A review of systems engineering standards and processesaero.tamu.edu/sites/default/files/jnj_symposium/JBioMechanics2008.pdf · ISO 15288 19 9 6 ISO /IEC 15288 AN SI/EIA 632 2002

* Corresponding author. Tel.: +886-2-2737-8000; fax.: +886-2-2737-8044.

E-mail address: [email protected] (J. N. Juang).

A review of systems engineering standards and

processes

Guey-Shin Chang, Horng-Linn Perng, Jer-Nan Juang*

National Applied Research Laboratories, 3F, No. 106, Ho-Ping E. Road, Sec. 2, Taipei 10622, Taiwan.

Abstract

This report provides an overview of the evolution of systems engineering standards and

guidelines, process models, and compliance assessment models from past to present. The history of

the development of systems engineering is introduced in order to show the need for its development

in that the traditional approach was deemed inadequate due to the difficulties associated with newer

larger-scale systems. Also in this report, systems engineering standards--defining the

interdisciplinary tasks that are required throughout a system’s life cycle in order to transform the

customer needs into a systems solution--are reviewed from the standpoint of their evolution. The

various commonly used system process models are addressed in order to emphasize that the

functions of the defined processes are performed in a parallel and iterative manner. The evolution

of compliance assessment models--used by organizations to investigate their compliance with all

standards, process models, evaluation, assessment, and certification criteria--are examined as well.

Finally, this report concludes that a working knowledge of systems engineering is an absolute

requirement of personnel working in modern enterprises and that the implementation of systems

engineering processes must be tailored to the scope of the job at hand.

1. Introduction

Systems engineering is a methodology developed to address the increasing

complexity that systems acquisitions have acquired over the past several decades. The

need for a systems engineering approach that is able to transfer user needs into an

operational system via an interdisciplinary process is highly sought after by both

government and industry. In the past, the fields of military defense, space exploration,

and software engineering were most interested in acquiring this type of capability.

Recently, however, many enterprises, professional societies, and other types of

organizations have recognized the importance of incorporating systems engineering

models into their own business models. To this end, a great deal of effort has been made

www.tibm.org.tw

Journal of Biomechatronics Engineering

Vol. 1, No. 1, (2008) 71-85

72 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) 71-85

to develop a standard for systems engineering and to promote its use on the campuses of

engineering-focused universities.

As stated in ANSI/EIA 632 (1999), “Systems engineering is intended to enable an

enterprise to strengthen its competitiveness in global markets by engineering and

producing quality systems and by delivering its products on time at an affordable price or

cost. The focus, therefore, is on conceptualizing, creating, and realizing a system and the

products that make up a system.” Many global enterprises have included systems

engineering competence in their visions. Some such enterprises include:

․ Raytheon’s Vision statement: “We aspire to be one of the most admired technology

companies in the world, and a "System of Systems" integrator.” - Dan Burnham

(CEO), November 9, 2000

․ Lockheed Martin’s Vision statement: “To be recognized as the world’s premier

systems engineering and technology enterprise.” - Dan Tellep (CEO) and Norm

Augustine (President), May 5, 1995

It became evident that there was a need for the development of systems engineering

standards when the traditional approach was deemed inadequate due to the difficulties

associated with newer larger-scale systems. These difficulties include the increased

complexity of data, the expanding role of software, the lack of traceability, and cost

overruns. In order to address these issues, it was necessary that a new approach for

systems management, both from a technical and programmatic viewpoint, be established.

As a result, many different systems engineering standards and models have evolved over

the years. This proliferation of various standards serves to accommodate systems

development, compliance assessment, and certification processes and, as a consequence,

has created a set of diverse terminologies.

Systems engineering’s beginnings can be traced back to Bell Telephone Laboratories

in the 1940s. However, it was not until almost thirty years later that the first U.S. military

standard, MIL-STD-499, was published in 1969 (U.S. department of Defense, 1969).

Systems engineering standards and guidelines have evolved from a federal government

contract-centric approach to a commercial, voluntary-compliance approach. The first

professional systems engineering society, the International Council on Systems

Engineering (INCOSE), was not organized until the early 1990s and the first commercial

U.S. systems engineering standards, ANSI/EIA 632 (1999) and IEEE 1220 (1998),

followed shortly thereafter.

It should be noted that this report only addresses the evolution of systems engineering

standards and guidelines, process models, and compliance assessment models from past

to present. It is not intended to cover the most recent model developments or specific

implementations that appear within published literature.

2. Systems and systems engineering defined

For people who are interested in the field of systems engineering, the questions most

often asked are, “What is a system and what is systems engineering?” Many different

definitions can be found on websites and in systems engineering standards and guidelines

but, basically, they are all the same in terms of the subject. “Systems Engineering

G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) 71-85 73

Fundamentals,” published by Defense System Management College (DSMC, 2001),

