1

Systems Engineering

Revitalization: an Industry Perspective

Dr. John B. Noblin LM IS&S

Chair GEIA G-47

DSP Conference 8 March 2005

2

From Some of Our Customers:

• Direction from the SECAF: - Develop Plan to strengthen Air Force’s

systems engineering capabilities - “Create an Institute for Systems

Engineering” • ASECAF (AQ) Policy Memo:

- Incentivize Contractors for Better Systems Engineering

• SMC/CC Policy Memo: - Application of SE related Specs & Standards

required on an integral element of SMC acquisition, contracting and program

management

“We Need Better SE”

• Navy – Collaboration on SE process improvements across

NAVAIR, NAVSEA, SPAWAR & MARCORPS – Broad level System-of-Systems integration

• FAA – Enterprise-wide Integrated Capability Maturity

Model in use for internal performance improvement

• OMB – Collaborating on an Enterprise Process

Improvement Framework for Government – Linked to OMB Federal Enterprise Architecture

Initiative

3

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 12207 IEEE

1220

SDCE

SE-CMM

EIA 731

EIA/IS 632

ISO 9000 series

ANSI/EIA 632

SSE- CMM

ISO/IEC 15288

*not released **based on CBA IPI, SAM, and others # V2 also based on many others See www.software.org/quagmire

CMMI

SA- CMM

Q9000

DOD- STD- 2168

QuagAug03

FAA- iCMM#

RTCA DO-178B

SW-CMM

TL9000

ISO 15939

PSM

SCAMPI

CBA IPI

SAM

FAM**

Process Stds Quality Stds Maturity or Capability

Models Appraisal methods

Guidelines

Six Sigma

J-STD 016

DOD- STD-

7935A TSP

The Frameworks Quagmire

supersedes

uses/references based on

Italic = obsolete boxed = integrating

4 Legend

Mil-Std-498

Heritage of Systems Engineering Standards

Systems Engineering EIA / IS

632

ISO 15288

ISO/IEC 12207

IEEE 1498 /EIA 640

Software Engineering Emphasis

Mil-Std-499B Mil-Std-

499A

DoD-Std-7935A

1994

1994

1994

1998

2003

1995

1996 1994

1988

1974

(Not Released)

DoD-Std-2167A

1988

DoD-Std-1703

1987

Mil-Std-499

1969

(Trial Use) IEEE 1220

1998

(Full Std)

(Draft)

2002

J-Std-016

1997

Supersedes Derived From

EIA 632

ANSI/EIA 632

Others ...

(Updates)

IEEE 1220

(Updates)

2002 EIA 731 SE

Capab. Model

IEEE 1220

IEEE 12207

1998

LM SE Revitalization

Project Defined Process

Project Defined Process

Common Source Standards

Organizational Standard

Process(es) LM-IEP

Process Standard

Industry Std

Gov’t Std

Domain Specific Standards

ANSI/EIA-632

ISO 9001:2000

IEEE 1220

LM–HWLCPS

Industry Std

Gov’t Std

Project Specific Standards

Project Defined Process

ISO/IEC-12207

CMMI V1.1

ISO/IEC-15288

LM CPSs

LM Business Units

5 Copyright 2003. Lockheed Martin Unpublished Work. All Rights Reserved.

Indicates Industry SE Standard

6

How Would You Define SE?

7

Systems Engineering…

Is a PROCESS – Not an Organization •Led by systems engineers

•All functions play a role; Integrated via Integrated Process and Product Development (IPPD)

•Must be rigorously applied across program

•The technical "glue" which makes separate design disciplines and subsystems function together to provide an integrated system which performs a specific job.

SE is a systematic, interdisciplinary approach that transforms customer needs into a total system solution

8

Systems Engineering…

…an interdisciplinary approach encompassing the entire set of scientific, technical, and managerial efforts needed to evolve, verify, deploy (or field), and support an integrated and life-cycle balanced set of system solutions that satisfy customer needs.

Needs Solution

9

The Systems Viewpoint • The Design Engineer has the specialist's

viewpoint. Views the system from the inside.

-Concerned with other system elements only as they affect their own design task; but not necessarily how theirs may affect others

• The Systems Engineer has the systems viewpoint. Views the system from the outside.

-Concerned with the effect of all system elements as they affect overall system design / performance / cost / schedule

10

Systems Engineering must focus on the entire problem: optimize the whole, not the parts!

11

What could we do Better? • Requirements should be written better

-Crisp, unambiguous, testable, firm

• All Program disciplines work together

-Program management, Engineering disciplines, contracts, bus ops, business development, research

• Compromise when necessary

-Tailor Standards & Procedures

-Eliminate desirables / use real needs

12

The Value of Systems Integration • Why is it important?? • The keyword is Integration … technical integration • Without it:

- At best:

- At worst: Complete failure – Pile of car parts – DIA Baggage Handling

13

Impact of SE on Program Cost

Defense Systems Management College - 9/1993

Cum

ulat

ive

Perc

enta

ge L

ife C

ycle

Cos

t

100%

90%

80%

70%

60%

50%

40%

30%

20%

10%

0%

Concept Phase

Design Phase

Develop- ment

Prod/Test Phase

Operations Through Disposal

8% 15% 20%

100%

Committed Costs

70%

85% 95%

3-6X

20-100X

500-1000X

Time Full Program Expenditures

50%

By the time system level design is complete, 85% of the costs have been committed and the cost to extract defects goes up exponentially

14

Why Is It Important to Manage Requirements?

• To ensure that there is a stable, consistent requirements baseline

• To avoid requirements growth

• To ensure everyone is working to the same set of requirements

• To get appropriate cost impact assessments for proposed changes from all stakeholders

15

As Contracts Specified It

Why are Requirements Important?Why are Requirements Important?

As Engineering Designed It As Materiel Ordered It

As Manufacturing Assembled It As Test Verified It What the Customer Wanted

Clearly Communicating Requirements is EssentialClearly Communicating Requirements is Essential

16

Mission Analysis Example -- The Modern Battlefield

17

One Requirements Repository/Tool for ALL Data and Disciplines

Requirements and Design

Stakeholder Needs & Mission Requirements

Operational Concepts

System Requirements

System Design

Element Requirements

Element Design

Repeat to lowest item level Items

Q: Where do requirements end and design begin? A: There is no dividing line. Design work at one level

generates requirements for the next lower level.

18

What Are the Verification Methods?

Inspection

Analysis/Simulation

Test

Demonstration

19

In summary, The Government / Industry Partnership in Systems Engineering begins with Standards

Systems Engineering Revitalization:

-Focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design.

- Integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation.

-Considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.

20

Lessons Learned - When to Worry

“That’s history!…We’re going to ‘do it differently this time!’”

“This is all within the state of the art with little design and no development.”

“How could it possibly cost that much ? It wouldn’t cost that much if we didn’t do….”

“We are using COTS hardware - cost risk is low.”

“It’s a tight but achievable schedule.”

“This system has been around for years, all we’re doing is a modification [derivative].”

21

Lessons Learned - When to Really Worry

You’ve carefully thought out all the angles

You’ve done it a thousand times

It comes naturally to you

You know what you’re doing, its what you’ve been trained to do your whole life

Nothing could possibly go wrong…. RIGHT?

22

Boy, that looks like an interesting job

What Process? I’ve done this before!

23

Think Again!

And Follow Your SE Processes!