provides perhaps the most useful definition:

“Simply stated, a system is an integrated composite of people, products, and

processes that provide a capability to satisfy a stated need or objective.”

“Systems engineering consists of two significant disciplines: the technical knowledge

domain in which the systems engineer operates and systems engineering management.”

Three commonly used definitions of systems engineering are provided by the best

known technical standards that apply to the subject. They all have a common theme:

․ A logical sequence of activities and decisions that transforms an operational need into

a description of system performance parameters and a preferred system configuration.

(MIL-STD-499A, Engineering Management, 1 May 1974. Now canceled (U.S.

department of Defense, 1974).)

․ An interdisciplinary approach that encompasses the entire technical effort and evolves

into and verifies an integrated and life-cycle balanced set of system people, products,

and process solutions that satisfy customer needs. (EIA /Standard IS-632, Systems

Engineering, December 1994.)

․ An interdisciplinary, collaborative approach that derives, evolves, and verifies a life-

cycle balanced system solution which satisfies customer expectations and meets

public acceptability. (IEEE P1220, Standard for Application and Management of the

Systems Engineering Process, [Final Draft], 26 September 1994.)

In summary, systems engineering is an interdisciplinary engineering management

process that evolves and verifies an integrated, life-cycle balanced set of system solutions

that satisfy customer needs. It is interesting to note that the ANSI/EIA 632 does not

define systems engineering as such, rather, it tries to define “what to do” with respect to

the “processes for engineering a system.”

3. Evolution of standards and guidelines

Systems engineering standards define the interdisciplinary tasks that are required

throughout a system’s life cycle to transform the customer needs into a systems solution.

US Military Standard MIL-STD-499, Engineering Management, dated July 17th, 1969,

was an early standard on the subject of systems engineering. It was produced by the

United States Department of Defense (DoD) for applications within the defense industry.

MIL-STD-499 provided the first definition of the scope of engineering management and

was very influential in defining the scope of systems engineering at that time. Five years

later, the A-version, MIL-STD-499A, was released on May 1st, 1974. The MIL-STD-

499B draft, dated 1992, was an updated and significantly rewritten version of MIL-STD-

499A that was distributed for review. At the time of its review, however, the majority of

industry did not accept the most comprehensive of these standards, that being MIL-STD-

499B.

In June 1994, as part of the acquisition reform effort, DoD decreed an end to military

standards other than performance specifications. Then Secretary of Defense, Dr. William

J. Perry, approved the Process Action Team’s recommendation “to use performance and

commercial specifications, unless no practical alternative exists to meet the user’s needs.”


A memorandum titled “Specifications and Standards – A New Way of Doing Business

(1994),” by Dr. William J. Perry, cited a goal for DoD to increase its access to

commercial state-of-the-art technology and allow for dual-use processes and products

from the commercial sector in the military as a way to expand the potential industrial

base for military equipment and services. Due to this policy the revision of MIL-STD-

499A was canceled and MIL-STD-499B was not officially released. The MIL-STD-499B

standard, however, had been used extensively by the Air Force as well as by other high-

tech industries.

The Director of Systems Engineering within the Office of the Secretary of Defense

(OSD) asked that a group of organizations collaborate to develop a commercial systems-

engineering standard to replace the military one. The working group was called the

Electronic Industries Alliance (EIA) and was composed of representatives from the DoD,

the Aircraft Industry Association (AIA), the National Security Industries Association

(NDIA), the Institute of Electrical and Electronics Engineers (IEEE), and INCOSE. This

working group made minor wording changes in the MIL-STD-499B draft and released a

“commercialized” version of MIL-STD-499B in December 1994 that was known as EIA

Interim Standard 632 (EIA/IS 632), Systems Engineering. This draft was written using

considerably more industry input and then transformed into a replacement version called

ANSI/EIA 632-1998, Processes for Engineering a System. It was released in January

1999 (Electronic Industry Association, 1999; Martin, 1998; Valerdi and Wheaton, 2005).

At the same time, IEEE was also working on a commercialized systems engineering

standard. The IEEE standard also incorporated significant industry input and was based

on the MIL-STD-499B draft and an AT&T systems engineering manual. The result was a

systems engineering standard called IEEE 1220 (1998), Standard for Application and

Management of the Systems Engineering Process. A Trial-Use version of IEEE 1220 was

released in February 1995 and a Full-Use version in January 1999. The International

Organization for Standardization (ISO) along with the International Electrotechnical

Commission (IEC) jointly developed ISO/IEC 15288 (2002). ISO/IEC 15288 was an

effort to create an international system life-cycle standard that was initiated by the same

group that created the ISO software life-cycle standard, ISO/IEC 12207. ISO/IEC 15288

was augmented by people with systems engineering expertise. These three commercially-

derived standards each addressed the systems engineering processes at various levels and

all three were required to fully realize systems engineering success within the

organizations that needed them. Fig. 1 shows the evolution of systems engineering

standards.


MIL-STD-499

July 1969

Engineering Management

MIL-STD-499A

May 1974

MIL-STD-499B

June 1992

“Coordination Copy”

Perry Memo

Abolishes new military standards

June 1994

IEEE 1220

1992

Commercial SE Standard beganEIA/IS 632

December 1994

Interim Standard

After Perry Memo

ISO 15288

1996

ISO/IEC 15288

2002ANSI/EIA 632

January 1999

IEEE 1220

Trial Use

February 1995

IEEE 1220

Full UseJanuary 1999

X

MIL-STD-499C

May 1994

Unreleased Draft

coordina

tion

MIL-STD-499C

March 2007

Draft by TAC

ISO/IEEE 15288

2008

MIL-STD-499

July 1969

Engineering Management

MIL-STD-499A

May 1974

MIL-STD-499B

June 1992

“Coordination Copy”

Perry Memo

Abolishes new military standards

June 1994

IEEE 1220

1992

Commercial SE Standard beganEIA/IS 632

December 1994

Interim Standard

After Perry Memo

ISO 15288

1996

ISO/IEC 15288

2002ANSI/EIA 632

January 1999

IEEE 1220

Trial Use

February 1995

IEEE 1220

Full UseJanuary 1999

X

MIL-STD-499C

May 1994

Unreleased Draft

coordina

tion

MIL-STD-499C

March 2007

Draft by TAC

ISO/IEEE 15288

2008

Fig. 1. The evolution of systems engineering standards.

In addition to standards, many guidelines and handbooks on systems engineering

were released by organizations, especially in the space and military sectors. A handbook

with two volumes, MSFC-HDBK-1912A, Systems Engineering Handbook was released

by the National Aeronautics and Space Administration (NASA)/Marshall Space Flight

Center (MSFC) in 1991 and revised in 1994. NASA-SP-6105, NASA Systems

Engineering Handbook was published by NASA in 1992 and revised in 1995. A book

named Systems Engineering Fundamentals was published by Defense System

Management College (DSMC) in 1999 and revised in 2001. In Europe, the European

Space Agency (ESA) released a series of standards on space engineering including

ECSS-E-10 that was released in April 1996.

4. Systems engineering process models

The systems process model describes an enterprise’s activities as they relate to its

total engineering effort to achieve a given outcome (i.e., a product or service). The

systems process model illustrates the sequence and/or interaction among various project

activities from creation to disposal of the product/service. The most commonly used

process models are the Waterfall, Spiral, and Vee (Blanchard and Wolter, 2006).

The Waterfall model (Royce, 1970), introduced by Royce in 1970, initially was used

for software development. This model usually consists of five to seven series of steps or

phases for the systems engineering of software development. Boehm expanded this into

an eight-step series of activities in 1981. A similar model splits the hardware and

software into two distinct efforts. Ideally, each phase is carried out to completion in


sequence until the product is delivered. However, such is rarely the case. When

deficiencies are found, phases must be repeated until the product is corrected.

The Spiral process model of the developmental life cycle (Boehm, 1988) was

introduced as a risk-driven approach for the development of products or systems. This

model was an adaptation of the Waterfall model, which did not mandate the use of

prototypes. The Spiral model incorporates features from other models such as feedback.

The Spiral model application is iterative and proceeds through several phases each time a

different type of prototype is developed. It allows for risk evaluation before proceeding to

the subsequent phase.

The Vee process model was developed (Forsberg and Mooz, 1992, 1995) by Forberg

and Mooz and described by them as “the technical aspect of the project cycle.” This

model begins with the user’s needs on the upper left-hand side and ends with a user-

validated system on the upper right-hand side. On the left-hand side, decomposition and

definition activities resolve the system architecture, thus creating the design details.

Integration and verification flows up and to the right as successively higher levels of

subsystems are verified, thus culminating at the system level. The Vee process model

also shows the verification and validation progress from the component level to the

validation of the operational system. At each level of testing, the original specifications

and requirements are referenced to ensure that the components, subsystems, and the

system itself all meet the original specifications.

SynthesisEvaluation

and

Decision

Description

of System

Elements

Functional

Analysis

Input

RequirementsOR OR

OR

SOLUTIONS

• WHAT

• WHY

• HOW

ITERATIVE TRADE-OFFS

Fig. 2. The systems engineering process.

The traditional systems engineering process for accomplishing system design tasks is

often referenced in publications (Systems Engineering Management Guide, DSMC, Jan

1990). Fig. 2 illustrates the activities of the basic systems engineering process. It consists

primarily of four activities: 1) functional analysis, 2) synthesis, 3) evaluation and decision,

and 4) a description of systems elements. The final product is production-ready

documentation of all system elements. Although this process only deals with system

design activities, it is the most traditional process used in the acquisition of defense

systems over the last several decades.


Fig. 3. The SIMILAR process (Bahill and Gissing, 1998).

In addition to the most commonly used process models mentioned previously, Bahill

and Gissing (1998) proposed the so-called SIMILAR process. This process is usually

comprised of the following seven tasks: 1) state the problem, 2) investigate alternatives, 3)

model the system, 4) integrate, 5) launch the system, 6) assess performance, and 7) re-

evaluate. These functions are summarized using the acronym SIMILAR: State,

Investigate, Model, Integrate, Launch, Assess, and Re-evaluate. The SIMILAR systems

engineering process is illustrated in Fig. 3.

Fig. 4. The relationship between systems engineering processes.


ANSI/EIA 632 also defines 13 processes containing a total of 33 requirements that

are used in engineering a system. ANSI/EIA 632 can be applied to the developmental

process of any product. These processes can be applied to the engineering or re-

engineering of the end products that make up the system as well as to the development of

enabling products required to provide life-cycle support to system end products. Fig. 4

shows the relationships between the processes that make up this standard.

The key concepts for this standard cited from ANSI/EIA 632 are summarized as

follows:

“This Standard defines a systematic approach to engineering or reengineering a

system, incorporating best practices that have evolved during the second half of the

twentieth century. The defined approach has three premises:

a) A system is one or more end products and sets of related enabling products that allow

end products, over their life cycle of use, to meet stakeholder needs and expectations;

b) Products are an integrated composite of hierarchical elements so integrated as to meet

the defined stakeholder requirements;

c) The engineering of a system and its related products is accomplished by applying a

set of processes to each element of the system hierarchy by a multidisciplinary team

of people who have the requisite knowledge and skills.”

Fig. 5. The 33 Process Requirements Specified by ANSI/EIA 632.


The process model is defined as an enterprise’s activities as they are related to the

total engineering effort to achieve a given outcome. Regardless of any defined processes,

it is important to note that the Systems Engineering

Process is not sequential. The functions are all performed in a parallel and iterative

manner. The previous review report can also be found in Systems Engineering Review

Report (2002) by Global Intergy Corporation.

5. Compliance assessment models

Organizations that want to remain competitive usually strive to comply with all

possible standards, process models, evaluation, assessment, and certification criteria.

Organizations use system capability and maturity models to investigate their processes as

well as the quality, cost, and effectiveness of their products. Capability models define the

characteristics of good processes but do not necessarily prescribe how the processes

should be implemented. Capability models are not actually processes. The purpose of

capability models is to establish a process improvement roadmap upon which a route can

be drawn from “where we are today” to “where we want to be.” In order to determine

“where we are today,” an organization performs an assessment, also called an appraisal,

sometimes with the aid of an outsider with specific expertise in that model. They

intentionally do not address a particular life-cycle or sequence of activities. The first

capability model, the Software-Capability Maturity Model (SW-CMM), was developed

for the field of software development, or more precisely, the management of software

development projects. Based on this, the Capability Maturity Model (CMM) models

expanded on and addressed systems engineering, integrated product development, as well

as other aspects of organizations including human resources and organizational security.

In 1992, the International Council on Systems Engineering (INCOSE) sponsored a

working group that began to address the assessment of systems engineering capability.

This group developed the Systems Engineering Capability Assessment Model (SECAM)

that was released in July 1996. Also, in December 1993, the Enterprise Process

Improvement Collaboration (EPIC) group spun off from the INCOSE SECAM working

group and developed the Systems Engineering Capability Maturity Model (SE-CMM)

that was released in December 1994. A service mark report on the SE-CMM Ver. 1.1

(1995) was released by Carnegie Mellon University’s Software Engineering Institute

(SEI) in November 1995. This standard evolved from a software legacy. The

development of these two groups meant there were now two systems engineering

capability maturity models on the market.

INCOSE and the Director for Systems Engineering in the Office of the Secretary for

Defense agreed that the two models should be combined into one single model. EPIC and

INCOSE agreed to work towards a merged model that was eventually called the Systems

Engineering Capability Model (SECM), EIA/IS 731. SECM was accepted as the standard

model within the systems and software engineering communities. It should be

emphasized that the SECM is not a process standard but actually a standard for defining

and assessing the maturity of the systems engineering discipline.


In 1997, the Software Productivity Consortium (SPC) created a website to help

organizations understand which frameworks were most important and how they related to

each other. Various combinations of international and national standards bodies,

governmental organizations, professional societies, and other quasi-legislative bodies

have promulgated a dizzying array of system process standards, recommended practices,

guidelines, and capability maturity models. The resulting quagmire has quenched the

ardor of many organizations seeking accreditation for one or more frameworks. The

Frameworks Quagmire (Sheard, 2001), proposed by SPC, as shown in Fig. 6, provides

detailed maps of the standards evolution and adds to the potential confusion over systems

engineering standards and models.

In December 2000, the Capability Maturity Model Integration (CMMI) was created

by SEI. CMMI integrated the capability models for software engineering, systems

engineering, and integrated product and process development processes. The CMMI

provided specific assessment and appraisal method for systems engineering (SE-CMM),

software engineering (SW-CMM), software acquisition (SA-CMM), integrated product

and process development (IPPD-CMM), EIA/IS 731 (Software Engineering Institute,

Carnegie Mellon University, 1995, 2001a, 2001b, 2001c, 2001d, 2002a, 2002b, 2002c,

2002d), etc. Before CMMI released their model, however, the U.S. Federal Aviation

Administration created its own integrated CMM, FAA-iCMM (1997). The FAA model

combined process areas from SW-CMM, SE-CMM, SA-CMM, ISO 9000, ISO/IEC

12207, ISO/IEC 15288, EIA 632, EIA/IS 731, ISO/IEC 15939, and the CMMI. The

current version for FAA-iCMM is Ver. DS2.0. Fig. 7 shows the modified Framework

Quagmire after CMMI published.

The new version further integrated into CMMI for Development (CMMI-SEI, 2006),

CMMI for Service (CMMI-SVC, 2006) – draft, and CMMI for Acquisition (2007). The

latest models integrate the bodies of knowledge that are essential for development and

maintenance, acquisition environment and services practices, but that have been

addressed separately in the past. The modified Framework Quagmire after three

published CMMI constellations is shown in Fig. 8.


ANSI/EIA 632

PSP

IEEE/EIA

12207

Baldrige

ISO/IEC

15504

People CMM

IPD-

CMM*

SECAM

SCE

MIL-STD-

498

DOD-

STD-

2167A

MIL-STD

499B*

ISO/IEC

12207IEEE

1220

SDCE

SE-CMM

EIA

731

EIA/IS

632

ISO 9000

series

SSE-

CMM

ISO/IEC 15288

CMMI

SA-

CMM

Q9000

DOD-

STD-

2168

FAA-

iCMM#

RTCA DO-178B

SW-CMM

TL9000

ISO

15939

PSM

SCAMPI

CBA IPI

SAM

FAM**Six

Sigma

J-STD

016

DOD-

STD-

7935ATSP

supersedes

uses/references

based on

Italic = obsolete

Boxed = integrating

Process StdsQuality StdsMaturity or

Capability

ModelsAppraisal

methodsGuidelines

*not released **based on CBA IPI, SAM, and others # V2 also based on many others

Seewww.software.org/quagmire

ANSI/EIA 632

PSP

IEEE/EIA

12207

Baldrige

ISO/IEC

15504

People CMM

IPD-

CMM*

SECAM

SCE

MIL-STD-

498

DOD-

STD-

2167A

MIL-STD

499B*

ISO/IEC

12207IEEE

1220

SDCE

SE-CMM

EIA

731

EIA/IS

632

ISO 9000

series

SSE-

CMM

ISO/IEC 15288

CMMI

SA-

CMM

Q9000

DOD-

STD-

2168

FAA-

iCMM#

RTCA DO-178B

SW-CMM

TL9000

ISO

15939

PSM

SCAMPI

CBA IPI

SAM

FAM**Six

Sigma

J-STD

016

DOD-

STD-

7935ATSP

supersedes

uses/references

based on

Italic = obsolete

Boxed = integrating

supersedes

uses/references

based on

supersedes

uses/references

based on

Italic = obsolete

Boxed = integrating


Capability

ModelsAppraisal

methodsGuidelines


Capability

ModelsAppraisal

methodsGuidelines

*not released **based on CBA IPI, SAM, and others # V2 also based on many others

Seewww.software.org/quagmire

Fig. 6. The Frameworks Quagmire in 2001 (Source: Sheard 2001).

SW-CMM

MIL-Q-9858A

(1963)

Trillium Baldrige

IEEE Stds -730, -828, -829,

-830, -1012, -1016, -1028,

-1058, -1063ISO 15504

(SPICE)

2003

People

CMM

IPD-CMM*

DoD IPPD

SECAMAF IPD Guide

(1993)

SDCCR

SCE

NATO

AQAP 1, 4, 9

BS 5750

MIL-STD-498

(1994)

DOD-STD-2167A

(1988)

DOD-STD-7935A

(1988)

MIL-STD-499B*

(1994)

ISO/IEC 12207

IEEE 1220

(1998)ISO 10011

SDCE

SE-CMMSECM

EIA/IS 731

EIA/IS 632

ISO 9000

Series

EIA/IEEE

J-STD-016

(1995)

IEEE/EIA 12207*

EIA 632*

MIL-STD-1679

(1983)

IEEE 1074(1997)TickIT

SSE-CMM

ISO 15288*

EQA

CMMI

PSP

SA-CMM

Q9000

DOD-STD-2168

(1988)

FAA-iCMM

DO-178B

MIL-STD-499A

(1974)

MIL-STD-499

(1967)

MIL-STD-1803

(1988)

Green - US DoD: MIL, DOD, AF

Red - CMU-SEI: CMM, CMMIPurple - International: ISO, IEC, EC, UKBlue - US Industry: IEEE

* Not yet released

After: Sarah Sheard, SPC, 1997, www.software.com/quagmireQuagmire is copyr ight Software Productivi ty Consor tium (SPC)

TSP

DOD-STD-1703

(1987)

SW-CMM

MIL-Q-9858A

(1963)

Trillium Baldrige

IEEE Stds -730, -828, -829,

-830, -1012, -1016, -1028,

-1058, -1063ISO 15504

(SPICE)

2003

People

CMM

IPD-CMM*

DoD IPPD

SECAMAF IPD Guide

(1993)

SDCCR

SCE

NATO

AQAP 1, 4, 9

BS 5750

MIL-STD-498

(1994)

DOD-STD-2167A

(1988)

DOD-STD-7935A

(1988)

MIL-STD-499B*

(1994)

ISO/IEC 12207

IEEE 1220

(1998)ISO 10011

SDCE

SE-CMMSE-CMMSECM

EIA/IS 731

EIA/IS 632

ISO 9000

Series

EIA/IEEE

J-STD-016

(1995)

IEEE/EIA 12207*

EIA 632*

MIL-STD-1679

(1983)

IEEE 1074(1997)TickIT

SSE-CMM

ISO 15288*

EQA

CMMI

PSP

SA-CMM

Q9000

DOD-STD-2168

(1988)

FAA-iCMM

DO-178B

MIL-STD-499A

(1974)

MIL-STD-499

(1967)

MIL-STD-1803

(1988)

Green - US DoD: MIL, DOD, AF

Red - CMU-SEI: CMM, CMMIPurple - International: ISO, IEC, EC, UKBlue - US Industry: IEEE

* Not yet released

After: Sarah Sheard, SPC, 1997, www.software.com/quagmireQuagmire is copyr ight Software Productivi ty Consor tium (SPC)

TSP

DOD-STD-1703

(1987)

Fig. 7. The Frameworks Quagmire after CMMI (Source: modified after SPC 1997).


CMMI

After: Sarah Sheard, SPC, www.software.com/quagmireQuagmire is copyright Software Productivity Consortium (SPC)

MIL-Q-9858A

(1963)

Trillium

(CAN)

Baldrige

(US)

IEEE Stds -730, -828, -829, -830, -1012, -1016, -1028,

-1058, -1063ISO 15504

(SPICE)

2003

PeopleCMM

NATO

AQAP 1, 4, 9

BS 5750

MIL-STD-498(1984)

DOD-STD-2167A(1988)

DOD-STD-7935A

(1988)

MIL-STD-499B*

(1994)

ISO/IEC 12207

IEEE 1220

(1998)

ISO 10011EIA/IS 632

ISO 9000Series

EIA/IEEE

J-STD-016

(1995)

IEEE/EIA 12207(1998)

EIA 632(1999)

MIL-STD-1679(1983)

IEEE 1074(1994)

TickIT

SSE-CMM

ISO 15288

(2002)

EQA

Green - US DoD: MIL, DOD, AFRed - CMU-SEI: CMM, CMMI

Purple - International: ISO, IECBlue - US Industry: IEEE

* Not yet released

PSP

SA-CMM

Q9000

DOD-STD-2168(1988)

FAA-iCMM

DO-178B

MIL-STD-499C*(Draft 2005)

MIL-STD-499A(1974)

MIL-STD-499(1967)

ISO/IEEE 12207

(2008)

CMMI-DEV

CMMI-ACQ

CMMI-SVC

ISO/IEEE 15288

(2008)

DOD-STD-1703

(1987)

TSPCMMI

After: Sarah Sheard, SPC, www.software.com/quagmireQuagmire is copyright Software Productivity Consortium (SPC)

MIL-Q-9858A

(1963)

Trillium

(CAN)

Baldrige

(US)

IEEE Stds -730, -828, -829, -830, -1012, -1016, -1028,

-1058, -1063ISO 15504

(SPICE)

2003

PeopleCMM

NATO

AQAP 1, 4, 9

BS 5750

MIL-STD-498(1984)

DOD-STD-2167A(1988)

DOD-STD-7935A

(1988)

MIL-STD-499B*

(1994)

ISO/IEC 12207

IEEE 1220

(1998)

ISO 10011EIA/IS 632

ISO 9000Series

EIA/IEEE

J-STD-016

(1995)

IEEE/EIA 12207(1998)

EIA 632(1999)

MIL-STD-1679(1983)

IEEE 1074(1994)

TickIT

SSE-CMM

ISO 15288

(2002)

EQA

Green - US DoD: MIL, DOD, AFRed - CMU-SEI: CMM, CMMI

Purple - International: ISO, IECBlue - US Industry: IEEE

* Not yet released

PSP

SA-CMM

Q9000

DOD-STD-2168(1988)

FAA-iCMM

DO-178B

MIL-STD-499C*(Draft 2005)

MIL-STD-499A(1974)

MIL-STD-499(1967)

ISO/IEEE 12207

(2008)

CMMI-DEV

CMMI-ACQ

CMMI-SVC

ISO/IEEE 15288

(2008)

DOD-STD-1703

(1987)

TSP

Fig. 8. The Frameworks Quagmire Now (Source: modified after SPC 1997).

6. Conclusions

This paper provides an overview of the evolution of systems engineering standards

and guidelines, process models, and compliance assessment models from past to present.

The evolution of systems engineering required tremendous efforts on the part of many

professional societies, enterprises, and academia. The impact that systems engineering

has had on academia, government, and industry is immeasurable. It is important to note

that:

․ Systems engineering is a methodology that, by definition, assists enterprise personnel

to produce an end product that meets customer needs. Systems engineering does this

by helping the producer organize related processes, methods, and tools. Indeed, a

methodology is primarily created by accumulating the experience of failures or

overruns encountered in previous projects. Implementation of systems engineering

process defined in standards does not necessarily ensure a successful project;

however, it can help mitigate the risks associated with the project.

․ Systems engineering was developed to manage the acquisition of highly complex

high-end systems such as those utilized in the military, space, and software

development fields, of which the government was the primary customer during early

development. Various standards such as ANSI/EIA 632 and ISO/IEC 15288 have

been extended to enable enterprise to strengthen its competitiveness in global markets

by engineering and producing quality systems and by delivering products on time and


at an affordable cost. Systems engineering has become a discipline required for every

enterprise’s personnel working in technical or programmatic fields.

․ Systems engineering has value and application well beyond the bounds of traditional

engineering. Due to the different implications and objectives for each project, no

single systems engineering approach or capability assessment model can be applied to

all cases. It is extremely important to remember that, when implementing the systems

engineering processes, it must be properly tailored to the scope and level of the job at

hand.

References

ANSI/EIA-632, 1999, Process for Engineering a System. Electronic Industry Association.

Bahill, A. T., Gissing, B., 1998. Re-evaluating systems engineering concepts using systems thinking. IEEE

Transaction on Systems, Man and Cybernetics, Part C: Applications and Reviews 28, 516-527.

Blanchard, B. S., Fabrycky, W. J., 2006. Systems Engineering and Analysis, 4 ed. Prentice-Hall International,

London.

Boehm, B. W., 1988. A spiral model of software development and enhancement. Computer and Electronics in

Agriculture 21, 61-72.

CMMI for Services, 2006. Initial Draft. Software Engineering Institute (SEI). Carnegie Mellon University, USA.

CMU/SEI-95-MM-003, 1995a. A Systems Engineering Capability Maturity Model. (SE-CMM Ver. 1.1).

Software Engineering Institute (SEI). Carnegie Mellon University, USA.

CMU/SEI-95-MM-003, 1995b. A Systems Engineering Capability Maturity Model. (SE-CMM Ver. 1.1).

Software Engineering Institute, Carnegie Mellon University, USA.

CMU/SEI-2002-TR-001, 2001a. Capability Maturity Model Integration for Systems Engineering and Software

Engineering. (CMMI-SE/SW Ver. 1.1), Continuous Representation. Software Engineering Institute,

Carnegie Mellon University, USA.

CMU/SEI-2002-TR-002, 2001b. Capability Maturity Model Integration for Systems Engineering and Software

Engineering (CMMI-SE/SW Ver. 1.1), Staged Representation. Software Engineering Institute, Carnegie

Mellon University, USA.

CMU/SEI-2002-TR-003, 2001c. Capability Maturity Model Integration for Systems Engineering, Software

Engineering, and Integrated Product and Process Development (CMMI-SE/SW/IPPD Ver. 1.1),

Continuous Representation. Software Engineering Institute, Carnegie Mellon University, USA.

CMU/SEI-2002-TR-004, 2001d. Capability Maturity Model Integration for Systems Engineering, Software

Engineering, and Integrated Product and Process Development (CMMI-SE/SW/IPPD Ver. 1.1). Staged

Representation. Software Engineering Institute, Carnegie Mellon University, USA.

CMU/SEI-2002-TR-011, 2002a. Capability Maturity Model Integration for Systems Engineering, Software

Engineering, Integrated Product and Process Development and Supplier Sourcing (CMMI-

SE/SW/IPPD/SS Ver. 1.1), Continuous Representation. Software Engineering Institute. Carnegie Mellon

University, U.S.A.

CMU/SEI-2002-TR-012, 2002b. Capability Maturity Model Integration for Systems Engineering, Software

Engineering, Integrated Product and Process Development and Supplier Sourcing (CMMI-

SE/SW/IPPD/SS Ver. 1.1), Staged Representation. Software Engineering Institute, Carnegie Mellon

University, USA.


CMU/SEI-2002-TR-028, 2002c. Capability Maturity Model Integration for Software (CMMI-SW Ver. 1.1),

Continuous Representation. Software Engineering Institute, Carnegie Mellon University, USA.

CMU/SEI-2002-TR-029, 2002d. Capability Maturity Model Integration for Software (CMMI-SW Ver. 1.1),

Staged Representation. Software Engineering Institute. Carnegie Mellon University, USA.

CMU/SEI-2006-TR-008, 2006. Capability Maturity Model Integration for Development (CMMI-Dev Ver. 1.2),

Software Engineering Institute. Carnegie Mellon University, USA.

CMU/SEI-2007-TR-017, 2007. CMMI for Acquisition Ver. 1.2. Software Engineering Institute, Carnegie

Mellon University, USA.

DSMC, 1990. Systems Engineering Management Guide. Defense Systems Management College, Department of

Defence.

DSMC, 2001. Systems Engineering Fundamentals. Defense System Management College, Department of

Defence.

ECSS-E-10A, 1996. Space Engineering- Systems Engineering. European Space Agency.

EIA/IS 632, 1994. Systems Engineering, Interim Standard. Electronics Industry Association.

EIA/IS 731.1, Systems Engineering Capability Model, Electronic Industry Association (EIA).

EIA/IS 731.2, Systems Engineering Capability Model Appraisal Method, Electronic Industry Association (EIA).

FAA-iCMM, 1997. The Federal Aviation Administration Integrated Capability Maturity Model, Ver. 1.0: An

Integrated Capability Maturity Model for the Acquisition of Software Intensive Systems. Federal Aviation

Administration.

Forsberg, K., Mooz, H., 1992. The relationship of systems engineering to the project cycle. Engineering

Management Journal 4, 36-43.

Forsberg, K., Mooz, H., 1995. Application of the “Vee” to incremental and evolutionary development. In:

Proceedings of the Fifth Annual International Symposium of the National Council on Systems Engineering,

St. Louis, MO., USA.

Global Intergy Corporation, 2002e. Systems Engineering Process Review Report, Ver. 2.

IEEE 1220, 1998. IEEE Standard for Application and Management of the Systems Engineering Process. IEEE

Computer Society.

INCOSE Website, 2006. A consensus of the INCOSE fellows. On-line available at

http://www.incose.org/practice/fellowsconsensus.aspx.

ISO/IEC 12207, Systems and Software Engineering - Software Life Cycle Processes. International Organization

for Standardization.

ISO/IEC 15288, Systems and Software Engineering - System Life Cycle Processes. International Organization

for Standardization.

Martin, J. N., 1998. Overview of the EIA 632 standard: processes for engineering a system. In: Digital Avionics

System Conference, Seattle, Washington, USA, October 31- November 6, 1998, B32-1-9.

MIL-STD-499, 1969. Engineering Management. U.S. Department of Defense.

MIL-STD-499A, 1974. Engineering Management. U.S. Department of Defense.

MSFC-HDBK-1912A, 1994. Systems Engineering Handbook. NASA/Marshall Space Flight Center.

NASA-SP-6105, 1995c. Systems Engineering Handbook. NASA.

Perry, W. J., 1994. Specification and Standards – a New Way of Doing Business. Memorandum from the

Secretary of Defense to various military departments. Washington DC.

Royce, W. W., 1970. Managing the development of large software systems. Proceedings of IEEE WESCON 26,

1-9.

Sheard, S. A., 1997. The Frameworks Quagmire, A Brief Look. In: Proceedings of INCOSE.


Sheard, S. A., 2001. Evolution of the Frameworks Quagmire. Computer and Electronics in Agriculture 34, 96-

98.

Valerdi, R., Marilee, W., 2005. ANSI/EIA 632 as a standardized WBS for COSYSMO. In: AIAA 5th Aviation

Technology, Integration, and Operations Conference (ATIO), Hyatt Regency Crystal City, Arlington,

Virginia, USA, September 26-28, 2005, Paper No. AIAA 2005-7373.

Documents

A review of systems engineering standards and processesaero.tamu.edu/sites/default/files/jnj_symposium/JBioMechanics2008.pdf · ISO 15288 19 9 6 ISO /IEC 15288 AN SI/EIA 632 2002