Systems and Software Technology - ieee-stc.orgieee-stc.org/proceedings/2006/pdfs/jc1244.pdf · MIL-STD-499B MIL-STD-1679 1968-MIL-STD-961D Defense 1995 Specifications ISO/IEC 12207

0

Systems Engineering and Software EngineeringProcesses, Products, and People from a Standards Perspective (Subtitle: Stand on the Standards)

Systems and Software Technology Conference

May 1, 2006

John O. Clark William KenneyChief Engineer Systems EngineerNorthrop Grumman Mission Systems Northrop Grumman Mission Systems

Copyright 2006 Northrop Grumman CorporationCopyright 2006 Northrop Grumman Corporation

Systems Engineering and Software EngineeringProcesses, Products, and People from a Standards Perspective (Subtitle: Stand on the Standards)

Systems and Software Technology Conference

May 1, 2006

John O. Clark William KenneyChief Engineer Systems EngineerNorthrop Grumman Mission Systems Northrop Grumman Mission Systems

1

Overview

� Part 1 – Introduction

� Part 2 – Systems Engineering

� Break

� Part 3 – Systems Engineering Standards

� Part 4 - Recommendations & Summary

� Appendix - Acronyms

Copyright 2006 Northrop Grumman Corporation

2

Part 1 - Introduction


� Tutorial Purpose

� Tutorial Expectation

� Tutorial Conduct

� Copyright Acknowledgement

� Heritage and Future of Systems Engineering and Software Engineering Standards


� Break



� Appendix – Acronyms


3

Tutorial Purpose

� Describe the systems engineering and software engineering standards, including their heritage, processes, products, and future direction

� Show the relationships between systems engineering and software engineering processes and products based on the standards

� Encourage and challenge the participants to read, understand, select, tailor, and apply these standards

� “Stand on the standards," as opposed to relying solely on other sources such as instructions, procedures, guides, textbooks, education, training, and experience


4

Tutorial Expectation

On completing this tutorial, the participant will:

� Have a good understanding of systems, systems engineering, systems engineering management, systems engineering processes, and software engineering from a standards perspective

� Have a good understanding of the systems engineering and software engineering standards, including their heritage, processes, products, relationships, and future

� Have a good understanding of the system life cycle

� Be able to apply the standards to a project

� Use a common terminology to enhance communications

Learn the fundamentals of Systems Engineering and Software

Engineering Standards


5

Tutorial Conduct

� In fairness to all, we will start on time

� All ideas and beliefs will be respected

� What you say here stays here

� Participation is encouraged

� Your contributions improve the learning experience for everyone

� Class time is limited

� Brevity is a virtue!

This tutorial should be stimulating and fun.

Your participation will ensure that it is.


6

� Excerpts reprinted with permission IEEE 1220-1994, IEEE Trial-Use Standard for Application and Management of the Systems Engineering Process; IEEE 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process; and IEEE 12207, Industry Implementation of International Standard ISO/IEC 12207: 1995, Standard for Information Technology, Software Life Cycle Processes; and IEEE 1220-2005, IEEE Standard for Application and Management of the Systems Engineering Process. The IEEE disclaims any responsibility or liability resulting from the placement and use in the described manner.

� Excerpts from “Processes for Engineering a System” (EIA-632), Copyright © (1999) Government Electronics and Information Technology Association a Sector of the Electronic Industries Alliance. All Rights Reserved. Reprinted by Permission. Excerpts from "Systems Engineering” (EIA/IS 632), Copyright © (1994) Government Electronics and Information Technology Association a Sector of the Electronic Industries Alliance. All Rights Reserved. Reprinted by Permission.

� INCOSE Systems Engineering Handbook, Version 2a, 1 June 2004, Copyright © 2002, 2004 by INCOSE, subject to the following restrictions: INCOSE use. Permission to reproduce this document and to prepare derivative works from this document for INCOSE use is granted, provided this copyright notice is included with all reproductions and derivative works.

� Copyright International Organization for Standardization (ISO). This material is reproduced from ISO/IEC 15288:2002 and ISO/IEC TR 19760:2003 with permission from the American National Standards Institute on behalf of ISO. No part of this material may be copied or reproduced in any form, electronic retrieval system, or otherwise or made available on the Internet, a public network, by satellite, or otherwise without the prior written consent of the American National Standards Institute, 25 West 43rd Street, New York, NY 10036. Copies of these standards may be purchased from ANSI, (212) 642-4900, http://webstore.ansi.org.

Copyright AcknowledgementAcknowledgement

Provided with the permission of ____ from ____.

Copyright ____. All rights reserved. Copyright 2006 Northrop Grumman Corporation

7

INCOSE & JOCMIL-STDs to Commercial Stds to CMMs

Heritage and Future of SE and SW Standards

EIA/IS-632

1980

IEEE 1220

1994

DIDs

ANSI/EIA-

632

IEEE/EIA12207

MIL-STD-

499A

MIL-STD-

499

SystemsEngineering

ISO/IEC

12207

MIL-STD-

498

DOD-STD-2167

DOD-STD-2167A

DOD-STD-

1703

DOD-STD-

7935ADIDs

MIL-STD-1679A

1985

1998 1994

1994

1974 1969 1994

1987

1988

1988

1994

1995 1998

2006+

IEEE 1498

/EIA 640

1995

(Draft)

(Trial Use)

(Interim)

(Not

Released)

Sec Perry

LetterJan 1994

SoftwareEngineering

1968-

Data Item Descriptions

Primary Focus of this Brief

MIL-STD-499B

MIL-STD-

1679

1968-

MIL-STD-961D

1995 Defense Specifications

ISO/IEC

1220715288

Harmon

2005 IEEE 1220

2005

2006

EIA/IEEE

J-STD-016

1995

(Interim)

IEEE 1220

1998

MIL-STD-961E

2003

EIA/IS 731SE Capab Model

1998

ISO/IEC15288

2002

INCOSE SEHandbook V2

2000

NAVAIRSE Guide

2003

CMMI

DSMC/DAU

SE Fundamentals

1999 & 2001

V2a2004 2006

V3

ISO/IEC

TR 19760

2003

12207

1998

Supercedes

Based On

References

2006

NAVALSE Guide

2004


Legend:

8

In-Seat Warm-up Exercise

Instructions: Answer the following questions on your own without looking at the materials:

� What is a system?

� What is systems engineering?

� What is systems engineering management?

� What is the systems engineering process?

Time: 5 minutes

JOC


9

Overview (cont)



� What is a System?

� What is Systems Engineering?

� What is Systems Engineering Management?

� What is the Systems Engineering Process?

� Standards Scope and Detail

� User Scorecard and Mapping

� Break





10

� An integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective. (EIA/IS-632-1994)

� An aggregation of end products and enabling products to achieve a given purpose. (ANSI/EIA-632-1998)

� The top element of the system architecture, specification tree, or system breakdown structure that is comprised of one or more products and associated life cycle processes and their products and services. (IEEE 1220-1994)

� A set or arrangement of elements [people, products (hardware and software) and processes (facilities, equipment, material, and procedures)] that are related and whose behavior satisfies customer/operational needs, and provides for the life cycle sustainment of the products. (IEEE 1220-1998)

� A set or arrangement of elements [people, products (hardware and software) and processes (facilities, equipment, material, and procedures)] that are related, and whose behavior satisfies operational needs and provides for the life cycle sustainment of the products. (IEEE 1220-2005)

� A combination of interacting elements organized to achieve one or more stated purposes. (ISO/IEC 15288)

What is a System?

Provided with the permission of EIA fromEIA/IS-632-1994. Copyright 1995 EIA. All rights reserved.

Provided with the permission of EIA fromANSI/EIA-632-1998. Copyright 1999 EIA. All rights reserved.

Provided with the permission of IEEE from IEEE 1220-1994. Copyright 1995 IEEE. All rights reserved.

Provided with the permission of IEEE from IEEE-1220-1998. Copyright 1999 IEEE. All rights reserved.


Provided with the permission of ANSI from ISO/IEC 15288. Copyright 2003 ISO. All rights reserved.

Standards Definitions EIA, ANSI, IEEE, ISO/IEC


11

Pro

cesses

People

SystemPro

duct

sPeopleProducts Processes

System

Provided with the permission of EIA from EIA/IS-632-1994. Copyright 1995 EIA. All rights reserved.

EIA/IS-632-1994

What is a System? (cont)EIA/IS-632 & JOCKey Terms


12

What is a System? (cont)

SystemBreakdown

Structure (SBS)

Example:

External

System

External

System

Higher-Level Systems/

System-of-Systems (SOS)/

Family of Systems (FOS)

JOCAdditions

People

Battle Group/Ship

Warfare System

Warfare System Equipment, Procedures, Operators, Maintainers

Radar Subsystem

Phased Array Antenna

Array Hardware Configuration Item (CI)Array Software CI

Array Element Hardware UnitArray Element Software Unit

Phase Shifter HardwarePhase Shifter Software

ProductBreakdownStructure

(PBS)

IEEE 1220-2005 & JOC

System

Products Processes People


System Breakdown Structure (SBS)

Processes

& People

Processes

& People


13

What is a System? (cont)EIA/IS-632-1994


Example System Configuration


14Provided with the permission of EIA from ANSI/EIA-632-1998.

Copyright 1999 EIA. All rights reserved.

Forming a System Structure ANSI/EIA-632-1998



15

ISO/IEC 15288

Operational Environment and Enabling Systems


Provided with the permission of ANSI from ISO/IEC 15288. Copyright 2002 ISO/IEC. All rights reserved.


16

ISO/IEC 15288


Typical System of Systems Environment



17

ISO/IEC 15288

System and System Element Relationship


Provided with the permission of ANSI from ISO/IEC 15288. Copyright 2002 ISO/IEC. All rights reserved. Copyright 2006 Northrop Grumman Corporation

18

ISO/IEC 15288System of Interest Structure


Provided with the permission of ANSI from ISO/IEC 15288. Copyright 2002 ISO/IEC. All rights reserved. Copyright 2006 Northrop Grumman Corporation

19

� 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. the development of information for management decision making.(EIA/IS-632-1994)

� None (ANSI/EIA-632-1998)

� An interdisciplinary collaborative approach to derive, evolve, and verify a life cycle balanced system solution that satisfies customer expectations and meets public acceptability. (IEEE 1220-1994)

� None (IEEE 1220-1998 and IEEE 1220-2005)

� None (ISO/IEC 15288)

What is Systems Engineering?



Standards Definitions EIA & IEEE


20

System/Subsystem Design Description (SSDD)System Specification (SS) (MIL-STD-961E)

Software Design Description (SDD)

Requirement: “Noun shall verb.” Example: The car shall stop within 100 feet at 50 mph and be green.

Functional Performance Physical or Design

Function: “Verb Noun,” “Verb-ing,” or “Verb.” Examples: Stop Car, Stopping, or Stop.

Component: “Noun.” Example: Brake.

System Requirements Document (SRD)System Specification (SS) (MIL-STD-961E) System/Subsystem Specification (SSS)Software Requirements Specification (SRS)

Requirements

Functions Components(SSDD/SS/SDD)

What is Systems Engineering? (cont)JOCKey Terms and Relationships


21

� Functional Requirement: What?

� Performance Requirement: How well?

� Capability: A group of related requirements. Synonyms include function, subject, object, or other term useful for presenting the requirements.

� Configuration Item (CI): Any item designated for Configuration Mgmt.

� Preliminary Design: High-Level Design, one level below (inside) the CI.

� Detailed Design: Low-Level Design, lowest level of the CI.

� Validation: Right system?

� Verification: System right?

� Verification Methods: Analysis (including modeling and simulation), Demonstration, Test, and Inspection.

� Use Case: A scenario-driven functional thread through the system.

� Decompose: Parse or separate.

� Derive: Deduce (e.g., if a=b+c then c=a-b, or I’ll know it when I see it).

� Synthesis: Design. Translate requirements (problems) into solutions.

What is Systems Engineering? (cont)JOCRelated Terms


22

IEEE 1220-2005

What is Systems Engineering? (cont)


Problem and Solution Space for Systems Engineering


23

JOCProcesses, Architectures, and Baselines


• Requirements Trade Studies and Assessments

•Effectiveness Analysis, etc.

• Physical Design Trade Studies

• Effectiveness Analysis, etc.

Systems Analysis

• Functional Trade Studies andAssessments

• Effectiveness Analysis, etc.

Requirements Analysis• Define Requirements

• Define Interfaces

• Decompose and Derive Requirements

• Define Constraints & Conditions

• Define Requirements Architecture

• Establish Requirements Baseline

Functional Analysis & Allocation• Define Functions

• Allocate Requirements to Functions

• Define Functional Interfaces

• Decompose Functions to Subfunctions

• Allocate Decomposed and Derived

Requirements to Subfunctions

• Define Functional Architecture

• Develop Functional Flow Block Diagrams

• Establish Functional Baseline

Physical Design & Allocation• Define Subsystems and Components

• Allocate Functions and Subfunctions to

Subsystems and Components

• Define Subsystem & Component Rqmts

• Define Subsystem & Component Interfaces

• Establish Allocated Baseline

• Define Physical Architecture

• Develop Physical Flow Block Diagrams

• Establish Physical/Product Baseline

Control

F11 F12 F31

F3F1

Sys

F2

I/F

I/F

I/F I/F

I/F

I/FF32

R22 R21

R2R1

SysI/F I/F

R22R11 C1 C2 C3

Sub3Sub1

Sys

Sub2

I/F

I/F

I/F I/F

I/F

I/F

• Risk Management• Configuration & Data Management

• Interface Management

• Performance-Based Progress Measurement:

- SEMS/IMP & SEDS/IMS- TPMs & Metrics

- Technical Reviews

- Earned Value

Design

Loop

Requirements Loop

Verification Loop

Requirements ArchitectureFunctional Architecture Physical Architecture

• SOW, Deliverables• WBS, SBS, PBS

• Work & Planning Packages

and Assessments


24

1.0 2.0 3.0 4.0 5.0 6.0 7.0TOP

LEVEL F1 F2 F3 F4 F5 F6 F7

2ndLEVEL

1.0 1.1REF

F1 F1.1 OR

1.2

1.3

F1.2

F1.3

1.4

F1.4 AND

F1.5

F1.6

REF

2.0

F2

REF

1.4 1.4.1 1.4.2 1.4.3

F1.4 F1.4.1 F1.4.2 F1.4.33rd

LEVEL F1.5

REFG

REF

F1.4.3

G

G

OR 1.4.3.3REF

Fnn

1.4.3.1

F1.4.3.1

1.4.3.2

F1.4.3.2

F1.4.3.3

4thLEVEL

Functional Flow Diagram (FFD) Example


INCOSE SE HDBK

Provided with the permission of INCOSE from INCOSE SE Handbook, Version 2a. Copyright 2002, 2004 by INCOSE.


25


DSMCFunctional Flow Block Diagram (FFBD) Example

DSMC SE Fundamentals, October 1999Copyright 2006 Northrop Grumman Corporation

26

Function

Function

Function

Function

Function

1

2

3

4

5

Input

Output(F1)

(F2)

(F3)

(F4)

(F5)Output

Input

F1

F2

F1

F3

F1

F4

F1

F5

F1

F2

F1

F3

F2

F3

F2

F3

F2

F4

F2

F5

F3

F4

F2

F4

F1

F4

F3

F5

F2

F5

F1

F5

F4

F5

F3

F4

F3

F5

F4

F5

INCOSE SE HDBKOne Type of N2 Chart Using Functions


Cells are blank if no interface.

Other uses include interfaces between:

� Systems

� Spaces

� Products

� Processes

� People, and

� Organizations

Note: Doesn’t follow prior FFD example.



27

Generic Space-craft

Remote Ground Stations

Tracking and Data Relay Satellites

Data Relay and Control

Primary Users

-Payload Data -Spacecraft

Status

and Ranging

-Payload Data -Spacecraft Status and Ranging



- Payload Data - Data Products -Schedules

- Data Requests - Status - Surface Truth

- TDRS Vectors - TDRS Commands - S/C Commands

- Schedules - Directives - S/C Commands- Pred. S/C Positions

- S/C Commands

- S/C Commands

N2 Chart Example Using SystemsINCOSE SE HDBK


Provided with the permission of INCOSE from INCOSE SE Handbook, Version 2a. Copyright 2002, 2004 by INCOSE. Copyright 2006 Northrop Grumman Corporation

28


Another Type of N2 Chart Using Systems

System 1 System 2 System 3 System 4 System 5

JOC

Cells are blank if no interface.

Cells can contain interface direction, data, status, an X, etc.

System 1

System 2

System 3

System 4

System 5

S1 S1 S1 S1

S1

S1

S1

S1

S2 S2 S2 S2

S2

S2

S2

S2

S3

S3

S3

S3

S3 S3 S3 S3

S4

S4

S4

S4

S4 S4 S4 S4

S5

S5

S5

S5

S5S5S5S5


29


Functional to Physical Allocation Matrix Example DSMC

Can also be used for Requirements to Functional and Requirements to Physical allocations.

DSMC SE Fundamentals, October 1999Copyright 2006 Northrop Grumman Corporation

30

Accept Card

Accept PIN

DisplayIncorrect PIN

Accept Card

Accept PIN

Display

Menu

DisplayPin

Request

DisplayIncorrect

PIN

Display

MENU

ATM Card

PIN

ATM Card

PIN

Scenario 1 Bad PINScenario 2 Good PIN

Display

PinRequest


Functional Thread Analysis / Use Cases

INCOSE SE HDBK

Requirements Specifications and Test Procedures can be written using Use Cases.



31

� Waterfall (once through)

� Evolutionary (requirements allocated to increments or spirals)

� Incremental (end requirements known)

� Spiral (end requirements not known)

� Iterative (small increments)

� Combinations of Above


Systems Engineering Development StrategiesJOC


32


IEEE/EIA 12207

Provided with the permission of IEEE from IEEE/EIA 12207. Copyright 1998 IEEE. All rights reserved. Copyright 2006 Northrop Grumman Corporation

33

USD (AT&L)

Evolutionary Acquisition and Spiral Development,

USD (AT&L), April 2002



34


1. Determine objectives, alternatives, constraints

3. Develop and verify next level product

4. Plan next phases

2. Evaluate alternatives. Identify and resolve risks

Spiral Model

B. W. Boehm, “A Spiral Model of Software Development and Enhancement,”

IEEE Computer Society Press, 1990, pp 513-527.

B. W. Boehm


35

JOCIncremental and Iterative SE Process Example


A R F SS/HS PD

ITERATIONS

PCATC/SV/FCATRCD

1 2 3 4 5 6 7 8 9

Increment 1 Reviews:

A: AlternativeR: Requirements

F: Functional

SS: Software SpecHS: Hardware Spec

PD: Preliminary Design

CD: Critical DesignTR: Test Readiness

TC: Test Completion

SV: System VerificationFCA: Functional Configuration Audit

PCA: Physical Configuration Audit

Requirements

Analysis

Functional Analysis

and Allocation

Synthesis/ Design

Systems

Analysis

Control

Validation

Verification

Process

Iteration

INCREMENT 1

Iteration

Reviews:

R

F

PD/CD

A

TR

PCA

TC/SV/FCA

Leve

l of

Activity


36

SEDS

Calendar Driven (Date Driven or Time Coincidental)

Required Events, Milestones, and Activities

Measureable Dates or Periods

Captures All Required Events, Milestones, and Activities

Earned Value Management (EVM)

BCWS

BCWP

ACWP

Technical Performance Measurement (TPM)

Metrics

SV

CV

Notes:

- - - - - JOC Additions

Systems Engineering Master Schedule (SEMS) = Integrated Master Plan (IMP)

Systems Engineering Detailed Schedule (SEDS) = Integrated Master Schedule (IMS)

Key Elements of a Systems Engineering Management Plan (SEMP)

What is Systems Engineering Management?

EIA/IS-632-1994



37

Systems Engineering Management? (cont)Work Breakdown Structure (WBS) Example

System Breakdown Structure (SBS)

Organizational Breakdown Structure (OBS)

(CWBS)

PROGRAM WORK BREAKDOWN STRUCTURE (PWBS)•

•

C/SCSC Joint Guide & JOC

Cost/Schedule Control Systems Joint Implementation Guide,

AFSCP 173-5 & DLAH 8315.2, October 1980. Also see MIL-HDBK-881.

JOCAdditions

Product Breakdown Structure (PBS)


38

ISO/IEC 15288System and Project Hierarchies


Systems Engineering Management? (cont)


39

AcquirerPMP

DMP&CMP

SEMPSEMP

PAP

Supplier/Developer

PMP

RMP I&VP

HSIP

ILSP

ILSP

TEMP

Acquirer Plan

Supplier/

Developer Plan

DMP

RMP

SDPHDP CMP RM&AP TPIMP&IMS

CMP – Configuration Management PlanDMP – Data Management PlanHDP – Hardware Development Plan

HSIP – Human Systems Integration PlanILSP – Integrated Logistics Support Plan

IMP – Integrated Master PlanIMS – Integrated Master Schedule

I&VP – Integration and Verification Plan

PAP – Product Assurance Plan

PMP – Program Management PlanRM&AP – Reliability, Maintainability & Availability Plan

RMP – Risk Management PlanSDP – Software Development PlanSEMP – Systems Engineering Management Plan

TEMP – Test and Evaluation Management PlanTP – Training Plan

JOC


Plans Tree


40

EIA-632 Documents

EIA-632 Document Name Example of Consolidated Documents

Program Management

Plan

Engineering Management

Plan

Integration and Test

Management Plan

Product Assurance

And Support Plan

Security Policies/

Proc Plan

Concept Documents

Concept Specification X

Maintenance Concept X

Operations Concept (or Concept of Operations) X

Disposal Concept X

Technical Documents

Configuration Management Plan X

Contractor Integrated Technical Services Plan X

Data Management Plan X

Electromagnetic Compatibility/Interference Control Plan X

Engineering Plan X

Human Factors/Engineering Plan X

Interface Control Plan X

Supportability Plan X

Maintenance Plan X

Producibility Plan X

Project Plan X

Reliability Plan X

Software Development Plan X

System Safety Plan X

System Security Plan X

Technical Review Plan X

Testability Plan X

Training Plan X

Other (Verification, Validation, Test, TPM, CRD, Mfg, etc) X X X

Enterprise/ Project

Project Plan X

Resource Management Plan X

Risk Management Plan X

Strategic Plan X

Total Cost Of Ownership Plan X

EIA-632 & JOCExample of Consolidated Plans



41

JOC

CustomerSE Policy

ProgramSEMP

ProgramSEMP

CustomerSE TRM

CustomerSE Ops Man

Sources

SEMP

EIA/IS-6321994

CDRL – Contract Data Requirements ListCMMI – Capability Maturity Model Integrated

DAU – Defense Acquisition UniversityDoD – Department of Defense

DSMC – Defense Systems Management College

INCOSE – International Council on SESEMP – Systems Engineering Management Plan

SOW – Statement of WorkTRM – Technical Review Manual

INCOSESE Hdbk

DAU/DSMCSE Fund

IEEE 12202005

ContractSOW

DD 1423s

CDRLs

OrganizationProcess

Document

CustomerSE Guide

CustomerSEMP Hdbk

EIA-6321998

ISO 152882002

CMMIISO TR19760

2003

DoD5000

SDP

IEEE/EIAJ-STD-016

Heritage of the SEMP and SDP


CustomerSE Checklist


42

EIA/IS-632 Appendix B SEMP IEEE 1220 Annex B SEMP Combined EIA/IS-632 and IEEE 1220

Title Page Title Page Title Page Table of Contents Table of Contents Table of Contents

1.0 Scope 1.0 Scope 1.0 Scope 1.1 Technical Plan Summary

2.0 Applicable Documents 2.0 Applicable Documents 2.0 Applicable Documents 3.0 Systems Engineering Process 3.0 Systems Engineering Process (SEP)

Application 3.0 Systems Engineering Process (SEP) Application

3.1 Systems Engineering Process Planning 3.1 Systems Engineering Process Planning 3.1 Systems Engineering Process Planning

3.1.1 Major Products and Results of the Process

3.1.1 Major Deliverables and Results 3.1.1 Major Products and Results of the Process

3.1.1.1 Integrated Decision Data Base 3.1.1.1 Integrated Database 3.1.1.1 Integrated Decision Database

3.1.1.2 Specifications and Configuration Baselines

3.1.1.2 Specifications and Baselines 3.1.1.2 Specifications and Configuration Baselines

3.1.2 Process Inputs 3.1.2 Process Inputs 3.1.2 Process Inputs

3.1.3 Technical Objectives 3.1.3 Technical Objectives 3.1.3 Technical Objectives 3.1.4 Work Breakdown Structure (WBS) 3.1.4 System Breakdown Structure (SBS) 3.1.4 System/Work Breakdown Structure

(SBS/WBS) 3.1.5 Training 3.1.5 Training 3.1.5 Training

3.1.6 Standards and Procedures 3.1.6 Standards and Procedures 3.1.6 Standards and Procedures 3.1.7 Resource Allocation 3.1.7 Resource Allocation 3.1.7 Resource Allocation

3.1.8 Constraints 3.1.8 Constraints 3.1.8 Constraints 3.1.9 Work Authorization 3.1.9 Work Authorization 3.1.9 Work Authorization

3.1.10 Verification Planning 3.1.10 Verification Planning 3.1.11 Subcontractor/Supplier Technical Effort 3.1.11 Subcontractor/Supplier Technical Effort

3.2 Requirements Analysis 3.2 Requirements Analysis 3.2 Requirements Analysis 3.3 Requirements Baseline Validation 3.3 Requirements Baseline Validation

3.3 Functional Analysis/Allocation 3.4 Functional Analysis 3.4 Functional Analysis/Allocation 3.5 Functional Verification 3.5 Functional Verification

3.4 Synthesis 3.6 Synthesis 3.6 Synthesis/Design 3.7 Design Verification 3.7 Synthesis/Design Verification

3.5 Systems Analysis and Control 3.5.1 Systems Analysis 3.8 Systems Analysis 3.8 Systems Analysis

3.5.1.1 Trade Studies 3.8.1 Trade-Off Analyses 3.8.1 Trade Studies 3.5.1.2 System and Cost Effectiveness Analysis

3.8.2 System/Cost Effectiveness Analyses 3.8.2 System and Cost Effectiveness Analysis

3.5.1.3 Risk Management 3.8.3 Risk Management 3.8.3 Risk Management


SEMP Outlines



EIA/IS-632-1994 & IEEE 1220-2005


43

EIA/IS-632 Appendix B SEMP IEEE 1220 Annex B SEMP Combined EIA/IS-632 and IEEE 1220

3.5.2 Control 3.9 Control 3.9 Control

3.5.2.1 Configuration Management 3.9.1 Design Capture 3.9.1 Configuration Management 3.5.2.2 Interface Management 3.9.2 Interface Management 3.9.2 Interface Management

3.5.2.3 Data Management 3.9.3 Data Management 3.9.3 Data Management

3.5.2.4 Systems Engineering Master Schedule (SEMS)

3.9.4 Systems Engineering Master Schedule (SEMS)

3.9.4 Systems Engineering Master Schedule (SEMS)

3.5.2.5 Technical Performance Measurement (TPM)

3.9.5 Technical Performance Measurement 3.9.5 Technical Performance Measurement

3.5.2.6 Technical Reviews 3.9.6 Technical Reviews 3.9.6 Technical Reviews 3.5.2.7 Subcontractor/Supplier Control 3.9.7 Supplier Control 3.9.7 Subcontractor/Supplier Control

3.5.2.8 Requirements Traceability 3.9.8 Requirements Traceability 3.9.8 Requirements Traceability

4.0 Transitioning Critical Technologies 4.0 Transitioning Critical Technologies 4.0 Transitioning Critical Technologies

5.0 Integration of the Systems Engineering Effort



5.1 Organizational Structure 5.1 Organizational Structure

6.0 Implementation Tasks 5.2 Required Systems Engineering Integration Tasks

5.2 Required Systems Engineering Integration Tasks

7.0 Additional Systems Engineering Activities 6.0 Additional Systems Engineering Activities 6.0 Additional Systems Engineering Activities

7.1 Long-Lead Items 6.1 Long-Lead Items 6.1 Long-Lead Items

7.2 Engineering Tools 6.2 Engineering Tools 6.2 Engineering Tools 7.3 Design to Cost 6.3 Design to Cost 6.3 Design to Cost

7.4 Value Engineering 6.4 Value Engineering 6.4 Value Engineering

7.5 System Integration 6.5 Systems Integration Plan 6.5 System Integration

6.6 Interface With Other Life Cycle Support Functions

6.6 Interface With Other Life Cycle Support Functions

6.7 Safety Plan 6.7 Safety Plan

7.6 Other Methods and Controls 6.8 Other Plans and Controls 6.8 Other Plans and Controls

8.0 Notes 7.0 Notes 7.0 Notes

8.1 General Information (e.g., background, glossary)

7.1 General Background Information 7.1 General Background Information

8.2 Acronyms and Abbreviations with Meanings as used in the SEMP

7.2 Acronyms and Abbreviations 7.2 Acronyms and Abbreviations

7.3 Glossary 7.3 Glossary

9 Appendices Appendices Appendices

9.1 Technical Performance Measurement A. A Technical Performance Measurement

B.


SEMP Outlines (cont) EIA/IS-632-1994 & IEEE 1220-2005


Provided with the permission of IEEE from IEEE-1220-2005. Copyright 2005 IEEE. All rights reserved. Copyright 2006 Northrop Grumman Corporation

44

EIA/IS-632-1994



Provided with the permission of EIA from EIA/IS-632-1994. Copyright 1995 EIA. All rights reserved. Copyright 2006 Northrop Grumman Corporation

45

Technical Baselines, Documents, and Reviews

A/O – Alternative/OperationalCD – Critical Design

DBDD – Data Base Design Description

F – Functional

FCA – Functional Configuration Audit

HDD – Hardware Design Description

HRS- Hardware Requirements Specification

IDD – Interface Design Description

IRS – Interface Requirements Specification

ORD – Operational Requirements Document

PCA – Physical Configuration Audit

PD – Preliminary Design

TLR – Top Level Requirements

R – Requirements


Baselines

Performance

Requirements

Functional

Allocated

Developmental

Physical/Product

ORD / TLR

SRD / SS / SSSExternal IRS

SRD / SS / SSS

SSDD, SRS, HRS,Internal IRS

HDD (Drawings)SDD, DBDD, IDD

SoftwareHardware

R

F

PD

CD

FCA/VPCA

Documents Reviews

JOC

A/O

SDD – Software Design Description

SRD – System Requirements Document

SS – System Specification

SSS – System/Subsystem Specification

SRS – Software Requirements Specification

SSDD – System/Subsystem Design Specification

V – Verification


46

JOC

FULL MENUReview Types:

Document Types:

A R F I PD CD TR TC FCA VR PCA

ORDStudies

SSSIRS

SSSIRS

SSDD

SDDHDD

IDDDBDD

SDDHDD

IDDDBDD

T PlanT Proc

T Rpt Rpt Rpt Rpt

ASR SRR SFR SPDR SCDR STRR STCR SVR SPCA

ORD

Studies

SSS

IRS

SSS

IRSSSDD

SSDD SSDD T Plan

T Proc

Rpt RptRpt

Flow

Down:

Roll

Up:

SSRR SSFR SSPDR SSCDR SSTRR SSTCR SSFCA SSPCA

SSS SSS

IRSSSDD

SSDD SSDD T Plan

T Proc

T Rpt Rpt Rpt

FlowDown:

SWRR SWFR SWPDR SWCDR SWTRR SWTCR SWFCA SWPCA

SRS SRSIRS

SDDIDD

DBDD

SDDIDD

DBDD

T PlanT Proc

T Rpt Rpt Rpt

System Requirements

Baseline

SUBSYSTEMLEVEL

COMPONENTLEVEL

SYSTEM

LEVEL

System

requirementsallocated tosubsystem

System Allocated Baseline =Subsystem Requirements

Baseline

Subsystem

requirementsallocated to

component

Subsystem Allocated Baseline =Component Requirements

Baseline (e.g., Software Requirements Baseline)

Roll

Up:

ISR

Technical Baselines, Documents, and Reviews (cont)



47

Technical Review ASR SRR SFR SSR PDR CDR TRR TCR FCA SVR PCA ISR

Baseline Document

PRB FRB PFB

FFB PAB FAB PPB

FPB

Concept Papers, etc. F U

System Specification (SS/SRD/SRS) P F U U U

External Interface Requirements Specifications (IRSs) P F U U U

Subsystem Specifications (SSSs) P F U U U

All Other Plans (PMP, SEMP, SDP, HDP, I&TP, QAP, etc.)

P F U U U

Systems Engineering Master Schedule (SEMS) / Integrated Master Plan (IMP)

P F U U U

Systems Engineering Detailed Schedule (SEDS) / Integrated Master Schedule (IMS)

P F U U U

System/Subsystem Design Descriptions (SSDDs) P F U U U

Hardware Requirements Specifications (HRSs) P F U U U

Software Requirements Specifications (SRSs) P F U U U

Internal Interface Requirements Specifications (IRSs) P F U U U

Software Design Descriptions (SDDs) P F U U U

Interface Design Specifications (IDSs)/ Interface Design Descriptions (IDDs)

P F U U U

Database Design Descriptions (DBDDs) P F U U U

Hardware Design Descriptions / Drawings (HDDs) P F U U U

Integration and Verification Plan (IVP) P F U U U

Formal Qualification Test Plan (FQTP) P F U U U

Formal Qualification Test Descriptions (FQTD) P F U U U

Formal Qualification Test Report (FQTR) P F U U

Software Product Specification (SPS) P F U U

Software Version Description (SVD) P F U U

Integration and Verification Report (IVR) P F U

Interim System Review (ISR) Report F

Legend: P = Preliminary; F = Final; U = Update; RB = Requirements Baseline; FB = Functional Baseline; AB = Allocated Baseline; PB = Product Baseline; ASR = Alternative Systems Review; SRR = System Requirements Review; SFR = System Functional Review; SSR = Software Specification Review; PDR = Preliminary Design Review; CDR = Critical Design Review; TRR = Test Readiness Review; TCR = Test Completion Review; FCA = Functional Configuration Audit; SVR = System Verification Review; PCA = Physical Configuration Audit; ISR = Interim System Review. Note: PPB = Preliminary Product Baseline = Developmental Baseline (DB). IRSs = all interface requirements specifications, and IDSs/IDDs = all interface design specifications or descriptions, regardless of which document (IRS/IDS/IDD) contains them.

JOC

Technical Baselines, Documents, and Reviews (cont)



48

System Spec

(Incl IRSs)

Item Spec Software Spec Process Spec

Detail SpecDetail Spec

Material Spec

Detail SpecDetail Spec

SDDs

IDDs

DBDDs

Code

Proc Def Workmanship

Mat’l Def

Inspec Rqmts

Rqmts

Design

Drawings

Workmanship

Manuf Stds

Inspec Rqmts

Rqmts

TLR/ORD

OCD SSS External IRSs

External IDDsDBDD SSDD

HRSs SRSs Internal IRSs

HDDs SDDs Internal IDDs

Rqmts

Design

Rqmts

Design

Rqmts

TLR/ORD

TEMP SSS

System Test Plan

Hardware Test Plan Software Test Plan

Hardware Test Procedures Software Test Procedures

Hardware Test Reports Software Test Reports

Hardware Trouble Reports Software Trouble Reports

IEEE 1220-2005

DIDs, IEEE/EIA J-016, JOC

MIL-STD-961E

DIDs, IEEE/EIA J-016, JOC

Provided with the permission of IEEE from IEEE-1220-2005.

Copyright 2005 IEEE. All rights reserved.

Technical Document Trees



49

SSDD DID

NotesSystem-Wide

Design Decisions3.0

System

Architecture Design4.0

Req Trace5.0

Scope1.0

Ref Docs2.0

Concept ofExecution

4.2

Manual Ops

4.1.X.3SWCIs4.1.X.2

HWCIs4.1.X.1

HWCI Y4.1.X.1.Y

SWCI Y4.1.X.2.Y

MO Y

4.1.X.3.Y

ID

4.1.X.1.Y.1Relationships

4.1.X.1.Y.2

Alloc of Sys Reqs& Des Decisions

4.1.X.1.Y.3

Comp HWResources4.1.X.1.Y.4

Component X4.1.X

ID & Diags4.3.1

Interface X4.3.X

InterfaceDesign

4.3

System Components

4.1

Appxs

SSDD

System/Subsystem Design Description (SSDD)


Data Item Description (DID) DI-IPSC-81432A, 10 August 1999Copyright 2006 Northrop Grumman Corporation

50

Forsberg


USER REQUIREMENTS,

SYSTEM CONCEPT,

VALIDATION PLAN

SYSTEM SPECIFICATION AND

VERIFICATION PLAN

CONFIGURATION ITEM (CI) “DESIGN-TO” SPECIFICATIONS AND

VERIFICATION PLAN

“BUILD-TO” SPECIFICATIONS AND VERIFICATION

PROCEDURES

FABRICATE, ASSEMBLE, CODE

INSPECT/TEST TO “BUILD-TO” SPECIFICATIONS

ASSEMBLE CI’S AND VERIFY TO SPECIFICATIONS

INTEGRATE SYSTEM AND VERIFY TO SPECIFICATIONS

VALIDATE SYSTEM TO USER REQUIREMENTS

DECOMPOSITION

AND DEFINITION

INTEGRATION AND

VERIFICATION

VEE MODEL

Provided with the permission of Kevin Fosberg from

Forsberg, Mooz “Proceedings of the First Annual NCOSE Conference,” 1990, and

Forsberg, Mooz, Cotterman “Visualizing Project Management,” 2000 by John Wiley & Sons, Inc.

JOC Additions

Validation

Verification

Verification

Verification


51

� EIA/IS-632 Systems Engineering

� IEEE 1220-1994, 1220-1998, and 1220-2005 IEEE Trial-Use Standard for Application and Management of the Systems Engineering Process

� ANSI/EIA-632 Processes for Engineering a System

� ISO/IEC 15288 Systems Engineering – System Life Cycle Processes

� ISO/IEC TR 19760 Systems Engineering – A guide for the Application of ISO/IEC 15288 (System Life Cycle Processes)

� IEEE/EIA 12207 Industry Implementation of International Standard ISO/IEC 12207:

� IEEE/EIA 12207.0 Software Life Cycle Processes

� IEEE/EIA 12207.1 Life Cycle Data

� IEEE/EIA 12207.2 Implementation Considerations

� DoD Policy

� DoD 5000.1 The Defense Acquisition System

� DoD 5000.2 Operation of the Defense Acquisition System

� Defense Acquisition Guidebook (formerly DoD 5000.2-R)

� Policy for Systems Engineering in DoD

What is the Systems Engineering Process?


52

EIA/IS-632EIA/IS-632-1994The Systems Engineering Process


PROCESS OUTPUT• Integrated Decision Data Base

- Decision Support Data

- System Functional & Physical Architectures

- Specifications & Baselines• Balanced System Solution

Requirements Analysis• Analyze Missions & Environments• Identify Functional Requirements

• Define/Refine Performance & DesignConstraint Requirements

Functional Analysis / Allocation• Decomposition to Lower-Level Functions

• Allocate Performance and Other LimitingRequirements to Lower-Level Functions

• Define/Refine Functional Interfaces

• Define/Refine/Integrate Functional Architecture

Verification

Synthesis• Transform Architectures (Functional to Physical)

• Define Alternative Product Concepts• Define/Refine Physical Interfaces (Internal/External)

• Define Alternative Product & Process Solutions

Systems Analysis & Control

Requirements Loop

Design Loop

• Select Preferred Alternatives

• Trade-Off Studies• Effectiveness Analysis• Risk Management

• Configuration Management• Interface Management

• Data Management• Performance-Based Progress

Measurement- SEMS- TPM

- Technical Reviews

PROCESS INPUT• Customer Needs/

Objectives• Requirements:

- Mission/Operations

- Measures ofEffectiveness

- Environments- Constraints

• Technology Base• Prior Output Data• Program Decision

Requirements• Requirements from

Tailored Standards and Specifications


53

Requirements Analysis• Define Requirements

• Define Interfaces• Decompose & Derive Requirements

• Define Constraints & Conditions• Define Requirements Architecture

• Establish Requirements Baseline

Functional Analysis / Allocation• Define Functions• Allocate Requirements to Functions

• Define Functional Interfaces• Decompose Functions to Subfunctions

• Allocate Decomposed & Derived Reqsto Subfunctions

• Define Functional Architecture• Develop Functional Flow Block Diagrams

• Establish Functional Baseline

PROCESS OUTPUTS• Requirements, Functional &

Physical Architectures & Baselines

• System, Subsystem &

Component Specs (SSS/SSDDs)• Reqs Verification Matrix

• FCA & PCA Reports

VerificationLoop

PROCESS INPUTS• Customer Needs/

Objectives• Legacy Requirements

• Subject Matter ExpertDefined Requirements

• Technology Base

• Prior Output Data• CDRL Definition

• Doc Standards• EIA/IS-632

• IEEE 1220

• Requirements Architecture• System Spec (SS)

• Interface Specs• Traceable Requirements

• Requirements Baseline

• Functional Architecture

• System/Subsystem Specs (SSS)• Traceable Requirements

• Functional Baseline

Verification Loop:• Develop Verification Framework

• Define Key Performance Parameters• Define Verification Methods

• Develop Requirements Verification Matrix• Trace Requirements Verification Matrix to Test Procedures

• Conduct Functional and Physical Configuration Audits

Synthesis (Design)• Define Subsystems & Components• Allocate Functions & Subfunctions to

Subsystems & Components

• Define Subsystem & Component Reqs• Define Subsystem & Component Interfaces

• Establish Allocated Baseline• Define Physical Architecture

• Develop Physical Flow Block Diagrams• Establish Physical/Product Baseline


• Trade-Off Studies• Configuration Management

• Interface Management• Data Management, etc.


• Trade-Off Studies• Configuration Management

• Interface Management• Data Management, etc.

• Physical Architecture

• Component Specs/SSDDs• Traceable Requirements

• Allocated Baseline• Physical/Product Baseline

Requirements Loop

Design Loop

Fo

rwa

rd E

ng

ine

eri

ng

Re

ve

rse

En

gin

ee

rin

g

Example Application of EIA/IS-632

EIA/IS-632 (cont)

EIA/IS-632-1994 & JOC

Provided with the permission of EIA from EIA/IS-632-1994 and John Clark. Copyright 1995 EIA. All rights reserved.


54

EIA/IS-632-1994


Example of a System Life Cycle

EIA/IS-632 (cont)


55

Product Baseline. .

MS 0

Phase 0 Phase I Phase II Phase III

MS I MS II MS III

Functional Baseline

Allocated Baseline

Technical Management Plan (TMP) Update Update Update

ASR SRR SFR SSR PDR CDR TRR FCA PCA

ENGINEERING CHANGE

REVIEWS

Operational

Requirement

Document

(ORD)

Operational

Requirement

Document

(ORD)

Operational

Requirement

Document

(ORD)

System

Threat

Assessment

System

Threat

Assessment

System

Threat

Assessment

Mission

Need

Statement

Concept System SubsystemsDeficiency

CorrectionMods/Product

Improvements

System Performance Specification

Item Performance Specification

Item Detail Specification

Reassess Threat Reassess Threat Reassess Threat

Preplanned Product Improvement (P3I)

DraftGovernment

Approves

.Developmental

. Conceptual Performance Baseline

PROCESS INPUT

• Customer Needs/

Objectives/

Requirements

. . Mission/

Operations

. . Measures of

Effectiveness

. . Environments

. . Constraints

• Technology Base

• Prior Output Data

• Program Decision

Requirements

• Requirements From

Tailored Standards

and Specifications

Requirements Analysis

• Analyze Missions & Environments

• Identify Functional Requirements

• Define/Refine Performance & Design

Constraint Requirements

Functional Analysis/Allocation

• Decomposition is Lower-Level Functions

• Allocate Performance & Other Limiting

Requirements is Lower-Level Functions

• Define/Refine Functional Interfaces (Internal/External)


Requirements Loop

Systems Analysis

& Control

Design Loop

Synthesis

• Transform Architecture (Functional to Physical)

• Define Alternative Product Concepts

• Define/Refine Physical Interfaces (Internal/External)


PROCESS OUTPUT

• Integrated Decision Data Base

. . Decision Support Data

. . System Functional

Physical Architectures

. . Specifications & Baseline

• Baseline System Solution

Verification

• Select Preferred

Alternatives

• Trade-Off Studies

• Effectiveness Analysis

• Risk Management

• Configuration

M anagement

• Interface M anagement

• Data Management

• Performance-Based

• Progress M easurement

. . SEM S

. . TPM

. . Technical Reviews

PROCESS INPUT

• Customer Needs/

Objectives/

Requirements

. . Mission/

Operations

. . Measures of

Effectiveness

. . Environments

. . Constraints

• Technology Base



Requirements


Tailored Standards

and Specifications


• Analyze M issions & Environments










Requirements Loop

Systems Analysis

& Control

Design Loop

Synthesis





PROCESS OUTPUT







Verification


Alternatives



• Risk Management

• Configuration

Management


• Data M anagement



. . SEMS

. . TPM


PROCESS INPUT

• Customer Needs/

Objectives/

Requirements

. . Mission/

Operations

. . Measures of

Effectiveness

. . Environments

. . Constraints

• Technology Base



Requirements


Tailored Standards

and Specifications












Requirements Loop

Systems Analysis

& Control

Design Loop

Synthesis





PROCESS OUTPUT







Verification


Alternatives



• Risk Management

• Configuration

Management




• Progress Measurement

. . SEMS

. . TPM


PROCESS INPUT

• Customer Needs/

Objectives/

Requirements

. . M ission/

Operations

. . Measures of

Effectiveness

. . Environments

. . Constraints

• Technology Base



Requirements


Tailored Standards

and Specifications












Requirements Loop

Systems Analysis

& Control

Design Loop

Synthesis





PROCESS OUTPUT







Verification


Alternatives



• Risk M anagement

• Configuration

Management




• Progress Measurement

. . SEMS

. . TPM


PROCESS INPUT

• Customer Needs/

Objectives/

Requirements

. . Mission/

Operations

. . Measures of

Effectiveness

. . Environments

. . Constraints

• Technology Base



Requirements


Tailored Standards

and Specifications












Requirements Loop

Systems Analysis

& Control

Design Loop

Synthesis





PROCESS OUTPUT







Verification


Alternatives



• Risk Management

• Configuration

Management





. . SEM S

. . TPM


PEO-TSC

PEO-TSC SEMP Handbook,

TSCBT3HDBK 4810.1Rev 0, 2 August 1999

EIA/IS-632 (cont)

Example Application of EIA/IS-632


56

IEEE 1220-1994

IEEE 1220-1994

PROCESS

INPUTS

RequirementsAnalysis

Requirements

BaselineValidation

FunctionalAnalysis

Functional

Verification

Synthesis

PhysicalVerification

Requirements Baseline

Validated Requirements Baseline

Functional Architecture

Verified Functional Architecture

Physical Architecture

Verified Physical Architecture

Control

PROCESS OUTPUTS

Requirements TradeStudies &

Assessments

Functional TradeStudies &

Assessments

Design TradeStudies &

Assessments

Requirement

& Constraint

Conflicts

Requirement

Trade-offs & Impacts

Decomposition &

Requirement Allocation

Alternatives

Decomposition/Allocation


Design Solution

Requirements &

Alternatives

Design Solution


System

Analysis


The Systems Engineering Process


57

PROCESS

INPUTS


RequirementsVerification

Functional

Analysis

Functional

Verification

Synthesis

DesignVerification

Requirements baseline

Validated requirements baseline

Functional architecture

Verified functional architecture

Physical architecture

Verified physical architecture

Control

PROCESS OUTPUTS

Requirements tradestudies and

assessments

Functional tradestudies and assessments

Design trade

studies and assessments

Requirement

and constraint

conflicts

Requirement

trade-offs and impacts

Decomposition

and requirement

allocation alternatives

Decomposition/

allocation trade-offs

and impacts

Design solution

requirements and

alternatives

Design solution

trade-offs

and impacts

System

Analysis

IEEE 1220-1998

IEEE 1220-1998




58

PROCESS

INPUTS


RequirementsValidation

Functional

Analysis

Functional

Verification

Synthesis

DesignVerification







Control

PROCESS OUTPUTS


assessments


Design trade


Requirement

and constraint

conflicts

Requirement


Decomposition

and requirement


Decomposition/


and impacts

Design solution

requirements and

alternatives

Design solution

trade-offs

and impacts

System

Analysis

IEEE 1220-2005

IEEE 1220-2005




59

AcquisitionProcess

SupplyProcess

Acquisition& Supply

Technical Evaluation

SystemsAnalysisProcess

SystemVerification

Process

RequirementsValidationProcess

End ProductsValidationProcess

Technical Management

PlanningProcess

AssessmentProcess

ControlProcess

SystemDesign

RequirementsDefinition Process

Solution DefinitionProcess

ProductRealization

ImplementationProcess

Transition to UseProcess

Plans,Directives& Status

Outcomes&

Feedback

Requirements

Designs

Products

AcquisitionRequest

SystemProducts

ANSI/EIA-632

ANSI/EIA-632-1998

Provided with the permission of EIA from ANSI/EIA-632-1998. Copyright 1999 EIA. All rights reserved.

Relationship of Processes for Engineering a System


60

ISO/IEC 15288

ISO/IEC 15288


The System Life Cycle Processes


61

ISO/IEC 15288 (cont)

ISO/IEC 15288


Agreement, Enterprise, Project and Technical Processes in

Co-Operating Organizations


62

ISO/IEC 15288


Relationship Between ISO/IEC 15288 and ISO/IEC 12207



63

ISO/IEC TR 19760

Application of Technical Processes to Engineer a System of Interest

Provided with the permission of ANSI from ISO/IEC TR 19760. Copyright 2003 ISO/IEC. All rights reserved.

ISO/IEC TR 19760


64

IEEE/EIA 12207

IEEE/EIA 12207

Provided with the permission of IEEE from IEEE/EIA 12207. Copyright 1998 IEEE. All rights reserved.

Life Cycle Processes


65

DoD 5000

DOD 5000.2

DoD 5000.2, 12 May 2003

IOCBA

Technology Development

System Development& Demonstration

Production &

Deployment

Systems Acquisition

Operations & Support

C

User Needs &

Technology Opportunities

Sustainment

� Process entry at Milestones A, B, or C

� Entrance criteria met before entering phase

� Evolutionary Acquisition or Single Step to Full Capability

FRP DecisionReview

FOC

LRIP/IOT&EDesignReadiness Review

Pre-Systems Acquisition

(ProgramInitiation)

Concept Refinement

ConceptDecision


66

DOD 5000.2

DoD 5000 (cont)

D

O

T

M

L

P

F

MS A

Analysis of

Materiel

Approaches

Demo

Demo

Demo

AoA

TechnologyDevelopment

DABJROC

JROC

Increment 3Increment 3


MS B

MS C

MS B

MS B MS C

MS C

- Materiel -

Process

DOTLPF

Process

Functional

Area

Analysis

Functional Area

Functional Concept

Integrated Architecture

Overarching Policy

NSS/NMS/Joint vision

Joint Concept of Operations

Feedback

ICD

CDD

CPD

ConceptRefinement

CD JROC DAB

DAB


DoD 5000.2, 12 May 2003

Requirements and Acquisition Process

AoA – Analysis of AlternativesICD – Initial Capabilities Document

CDD – Capability Development DocumentCPD – Capability Production DocumentCD – Concept Decision

DAB – Defense Acquisition BoardMS – Milestone

NSS – National Security SystemsJROC – Joint Requirements Oversight Council

DOTMLPF – Doctrine, Organization, Training, Material, Leadership, Personnel, Facilities.


67

Policy for Systems Engineering in DoD


68

Example of Process Mapping

Process Groups:


• Project Planning

• Project Control

• Decision Management

• Risk Management


• Configuration Management

• Quality Assurance

• Assessment

Design, Production & Evaluation

• Requirements Development

• Architectural Design

• Design Implementation

• Integration

• Transition

• Operations

• Disposal

• Validation

• Verification

• Systems Analysis

Acquisition

• Procurement

• Supply

• Subcontract Management

Not Addressed

SW- SE- ISO EIA EIA CMM CMM CMMI 15288 632 731.1

SPP PA-12 PP PP PP FA2.1

SPTO PA-11 PMC CP CP FA2.2

ISM - IPM DM - -

RM PA-10 RM RM - FA2.5

IC - - - - -

SCM PA-09 CM CM - FA2.6,2.7

SQA,SQM PA-08 PPQA QM - FA2.8

QPM - QPM,MA AP AP -

RqM PA-06,02 RqM,RD SR,RA RDP FA1.1

SPE PA-03 TS AD SDP FA1.2

- - CAR I IP FA1.3

PR PA-05 PI Int - FA1.5

- - - Trn TP -

- - - Op - -

- - - Dis - -

- PA-07 VAL Val RVP,EPVP FA1.7

- PA-07 VER Ver SVP FA1.6

- PA-01 DAR SAP FA1.4

- - - Acq Acq -

- PA-18 SAM Sup Sup FA2.4

SSM - - -

OPF/D, TP PA04,13,14 OPF/D,OT, EEM,IM, MT FA2.3,3.1,3.2

PCM,TCM,DP 15,16,17 OPP,OID SLCM,RESM 3.3,3.4

JOC


69

5646Total Score

√NAVSEA PEO-TSC - 2001

√√INCOSE – 2000

√

√

√

√

IEEE

1220-1994

√√NAVSEA PEO-TSC – 1999-2000

√√√OSD OSJTF – 2001

√√NAVAIR SE – 2003

√NAVSEA SE – 2002

√√√DoD Acquisition Guide - 2004

√NAVSEA PMS 465 CEC – 1999

√EIA/IS-731 – 1999

√DSMC/DMU – 1999 & 2001

IEEE

1220-1998

ANSI/EIA-

632-1998

EIA/IS-

632-1994

Standard

User

Used ScorecardJOC

Later users generally tend to reference the later standards


70

Scope and Detail of SE Standards

MIL-STD-499B EIA/IS 632

ISO/IEC 15288

EIA 632

IEEE 1220L

evel

of

Deta

il

Breadth of Scope

Provided with the permission of Sarah Sheard from

Sheard, Sarah A., Software Productivity Consortium (SPC), and

Lake, Jerome G., Systems Management international (SMi),

Systems Engineering Standards and Models Compared, July 1998.

Sheard and Lake


71

Scope and Detail of SE Standards (cont)ISO/IEC TR 19760

Provided with the permission of ANSI from ISO/IEC TR 19760. Copyright 2003 ISO/IEC. All rights reserved.


72

Overview (cont)



� Break





73

Overview (cont)



� Break


� EIA/IS-632

� IEEE 1220-2005

� ANSI/EIA-632

� ISO/IEC 15288

� ISO/IEC TR 19760

� IEEE/EIA 12207

� DoD Policy


� Appendix - Acronyms


74

Standards Overviews

� EIA/IS-632 Systems Engineering

� IEEE 1220-2005

� ANSI/EIA-632

� ISO/IEC 15288


� IEEE/EIA 12207

� DoD Policy


75

EIA/IS-632


Key Terms EIA/IS-632-1994


76

EIA/IS-632 (cont)

EIA/IS-632-1994


Systems Engineering Life Cycle Application


77

EIA/IS-632EIA/IS-632-1994The Systems Engineering Process


PROCESS OUTPUT• Integrated Decision Data Base

- Decision Support Data

- System Functional & Physical Architectures

- Specifications & Baselines• Balanced System Solution

Requirements Analysis• Analyze Missions & Environments• Identify Functional Requirements

• Define/Refine Performance & DesignConstraint Requirements

Functional Analysis / Allocation• Decomposition to Lower-Level Functions

• Allocate Performance and Other LimitingRequirements to Lower-Level Functions

• Define/Refine Functional Interfaces


Verification

Synthesis• Transform Architectures (Functional to Physical)

• Define Alternative Product Concepts• Define/Refine Physical Interfaces (Internal/External)



Requirements Loop

Design Loop

• Select Preferred Alternatives

• Trade-Off Studies• Effectiveness Analysis• Risk Management

• Configuration Management• Interface Management

• Data Management• Performance-Based Progress

Measurement- SEMS- TPM

- Technical Reviews

PROCESS INPUT• Customer Needs/

Objectives• Requirements:

- Mission/Operations

- Measures ofEffectiveness

- Environments- Constraints

• Technology Base• Prior Output Data• Program Decision

Requirements• Requirements from

Tailored Standards and Specifications


78

EIA/IS-632-1994


Example of a System Life Cycle

EIA/IS-632 (cont)


79

SEDS

Calendar Driven (Date Driven or Time Coincidental)

Required Events, Milestones, and Activities

Measureable Dates or Periods

Captures All Required Events, Milestones, and Activities

Earned Value Management (EVM)

BCWS

BCWP

ACWP


Metrics

SV

CV

Notes:

- - - - - JOC Additions

Systems Engineering Master Schedule (SEMS) = Integrated Master Plan (IMP)

Systems Engineering Detailed Schedule (SEDS) = Integrated Master Schedule (IMS)

Key Elements of a Systems Engineering Management Plan (SEMP)

EIA/IS-632 (cont)

EIA/IS-632-1994



80

EIA/IS-632-1994


Example System Configuration

EIA/IS-632 (cont)


81

EIA/IS-632-1994


EIA/IS-632 (cont)



82

Standards Overviews (cont)

� EIA/IS-632

� IEEE 1220-2005 IEEE Standard for Application and Management of the Systems Engineering Process

� ANSI/EIA-632

� ISO/IEC 15288


� IEEE/EIA 12207

� DoD Policy


83

PROCESS

INPUTS


RequirementsValidation

Functional

Analysis

Functional

Verification

Synthesis

DesignVerification







Control

PROCESS OUTPUTS


assessments


Design trade


Requirement

and constraint

conflicts

Requirement


Decomposition

and requirement


Decomposition/


and impacts

Design solution

requirements and

alternatives

Design solution

trade-offs

and impacts

System

Analysis

IEEE 1220-2005

IEEE 1220-2005




84

IEEE 1220-2005 (cont)


Requirements Analysis Process IEEE 1220-2005


85

Requirements Validation

IEEE 1220-2005 (cont)


IEEE 1220-2005


86

Functional Analysis Process

IEEE 1220-2005 (cont)

IEEE 1220-2005



87

Functional Verification

IEEE 1220-2005 (cont)IEEE 1220-2005



88

Synthesis Process

IEEE 1220-2005 (cont)

IEEE 1220-2005



89

Design Verification

IEEE 1220-2005 (cont)

IEEE 1220-2005



90

Systems Analysis Process

IEEE 1220-2005 (cont)

IEEE 1220-2005



91

Control Process

IEEE 1220-2005 (cont)IEEE 1220-2005



92

Systems Engineering Environment within an Enterprise

IEEE 1220-2005 (cont)

IEEE 1220-2005



93

Hierarchy of Elements within a System

IEEE 1220-2005 (cont)IEEE 1220-2005



94

Basic Building Blocks of a System

IEEE 1220-2005 (cont)

IEEE 1220-2005



95

Life Cycle Process Definition

IEEE 1220-2005 (cont)

IEEE 1220-2005



96

The System Breakdown Structure (SBS)

IEEE 1220-1998IEEE 1220-1998



97

The Specification Tree

IEEE 1220-2005 (cont)IEEE 1220-2005



98

IEEE 1220-2005

Typical System Life Cycle

Simultaneous Engineering of Life Cycle Processes

IEEE 1220-2005 (cont)



99

IEEE 1220-2005

IEEE 1220-2005 (cont)



IEEE Building Block Structure

100

IEEE 1220-2005 (cont)

ISO/IEC 15288 Figure D.3 System of Interest Structure

IEEE 1220-2005



101

IEEE 1220-2005 (cont)

ISO/IEC 15288 Breakdown Part of a Building Block

IEEE 1220-2005



102

IEEE 1220-2005 (cont)

ISO/IEC 15288 – IEEE 1220 Comparative Nomenclature

IEEE 1220-2005



103

ISO/IEC 15288 and IEEE 1220 Process Nomenclature

IEEE 1220-2005 (cont)

IEEE 1220-2005



104

IEEE 1220-2005 (cont)

Scope Comparison Areas Across Typical System Life Cycle Stages

IEEE 1220-2005



105


� EIA/IS-632

� IEEE 1220-2005

� ANSI/EIA-632 Processes for Engineering a System

� ISO/IEC 15288


� IEEE/EIA 12207

� DoD Policy


106

AcquisitionProcess

SupplyProcess

Acquisition& Supply


SystemsAnalysisProcess

SystemVerification

Process

RequirementsValidationProcess

End ProductsValidationProcess


PlanningProcess

AssessmentProcess

ControlProcess

SystemDesign

RequirementsDefinition Process

Solution DefinitionProcess

ProductRealization

ImplementationProcess

Transition to UseProcess

Plans,Directives& Status

Outcomes&

Feedback

Requirements

Designs

Products

AcquisitionRequest

SystemProducts

ANSI/EIA-632

ANSI/EIA-632-1998


Relationship of Processes for Engineering a System


107

ANSI/EIA-632 (cont)

Requirements for Engineering a System ANSI/EIA-632-1998



108

ANSI/EIA-632 (cont)

Application of this Standard

ANSI/EIA-632-1998

Provided with the permission of EIA from ANSI/EIA-632-1998. Copyright 1999 EIA. All rights reserved. Copyright 2006 Northrop Grumman Corporation

109

ANSI/EIA-632 (cont)

Acquisition and Supply Processes

ANSI/EIA-632-1998


110

ANSI/EIA-632 (cont)

Technical Management Processes ANSI/EIA-632-1998


111

ANSI/EIA-632 (cont)

System Design Processes ANSI/EIA-632-1998


112

ANSI/EIA-632 (cont)

Product Realization Processes ANSI/EIA-632-1998



113

ANSI/EIA-632 (cont)

Technical Evaluation ProcessesANSI/EIA-632-1998


114

ANSI/EIA-632 (cont)

Context for Application of this StandardANSI/EIA-632-1998


115

ANSI/EIA-632 (cont)

System Concept

ANSI/EIA-632-1998


116

ANSI/EIA-632 (cont)

Building Block

ANSI/EIA-632-1998



117

Building Block Role - Specifications

ANSI/EIA-632 (cont)

ANSI/EIA-632-1998


118

Building Block Role - Teamwork

ANSI/EIA-632 (cont)

ANSI/EIA-632-1998


119

Building Block Role – Technical Reviews

ANSI/EIA-632 (cont)

ANSI/EIA-632-1998


120

ANSI/EIA-632 (cont)

Forming a System StructureANSI/EIA-632-1998


121

ANSI/EIA-632 (cont)

Example System Structure ANSI/EIA-632-1998


122

ANSI/EIA-632 (cont)

Example Top Down Development ANSI/EIA-632-1998


123

ANSI/EIA-632 (cont)

Example Bottom-Up Realization ANSI/EIA-632-1998


124

ANSI/EIA-632 (cont)

Enterprise-Based Life Cycle Phases ANSI/EIA-632-1998


125

ANSI/EIA-632 (cont)

Approaches for Unprecedented and Precedented End Products

ANSI/EIA-632-1998


126

ANSI/EIA-632 (cont)

Requirement RelationshipsANSI/EIA-632-1998


127

ANSI/EIA-632 (cont)

Role of Specified Requirements ANSI/EIA-632-1998


128

ANSI/EIA-632 (cont)

Development of Enabling ProductsANSI/EIA-632-1998


129

ANSI/EIA-632 (cont)

Relationship Between Requirement Types and Elements of this StandardANSI/EIA-632-1998


130


� EIA/IS-632

� IEEE 1220-2005

� ANSI/EIA-632

� ISO/IEC 15288 Systems Engineering – System Life Cycle Processes


� IEEE/EIA 12207

� DoD Policy


131

ISO/IEC 15288

ISO/IEC 15288The System Life Cycle Processes

Provided with the permission of ANSI from ISO/IEC 15288. Copyright 2003 ISO. All rights reserved. Copyright 2006 Northrop Grumman Corporation

132


ISO/IEC 15288

Agreement, Enterprise, Project and Technical Processes in

Co-Operating Organizations


133


ISO/IEC 15288

An Example of Stages, their Purposes, and

Major Decision Gates


134

ISO/IEC 15288 (cont)ISO/IEC 15288

System Interaction with Typical Enabling Systems


135

ISO/IEC 15288Relationship Between ISO/IEC 15288 and ISO/IEC 12207



136

ISO/IEC 15288


Relationship Between ISO/IEC 15288 and ISO/IEC 12207(cont)


137

ISO/IEC 15288


Relationship Between ISO/IEC 15288 and ISO/IEC 12207 (cont)


138

ISO/IEC 15288

Operational Environment and Enabling Systems



139

ISO/IEC 15288Typical System of Systems Environment



140

ISO/IEC 15288

System and System Element Relationship



141

ISO/IEC 15288System of Interest Structure



142

ISO/IEC 15288System and Project Hierarchies



143


� EIA/IS-632

� IEEE 1220-2005

� ANSI/EIA-632

� ISO/IEC 15288

� ISO/IEC TR 19760 Guide to ISO/IEC 15288

� IEEE/EIA 12207

� DoD Policy


144

Context of the International StandardISO/IEC TR 19760

ISO/IEC TR 19760

Copyright 2006 Northrop Grumman CorporationProvided with the permission of ANSI from ISO/IEC TR 19760.

Copyright 2003 ISO. All rights reserved.

145

Role of International Standard Processes

ISO/IEC TR 19760 (cont)ISO/IEC TR 19760

Provided with the permission of ANSI from ISO/IEC TR 19760. Copyright 2003 ISO. All rights reserved. Copyright 2006 Northrop Grumman Corporation

146

Use of Agreement ProcessesISO/IEC TR 19760

ISO/IEC TR 19760 (cont)



147

Concept of UseISO/IEC TR 19760




148

Example Aircraft System of Interest and its Enabling Systems

ISO/IEC TR 19760




149

Hierarchy of ProjectsISO/IEC TR 19760



150

Example Process Inputs and Outputs

ISO/IEC TR 19760




151

Recursive Application of Processes ISO/IEC TR 19760




152

Iterative Application of Processes

ISO/IEC TR 19760




153

Application of Technical Processes to Engineer a System of InterestISO/IEC TR 19760



154

Application of Processes to Satisfy an AgreementISO/IEC TR 19760



155


� EIA/IS-632

� ANSI/EIA-632

� IEEE 1220-2005

� ISO/IEC 15288



� IEEE/EIA 12207.0 Software Life Cycle Processes

� IEEE/EIA 12207.1 Life Cycle Data

� IEEE/EIA 12207.2 Implementation Considerations

� DoD Policy


156

IEEE/EIA 12207

IEEE/EIA 12207

Provided with the permission of IEEE from IEEE/EIA 12207. Copyright 1998 IEEE. All rights reserved.

Life Cycle Processes


157

IEEE/EIA 12207 (cont)

IEEE/EIA 12207

An Example of the Application of the International Standard


158

Software Life Cycle Processes – Roles and Relationships


IEEE/EIA 12207


159

Software Life Cycle Processes, Views and Activities

IEEE/EIA 12207 (cont)IEEE/EIA 12207


160

The Processes and their Interactions


IEEE/EIA 12207


161

Relationship of Primary Life Cycle Processes and Roles


IEEE/EIA 12207


162

Acquisition Process

IEEE/EIA 12207 (cont)IEEE/EIA 12207


163

Supply Process


IEEE/EIA 12207


164

Development Process


IEEE/EIA 12207


165

Operation Process


IEEE/EIA 12207


166

Maintenance Process


IEEE/EIA 12207


167

Key Features of Three Development Strategies


IEEE/EIA 12207


168

Sample Risk Analysis for Determining the Appropriate

Development Strategy


IEEE/EIA 12207


169

One Possible Way of Applying IEEE 12207 to the

Waterfall Development Strategy


IEEE/EIA 12207


170


Incremental Development Strategy


IEEE/EIA 12207


171


Evolutionary Development Strategy


IEEE/EIA 12207


172

One Possible Way of Applying IEEE 12207 to a

Reengineering Project


IEEE/EIA 12207


173

Categories to be Used for Classifying Problems in Software Products


IEEE/EIA 12207


174

Priorities to be Used for Classifying Problems


IEEE/EIA 12207


175

Life Cycle Processes References


IEEE/EIA 12207


176

Information Item Matrix


IEEE/EIA 12207


177


� EIA/IS-632

� ANSI/EIA-632

� IEEE 1220-2005

� ISO/IEC 15288



� DoD Policy

� DoD 5000.1 The Defense Acquisition System

� DoD 5000.2 Operation of the Defense Acquisition System

� Interim Defense Acquisition Guidebook (formerly DoD 5000.2-R)

� Policy for Systems Engineering in DoD

� DoD Architecture Framework (DoDAF)


178

DoD 5000

DOD 5000.2

DoD 5000.2, 12 May 2003

IOCBA

Technology Development

System Development& Demonstration

Production &

Deployment

Systems Acquisition

Operations & Support

C

User Needs &

Technology Opportunities

Sustainment

� Process entry at Milestones A, B, or C

� Entrance criteria met before entering phase

� Evolutionary Acquisition or Single Step to Full Capability

FRP DecisionReview

FOC

LRIP/IOT&EDesignReadiness Review

Pre-Systems Acquisition

(ProgramInitiation)

Concept Refinement

ConceptDecision


179

DOD 5000.2

DoD 5000 (cont)

D

O

T

M

L

P

F

MS A

Analysis of

Materiel

Approaches

Demo

Demo

Demo

AoA

TechnologyDevelopment

DABJROC

JROC



MS B

MS C

MS B

MS B MS C

MS C

- Materiel -

Process

DOTLPF

Process

Functional

Area

Analysis

Functional Area

Functional Concept

Integrated Architecture

Overarching Policy

NSS/NMS/Joint vision

Joint Concept of Operations

Feedback

ICD

CDD

CPD

ConceptRefinement

CD JROC DAB

DAB


DoD 5000.2, 12 May 2003

Requirements and Acquisition Process

AoA – Analysis of Alternatives

ICD – Initial Capabilities DocumentCDD – Capability Development Document

CPD – Capability Production DocumentCD – Concept Decision

DAB – Defense Acquisition BoardMS – MilestoneNSS – National Security Systems

JROC – Joint Requirements Oversight Council DOTMLPF – Doctrine, Organization, Training, Material, Leadership, Personnel,

Facilities.


180

Policy for Systems Engineering in DoD


181

DoD and INCOSE SE Definitions

� DoD

� DoD 5000.1

� DoD 5000.2

� Defense Acquisition Guidebook (DAG)*

� SECNAVINST 5000.2C

� Defense Acquisition University (DAU/DSMC)

� Acquisition Knowledge Sharing System (AKSS)

� Naval Systems Engineering Guide

� INCOSE

* Contains the formal DoD Definition quoted verbatum from EIA/IS-632-1994


182

DoD 5000.1, 5000.2, DAG (former 5000.2-R)

� Acquisition programs shall be managed through the application of a systems engineering approach that optimizes total system performance and minimizes total ownership costs. A modular open-systems approach shall be employed, where feasible. (DoD 5000.1 and Defense Acquisition Guidebook).

� Effective sustainment of weapon systems begins with the design and development of reliable and maintainable systems through the continuous application of a robust systems engineering methodology. (DoD INST 5000.2 and Defense Acquisition Guidebook).

� All programs responding to a capabilities or requirements document, regardless of acquisition category, shall apply a robust SE approach that balances total system performance and total ownership costs within the family-of-systems, systems-of-systems context. Programs shall develop a Systems Engineering Plan (SEP) for Milestone Decision Authority approval in conjunction with each Milestone review, and integrated with the Acquisition Strategy. This plan shall describe the program's overall technical approach, including processes, resources, metrics, and applicable performance incentives. It shall also detail timing, conduct, and success criteria of technical reviews. (Defense Acquisition Guidebook).


183

Defense Acquisition Guidebook (cont)

� The overarching process that a program team applies to transition from a stated capability need to an operationally effective and suitable system. Systems engineering encompasses the application of systems engineering processes across the acquisition life cycle (adapted to each and every phase) and is intended to be the integrating mechanism for balanced solutions addressing capability needs, design considerations and constraints, as well as limitations imposed by technology, budget, and schedule. The systems engineering processes are applied early in concept definition, and then continuously throughout the total life cycle.


184

Defense Acquisition Guidebook (cont)� An interdisciplinary approach or a structured, disciplined, and

documented technical effort to simultaneously design and develop systems products and processes to satisfy the needs of the customer. Systems engineering transforms needed operational capabilities into an integrated system design through concurrent consideration of all Lifecycle needs. As systems become larger and more complex, the design, development, and production of a system or system-of-systems requires the integration of numerous activities and processes. Systems engineering is the approach to coordinate and integrate all acquisition Lifecycle activities. Systems engineering integrates diverse technical management processes to achieve an integrated systems design. Although numerous definitions exist, this chapter adopts the following formal definition, adapted from EIA/IS 632, Processes for Engineering a System:

Systems engineering is an interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and total Lifecycle balanced set of system, people, and process solutions that satisfy customer needs. Systems engineering is the integrating mechanism across the technical efforts related to the development, manufacturing, verification, deployment, operations, support, disposal of, and user training for systems and their life cycle processes. System engineering develops technical information to support the program management decision-making process. For example, systems engineers manage and control the definition and management of the system configuration and the translation of the system definition into work breakdown structures.


185

Defense Acquisition Guidebook (cont)

� Systems engineering provides a systematic set of processes to help coordinate and integrate activities throughout the life cycle of the system. Systems engineer technical framework to enable sound decision making relative to trade studies am system performance, risk, cost, and schedule. The successful implementation of proven, disciplined systems engineering processes results in a total system solution that is-

� Robust to changing technical, production, and operating environments;

� Adaptive to the needs of the user; and � Balanced among the multiple requirements, design

considerations, design constraints, and program budgets.


186

� Systems engineering focuses on defining user needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation to achieve the total capability. It includes the hardware, software and human operators, maintainers and support personnel. It also focuses on individual systems and includes system of systems (SoS) and/or family of systems (FoS) considerations. PMs shall employ a comprehensive, structured, integrated and disciplined systems engineering approach to the life-cycle design of weapons, information technology, and support systems. (SECNAVINST 5000.2C)

SECNAVINST 5000.2C


187

� An interdisciplinary engineering management process that evolvesand verifies an integrated, life-cycle balanced set of system solutions that satisfy customer needs. (DAU/DSMC SE Fundamentals, January 2001).

� The integrating mechanism across the technical efforts related to the development, manufacturing, verification, deployment, operations, support, disposal of, and user training for systems and their life cycle processes. Systems engineering develops technical information to support the program management decision-making process. For example, systems engineers manage and control the definition and management of the system configuration and the translation of the system definition into work breakdown structures. (DAU/DSMC Integrated Defense Acquisition, Technology and Logistics Life Cycle Management Framework, December 2004)

� Systems Engineering Plan (SEP) (required at each milestone) is acomprehensive, living document that defines the program’s systems engineering activities, addressing both government and contractor technical activities and responsibilities. (DAU/DSMC Integrated Defense Acquisition, Technology and Logistics Life Cycle Management Framework, December 2004).

DAU/DSMC


188

AKSS and Naval SE Guide

� The design and management of a total system which includes hardware and software, as well as other system life-cycle elements. A structured, disciplined, and documented technical effort through which systems products and processes are simultaneously defined and developed. SE is most effectively implemented as part of an overall integrated product and process development effort using multidisciplinary teamwork. (Acquisition Knowledge Sharing System, based on DoD 5000 series)

� None (Naval Systems Engineering Guide, October 2004)


189

INCOSE SE Handbook

� An interdisciplinary approach and means to enable the realization of successful systems. (INCOSE Systems Engineering Handbook, Version 2a)


190

DoD Architecture Framework (DoDAF) Implementation

Who needs to Interoperate to

whom?

What activities are

performed at each node?

Operational Architecture

• What is the operational concept?

• What are the operational requirements?

• What is the sequence of operations?

What does each

system do?

What are the

interface standards?

What are the

dependencies?

• What functions are each system in the

FoS required to do?

• What are the functional dependencies

between systems?

• What data (content, latency, etc.) must be

provided by systems to systems in the FoS?

• What are the communication and

interface protocols and standards?

System Architecture

Technical Architecture

Interoperability is not Improved by

Non-Standard Implementation of Architectures

Interoperability is not Improved by

Non-Standard Implementation of Architectures

� Problem

� Lack of standards for architectural terms

� Architects developing unique terminology

� Difficult if not impossible to compare architectures

� Lack of established Governance policy

� Solution

� Every architecture should be constructed from common terms, forming the elemental building blocks of the architecture

� Standardized architectural elements

� Working with Navy and Joint community to establish Governance policy

� Provide Guidance to ensure compliance with DoD integrated architecture policies

� Ensure NIA products are compliant with DoD Architecture Directives and Joint Integrated Architectures

Issues Addressed by an Architecture

Mr. Nehal Shaw, ASN RDA Cheng, NAVSEA Information Exchange, 16 August 2005 Copyright 2006 Northrop Grumman Corporation

191

Architecture Requirements/Policy

� DoD Architecture Framework Document

� Provides basis for developing standardized architecture views and products required by DOD, CJCS, and SECNAV policy documents

� CJCSI 3170.01E

� DoD 5000.1 and DoD 5000.2

� Establishes DoD acquisition policy

� Requires select integrated architecture views at each milestone

� Content and Scope of architecture products used is determined by MDA/PM

� Requires the development of integrated architecture products for supporting acquisition documentations:

� Joint Capability Integration and Development System (JCIDS)

� Capability gap and redundancy analysis

� CJCSI 6212.01C

� Requires architecture products be used in the J-6 interoperability and supportability certification process

� Specifies which architecture products are required for the ICD, CDD, and CPD

� SECNAV INST 5000.2C

� Establishes DON acquisition policy

� Directs the PEO/PM to develop mission integrated architectures in support of the CDD/CPD process

� Directs ASN (RD&A) CHENG to assist the PMs in the development of operational and system architectural views.

NUMBER 5000.2

May 12, 2003

USD(AT&L)

SUBJECT: Operation of the Defense Acquisition System

References:

(a) DoD Instruction 5000.2, “Operation of the Defense Acquisition System,” April 5, 2003

(hereby canceled) (b) DoD 5000.2-R, “Mandatory Procedures for Major Defense Acquisition Programs (MDAPs)

and Major Automated Information System (MAIS) Acquisition Programs,” April 5, 2002

(hereby canceled)

(c) DoD Directive 5000.1, “The Defense Acquisition System,” May 12, 2003

Error! Reference source not found. through Error! Reference source not found., see

enclosure 1

1. PURPOSE

This Instruction:

1.1. Reissues reference (a) and cancels reference (b).

1.2. Implements reference (c), the guidelines of references Error! Reference source not

found. and Error! Reference source not found., and current laws.

1.3. Establishes a simplified and flexible management framework for translating mission

needs and technology opportunities, based on approved mission needs and requirements, into

stable, affordable, and well-managed acquisition programs that include weapon systems and

automated information systems (AISs).

1.4. Consistent with statutory requirements and reference (c), authorizes Milestone

Decision Authorities (MDAs) to tailor procedures to achieve cost, schedule, and performance

goals.

2. APPLICABILITY AND SCOPE

This Instruction applies to:

2.1. The Office of the Secretary of Defense, the Military Departments, the Chairman of

the Joint Chiefs of Staff (Joint Staff), the Combatant Commands, the Office of the Inspector

General of the Department of Defense, the Defense Agencies, DoD Field Activities, and all other

organizational entities within the Department of Defense (hereafter referred to collectively as

“the DoD Components”).

2.2. All defense technology projects and acquisition programs. Some requirements, where

stated, apply only to Major Defense Acquisition Programs (MDAPs) and Major Automated

Information System (MAIS) programs.

NUMBER 5000.1

May 12, 2003

USD(AT&L)

SUBJECT: The Defense Acquisition System

References:

(a) DoD Directive 5000.1, “The Defense Acquisition System,” October 23, 2000 (hereby

canceled)

(b) DoD Instruction 5000.2, “Operation of the Defense Acquisition System,” May 12, 2003

(c) DoD 5025.1-M, “DoD Directives System Procedures,” current edition

(d) Title 10, United States Code, “Armed Forces”

(e) Section 2350a of title 10, United States Code, “Cooperative Research and Development

Projects: Allied Countries”

(f) Section 2751 of title 22, United States Code, “Need for international defense cooperation

and military export controls; Presidential waiver; report to Congress; arms sales policy”

(g) Section 2531 of title 10, United States Code, “Defense memoranda of understanding and

related agreements”

(h) Federal Acquisition Regulation (FAR), current edition

(i) Section 1004, Public Law 107-314, “Bob Stump National Defense Authorization Act for

Fiscal Year 2003,” “Development and Implementation of Financial Management Enterprise

Architecture”

(j) DoD Directive 8500.1, “Information Assurance (IA),” October 24, 2002

(k) DoD Directive 4630.5, “Interoperability and Supportability of Information Technology (IT)

and National Security Systems (NSS),” January 11, 2002

(l) DoD Directive 2060.1, “Implementation of, and Compliance with, Arms Control

Agreements,” January 9, 2001

1. PURPOSE

This Directive:

1.1. Reissues reference (a) and authorizes publication of reference (b).

1.2. Along with reference (b), provides management principles and mandatory policies

and procedures for managing all acquisition programs.

2. APPLICABILITY AND SCOPE

2.1. This Directive applies to the Office of the Secretary of Defense, the Military

Departments, the Chairman of the Joint Chiefs of Staff, the Combatant Commands, the Office of

the Inspector General of the Department of Defense, the Defense Agencies, the DoD Field

Activities, and all organizational entities within the Department of Defense (hereafter

collectively referred to as "the DoD Components").

2.2. The policies in this Directive apply to all acquisition programs.

DoD Architecture Framework

Working Group

DoD Architecture Framework

Version 1.0

Volume I: Definitions and Guidelines

15 January 2003

Sys

tem

s

Tech

nical

Operational

Sys

tem

s

Tech

nical

Operational


192

Architecture Views ��Acquisition Documents

XXXXXXXIntegrated

Architecture

DODAF

44CRD (NR-KPP)

44CRD (I-KPP)

XXXXXXXXXCPD NR-KPP

XXXXXXXXXCDD NR-KPP

XICD

CJCSI 6212.01

444CRD

3XXXXXXXXCPD

2XXXXXXXXCDD

XICD

CJCSM 3170.01

No Product Requirements

CJCSI 3170.01

XXXXXXXXXISP NR-KPP

XXXXXXXXXX1XISP

DODI 4630.8

No Product

Requirements

DODD 4630.5

No Product

Requirements

DODI 5000.2


DODD 5000.1

TV-1SV-

10cSV-6SV-5SV-4SV-2SV-1

OV-

6cOV-5OV-4OV-3OV-2OV-1AV-2AV-1POLICY

XXXXXXXIntegrated

Architecture

DODAF

44CRD (NR-KPP)

44CRD (I-KPP)

XXXXXXXXXCPD NR-KPP

XXXXXXXXXCDD NR-KPP

XICD

CJCSI 6212.01

444CRD

3XXXXXXXXCPD

2XXXXXXXXCDD

XICD

CJCSM 3170.01


CJCSI 3170.01

XXXXXXXXXISP NR-KPP

XXXXXXXXXX1XISP

DODI 4630.8

No Product

Requirements

DODD 4630.5

No Product

Requirements

DODI 5000.2


DODD 5000.1

TV-1SV-

10cSV-6SV-5SV-4SV-2SV-1

OV-

6cOV-5OV-4OV-3OV-2OV-1AV-2AV-1POLICY

Legend:

X - Required Architecture Product

1 - Acronym List

2 - Draft Information Technology (IT) Standards Profile generated by DoD IT Standards Registry (DISR)

3 - Final IT Standards Profile generated by DoD IT Standards Registry (DISR)

4 - Required for legacy Capstone Requirements Documents and Capstone Requirements Document

updates directed by the Joint Requirements Oversight Council.


193

Major Points of this Brief

� The word architecture is a synonym for design, structure, or synthesis.

� The architecture process (e.g., design process) is a sub-process of the Systems Engineering (SE) process.

� Architectural Engineering is a sub-discipline of SE. Architecture Engineers are a specialized type of Systems Engineers.

� Architecture products (views) are by-products of the SE process. They are NOT fore-products.

� Architecture products are nothing new. They have been around as a part of SE for a long time.

� DoDAF simply organizes these architecture products by groups (operational, systems, technical) in a list.

� The main purpose of architecture products is to aid POM decisions. Their main purpose is NOT to develop a system(i.e., to specify the requirements, capabilities, functions, or design of a system).


194

DoDAF Background

� What is DoDAF?

� DoDAF Purpose?

� Why Integrated Architectures?

� Who is Responsible for Which Views?

� What is the Major Use of DoDAF?


195

What is DoDAF?


196 Excerpted from “DoD Architectures,” Truman Parmele, OASD/DCIO, April 2003

What is DoDAF? (cont)


197

DoDAF Architecture Views


198DoDAF Deskbook.

Developing the Architecture Views


199

DoDAF Purpose

� The purpose of the Department of Defense (DoD) Architecture Framework, Version 1.0, is to provide guidance for describing architectures for both warfighting operations and business operations and processes. The Framework provides the guidance, rules, and product descriptions for developing and presenting architecture descriptions that ensure a common denominator for understanding, comparing, and integrating Families of Systems (FoS), Systems of Systems (SoS), and interoperating and interacting architectures.

DoD Architecture Framework, Version 1.0


200

Why Integrated Architectures?

� The Under Secretary of Defense (Acquisition, Technology, and Logistics) (USD(AT&L)), the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASD(C3I)), the Joint Staff, the Military Departments, the Defense Agencies, Combatant Commanders, and other appropriate DoD Components shall work collaboratively to develop joint integrated architectures for capability areas as agreed to by the Joint Staff. In addition, the Under Secretary of Defense (Comptroller) (USD(C)) is responsible for the development of the Financial Management Enterprise Architecture.

� Each integrated architecture shall have three views: operational, systems, and technical, as defined in the current Architectural Framework guidance and have direct relationships to DoD Component-developed functional area integrated architectures.

DoD 5000.2, 3.2.1 Integrated Architectures


201

Who is Responsible for Which Views?

� The Joint Staff (or Principal Staff Assistant (PSA) for businessareas) shall lead development of the operational view, in collaboration with the Services, Agencies, and Combatant Commanders, to describe the joint capabilities that the user seeks and how to employ them.

� The USD(AT&L) (or PSA for business areas) shall lead developmentof the systems view, in collaboration with the Services, Agencies, and Combatant Commanders, to characterize available technology and systems functionality. The systems view shall identify the kinds of systems and integration needed to achieve the desired operational capability.

� The DoD Chief Information Officer (CIO) shall lead the development and facilitate the implementation of the Global Information GridIntegrated Architecture, which shall underpin all mission area and capability architectures. The Military Departments and Defense Agencies shall participate in the identification of the appropriate technical view consisting of standards that define and clarify the individual systems technology and integration requirements. The standards used to form the Technical Views of integrated architectures shall be selected from those contained in the current approved version of the Joint Technical Architecture, accessible at http://jta.disa.mil/, reference f.

Ref DoD 5000.2, 3.2.1 Integrated Architectures Copyright 2006 Northrop Grumman Corporation

202

What is the Major Use of DoDAF?

� Using the integrated architectures, the USD(AT&L) shall lead the development of integrated plans or roadmaps. The Department of Defense shall use these roadmaps to conduct capability assessments, guide systems development, and define the associated investment plans as the basis for aligning resources and as an input to the Defense Planning Guidance, Program Objective Memorandum development, and Program and Budget Reviews.

Ref DoD 5000.2, 3.2.1 Integrated Architectures Copyright 2006 Northrop Grumman Corporation

203

What is the Major Use of DoDAF? (cont)

DoDAF Deskbook. Copyright 2006 Northrop Grumman Corporation

204

DoDAF Deskbook.

What is the Major Use of DoDAF? (cont)


205

INCOSE & JOCMIL-STDs to Commercial Stds to CMMs

Heritage and Future of SE and SW Standards

EIA/IS-632

1980

IEEE 1220

1994

DIDs

ANSI/EIA-

632

IEEE/EIA12207

MIL-STD-

499A

MIL-STD-

499

SystemsEngineering

ISO/IEC

12207

MIL-STD-

498

DOD-STD-2167

DOD-STD-2167A

DOD-STD-

1703

DOD-STD-

7935ADIDs

MIL-STD-1679A

1985

1998 1994

1994

1974 1969 1994

1987

1988

1988

1994

1995 1998

2006+

IEEE 1498

/EIA 640

1995

(Draft)

(Trial Use)

(Interim)

(Not

Released)

Sec Perry

LetterJan 1994

SoftwareEngineering

1968-

Data Item Descriptions

Primary Focus of this Brief

MIL-STD-499B

MIL-STD-

1679

1968-

MIL-STD-961D

1995 Defense Specifications

ISO/IEC

1220715288

Harmon

2005 IEEE 1220

2005

2006

EIA/IEEE

J-STD-016

1995

(Interim)

IEEE 1220

1998

MIL-STD-961E

2003

EIA/IS 731SE Capab Model

1998

ISO/IEC15288

2002

INCOSE SEHandbook V2

2000

NAVAIRSE Guide

2003

CMMI

DSMC/DAU

SE Fundamentals

1999 & 2001

V2a2004 2006

V3

ISO/IEC

TR 19760

2003

12207

1998

Supercedes

Based On

References

2006

NAVALSE Guide

2004


Legend:

206

Contents (cont)





� Backup Slides


207

Recommendations

� Stand on the Standards (Don’t Rely on Others)

� Read, Understand, Select, Tailor, and Apply Them

� Keep Abreast of Standards Evolution

� Develop a Corporate and/or Project Tailored Set of Processes, Product Templates, and SEMP

� Map the Standards To and From the Processes, Templates, and SEMP. Describe Any Tailoring.

� Start with a Pilot Project

� Refine the Processes, Templates, and SEMP

� Have Fun!

JOC


208

Standards Comparison


Systems Engineering Effort Categories Evident in the Standards

SE Categories ANSI/EIA-632 IEEE-1220 ISO-15288 CMMI MIL-STD-499C Mission/purpose definition

Not included in scope � Define customer

expectations (Req Anlys)

� Stakeholder needs

definition

� Develop customer

requirements (Req Devlp) Not included in scope

Requirements engineering

System Design

� Requirements definition

� Requirements analysis

� Track requirements and

design changes

� Requirements analysis � Req’ments development

� Requirements mgmt

� System requirements

analysis and validation

System architecting

System Design

� Solution definition

� Synthesis � Architectural design

� System life cycle mgmt

� Select product-component

solutions (Tech sol’n)

� Develop the design (Tech

sol’n)

� System product technical

req’ments anlys/validation

� Design or physical

solution representation

System implementation

Product Realization

� Implementation

� Transition to Use

Not included in scope

� Implementation

� Integration

� Transition

� Implement the product

design (Tech sol’n)

� Product integration

Not included in scope

Technical analysis


� Systems analysis

� Functional analysis

� Requirements trade studies

� Functional trade studies

� Design trade studies

� Requirements analysis � Decision analysis and

resolution

� Functional analysis,

allocations and validation

� Assessments of system

effectiveness, cost, schedule, and risk

� Tradeoff analyses

Technical management/ leadership

Technical Mgmt

� Planning

� Assessment

� Control

� Technical mgmt

� Track analysis data

� Track performance –

project plans, tech plans

� Track product metrics

� Update specifications

� Update architectures

� Update plans

� Maintain database

� Planning

� Assessment

� Control

� Decision mgmt

� Configuration mgmt

� Resource mgmt

� Risk mgmt

� Project planning

� Project monitoring &

control

� Measurement and analysis

� Process and product

quality assurance

� Configuration mgmt

� Integrated project mgmt

� Quantitative project mgmt

� Risk mgmt

� Planning

� Monitoring

� Decision making, control,

and baseline maintenance

� Risk mgmt

� Baseline change control

and maintenance

� Interface mgmt

� Data mgmt

� Technical reviews/audits

Scope management

Acquisition & Supply � Supply

� Acquisition Not included in scope

� Acquisition � Supply

� Supplier agreement mgmt

� Technical mgmt of subcontractors/vendors

Verification & validation


� Requirements validation

� System verification

� End products validation

� Requirement verification

� Functional verification

� Design verification

� Verification

� Validation

� Verification

� Validation

� Design or physical

solution verification and

validation

In the standard, but not in agreement with other standards

� Operation

� Disposal

� Enterprise mgmt

� Investment mgmt

� Quality mgmt

� Organ’l process focus

� Organ’l process definition

� Organ’l training

� Organ’l process perf

� Causal analysis/resolution

� Organ’l innov/deploymnt

� Lessons learned and

continuous improvement

Provided with the permission of Eric Honour, Honourcode Inc. Copyright 2006 Honourcode, Inc.

All rights reserved. Work performed as part of SE-ROI project http://www.hcode.com/seroi/

209

DoDAF Architecture Development Process

Determine the

intended use of

the architecture

Determine theDetermine the

intended use ofintended use of

the architecturethe architecture

Determine

scope of

architecture

Determine Determine

scope ofscope of

architecturearchitecture

Determine data

required to support

architecture

development

Determine dataDetermine data

required to supportrequired to support


developmentdevelopment

Conduct analysis

in support of

architecture

objectives

Conduct analysisConduct analysis

in support ofin support of


objectivesobjectives

Document results

IAW Architecture

Framework

Document resultsDocument results

IAW ArchitectureIAW Architecture

FrameworkFramework

Collect, organize,

correlate, and

store architecture

data

Collect, organize,Collect, organize,

correlate, andcorrelate, and

store architecturestore architecture

datadata

33 4422 55 66

11

Required architectural Required architectural characteristics:characteristics:

�� Architectural Architectural entitiesentities

�� Levels of detailLevels of detail

�� Units of measureUnits of measure

�� Geographical, Geographical, operational, and operational, and functional boundsfunctional bounds

�� Technological boundsTechnological bounds

�� Time frame(s)Time frame(s)

�� Architecture resource Architecture resource and schedule and schedule restraintsrestraints

�� Automated Automated repositoriesrepositories

�� Activity modelsActivity models

�� Dynamic modelsDynamic models

�� Organization modelsOrganization models

�� Shortfall analysisShortfall analysis

�� Capacity analysisCapacity analysis

�� Interoperability Interoperability assessmentsassessments

�� Investment tradeoffsInvestment tradeoffs

�� Business process Business process analysisanalysis

�� Architecture Architecture products and views products and views (Operational, (Operational, Systems, Technical)Systems, Technical)

�� Reusable Reusable architecture dataarchitecture data

�� Analysis reportsAnalysis reports

�� PurposePurpose

�� Critical issuesCritical issues

�� Target objectivesTarget objectives

�� Key tradeoffsKey tradeoffs

�� Probable analysis methodsProbable analysis methods

Excerpted and modified from DoD Architecture Framework Implementation, Lee W. Wagenhals, November 2003


210

Single System V-Model Example with DoDAF

V-Model excerpted, modified, and provided with the permission of Kevin Fosberg from


Forsberg, Mooz, Cotterman “Visualizing Project Management,” 2000 by John Wiley & Sons, Inc. Copyright 2006 Northrop Grumman Corporation

Formal Review

Working Level Review

Operational Requirements Analysis

ORD, MNS, STAR, All OVs

SystemRequirements Analysis

Prelim SRD, Ext IRS, SV-4, SV-5

Functional Analysis / AllocationFinal SRD, Ext IRS, SV-1, 7, 10

Top Level Synthesis / DesignSSDD, PIDS, CIDS, ICD, SRS, Int IRS,

SV-1, 2, 3, 6, 8, 9, 11, TV-1, 2

Detailed Synthesis / Design

Product Drawings, SDD, IDD, SPS

Fabrication & Coding

HW Components SW Components / Data

Unit / Component

Integration & VerificationHW Units / SW Units /

Components Components / Data

Hardware/Software Integration & Verification

HW Assemblies SW Builds

Element / Segment Integration & Verification

HW Cabinets SW Programs

System Integration

& VerificationSystem

Operational Test

& EvaluationLBTS and Shipboard

SRR

SFR

PDR

CDR

ASR

TRR

TRR

TRR

TRRTRR

TRRTRR

FCA

PCA

SVR

SSR

PRR

FCA

FCAFCA

FCAFCA

Performance Baseline

Prelim Functional Baseline

Final Functional Baseline

Prelim Allocated Baseline

Final Allocated Baseline

Product Baseline

Start of Developmental Baseline

IVP = Integration & Verification Plan

SADD = SNOA Architecture Description Document

IVPIVP

IVPIVP

IVPIVP

IVPIVP

TEMPTEMP

211

Family of Systems (FoS) V-Model Example

Formal Review




SystemRequirements Analysis




SV-1, 2, 3, 6, 8, 9, 11, TV-1, 2

Detailed Synthesis / DesignProduct Drawings, SDD, IDD, SPS



Unit / ComponentIntegration & Verification

HW Units / SW Units /Components Components / Data





System Integration


Operational Test

& EvaluationLBTS and Shipboard

SRR

SFR

PDR

CDR

ASR

TRR

TRR

TRR

TRRTRR

TRRTRR

FCA

PCA

SVR

SSR

PRR

FCA

FCAFCA

FCAFCA






Product Baseline


Application A = DD(X) B/L X

App

lication B = AEGIS B/L X

Application C = CVN

B/L X



Surface Navy OA (SNOA)Family of Integrated Warfare Systems (FIWS)CONOPS SADD

Strike Group T&EStrike Group B/Ls (SHIPMAIN)

IVPIVP

IVPIVP

IVPIVP

IVPIVP

TEMPTEMP

Strike Group Strike Group ““TEMPTEMP””




212

System of Systems (SoS) V-Model Example




Formal Review




System





SV-1, 2, 3, 6, 8, 9, 11, TV-1, 2





Unit / Component







System Integration


Operational Test

& Evaluation

LBTS and Shipboard

SRR

SFR

PDR

CDR

ASR

TRR

TRR

TRR

TRRTRR

TRRTRR

FCA

PCA

SVR

SSR

PRR

FCA

FCAFCA

FCAFCA






Product Baseline




IVPIVP

IVPIVP

IVPIVP

IVPIVP

TEMPTEMP

Formal Review




System





SV-1, 2, 3, 6, 8, 9, 11, TV-1, 2





Unit / Component







System Integration


Operational Test

& Evaluation

LBTS and Shipboard

SRR

SFR

PDR

CDR

ASR

TRR

TRR

TRR

TRRTRR

TRRTRR

FCA

PCA

SVR

SSR

PRR

FCA

FCAFCA

FCAFCA






Product Baseline




IVPIVP

IVPIVP

IVPIVP

IVPIVP

TEMPTEMP

Formal Review




System





SV-1, 2, 3, 6, 8, 9, 11, TV-1, 2





Unit / Component







System Integration


Operational Test

& Evaluation

LBTS and Shipboard

SRR

SFR

PDR

CDR

ASR

TRR

TRR

TRR

TRRTRR

TRRTRR

FCA

PCA

SVR

SSR

PRR

FCA

FCAFCA

FCAFCA






Product Baseline




IVPIVP

IVPIVP

IVPIVP

IVPIVP

TEMPTEMP

213

Domain and Application Eng Model Example

DomainAnalysis

DomainDesign

DomainImplementation

Domain Implementation

Assets(Code, Data Bases,

Test Plans & ProceduresRVMs, SVDs, SPSs, EDs)

Domain Engineering

DomainModels(ORDs,

ICDs, CDDs,

Specs, IRSs, SRSs, PIDS)

DomainArchitectures(SSDDs, IDDs,

SDDs, DBDDs, EDs)


Application B = AEGIS B/L X

Application C = CVN B/L X

ApplicationRequirements

AnalysisBased onDomainModel

ApplicationDesign

Based onDomain

Architecture

ApplicationImplementation,

Integration, & Test

Application

Requirements

Application Engineering

ApplicationRequirements Specifications (New / Modified Specs, SCNs, SRSs, IRSs)

ApplicationDesign

Descriptions(New / Modified SSDDs, SDD, DBDDs, EDs)

ApplicationImplementation

Assets for Application X(New / Modified

Code, Data Bases, Test Plans & ProceduresRVMs, SVDs, SPSs, EDs)

Application D = LCS B/L X

DeliveredPrograms(DD(X),AEGIS,

CVN, LCS)

Existing Domain

Knowledge (DD(X), AEGIS,

CVN, LCS)

Engineering Development Model (EDM)

Application E = DD(X) B/L Y, etc.

Application F = AEGIS B/L Y, etc.

Common Reusable Library (CRL)


Excerpted and modified from Guidelines for Successful Acquisition of Software-Intensive Systems, Volume 1, Department of the Air Force, Software Technology Support Center, June 1996

214

FoS w/ Domain & Appl Eng Model Example

Domain Engineering


Application B = AEGIS B/L X

Application C = CVN B/L X

Application Engineering

Application D = LCS B/L X

DeliveredPrograms(DD(X),AEGIS,

CVN, LCS)

Existing Domain

Knowledge (DD(X),

AEGIS, CVN, LCS)

Engineering Development Model (EDM)

Application E = DD(X) B/L Y, etc.

Application F = AEGIS B/L Y, etc.

Common Reusable Library (CRL)

INT

EG

RA

TIO

N &

VE

RIF

ICA

TIO

N

PR

OC

ES

S

DE

VE

LO

PM

EN

T P

RO

CE

SS

Operational Requirements AnalysisORD, MNS, STAR, All OVs

System Requirements AnalysisPrelim SRD, Ext IRS, SV-4, SV-5

Functional Analysis / AllocationFinal SRD, Ext IRS, SV-1, SV-7

Top Level Synthesis/De sign

SSDD, PIDS, CIDS, ICD, SRS, Int IRS,

SV-1, 2, 3, 6, 9, 11, TV-1, 2

Detailed Synthesis/De signProduct Drawings, SDD, IDD, SPS


HW Components SW Components/Data

Unit & Component

Integration & Verification

HW Units / Components SW Units / Components / Data





System Integration & Verification

Operational Test & Evaluation

System De finition and DesignHardware/Software Definition and

Design

Hardware/ Software

Implementation

Hardware/Software Integration and

Verification

System Integra tion, Verification, and

Validation

SRR

SFR

PDR

CDR

TEMP

ASR

TRR

TRR

TRR

TRR

TRR

FCAPCASVR

Formal ReviewWorking Level Review

SSR

PRR

FCA

FCA

FCA

IVP

IVP

IVP

IVP

ApplicationRequirements

INT

EG

RA

TIO

N &

VE

RIF

ICA

TIO

N

PR

OC

ES

S

DE

VE

LO

PM

EN

T P

RO

CE

SS



System Requirements Analysis


Functional Analysis / Allocation

Final SRD, Ext IRS, SV-1, SV-7

Top Level Synthesis/ De sign

SSDD, PIDS, CIDS, ICD, SRS, Int IRS,SV-1, 2, 3, 6, 9, 11, TV-1, 2

Detailed Synthesis/De signProduct Drawings, SDD, IDD, SPS


HW Components SW Components/Data

Unit & Component

Integration & Verification

HW Units / Components SW Units / Components /

Data


HW A ssemblies SW Builds



System Integration & Verification

Operational Test & Evaluation

System De finition and DesignHardware/Software Definition and

Design

Hardware/ Software

Implementation

Hardware/Software Integration and

Verification

System Integra tion, Verification, and

Validation

SRR

SFR

PDR

CDR

TEMP

ASR

TRR

TRR

TRR

TRR

TRR

FCA

PCASVR

Formal ReviewWorking Level Review

SSR

PRR

FCA

FCA

FCA

IVP

IVP

IVP

IVP




215

Summary

� Heritage and Future of Systems Engineering and Software Engineering Standards

� What is a System?

� What is Systems Engineering?

� What is Systems Engineering Management?

� What is the Systems Engineering Process?

JOC


216

Did We Meet Your Expectations?

On completing this presentation…..

� Do you have a good understanding of systems, systems engineering, systems engineering management, systems engineering processes, and software engineering from a standards perspective

� Do you have a good understanding of the systems engineering and software engineering standards, including their heritage, processes, products, relationships, and future

� Do you have a good understanding of the system life cycle

� Are you able to apply the standards to a project

� Are you able to you use a common terminology to enhance communications

Learn the fundamentals of Systems Engineering and Software

Engineering Standards


217

Almost the End!

� Questions?

JOC


218

THE END!

For More Information Contact:

John O. Clark William Kenney

Northrop Grumman Mission Systems Northrop Grumman Mission Systems

Defense Mission Systems Division Defense Mission Systems Division

Warfare Systems Engineering Dept. Fleet Systems Engineering Dept.

468 Viking Drive 80 M Street

Virginia Beach, VA 23452-7308 USA Washington, DC 20003 USA

[email protected] [email protected]

(757) 481-1504 (202) 799-3079


219

Acronyms

Configuration ItemCI

Contract Data Requirements ListCDRL

Critical Design ReviewCDR

Capability Development DocumentCDD

Concept DecisionCD

Critical DesignCD

ComponentC

Budgeted Cost of Work ScheduledBCWS

Budgeted Cost of Work PerformedBCWP

Automatic Teller MachineATM

Analysis, Technology and LogisticsAT&L

Alternative System ReviewASR

Assessment ProcessAP

Analysis of AlternativesAoA

American National Standards InstituteANSI

Architectural DesignAD

Actual Cost of Work PerformedACWP

AcquisitionAcq

AlternativeA

DescriptionAcronym

Electronic Industries AssociationEIA

Enterprise Environment ManagementEEM

Defense Systems Management CollegeDSMC

Doctrine, Organization, Training, Material,

Leadership, Personnel, Facilities

DOTMLPF

Department of Defense StandardDOD-STD

Defense Management UniversityDMU

Data Management PlanDMP

Decision MakingDM

DisposalDis

Data Item DescriptionDID

Data Base Design DescriptionDBDD

Defense Acquisition BoardDAB

Contract Work Breakdown StructureCWBS

Cost VarianceCV

Computer Software Configuration ItemCSCI

Capability Production DocumentCPD

Control ProcessCP

Capability Maturity Model IntegratedCMMI

Configuration Management PlanCM


220

Hardware SpecificationHS

Hardware Development PlanHDP

Hardware Design DescriptionHDD

HandbookHDBK

FirmwareFW

Full Rate ProductionFRP

Final Requirements BaselineFRB

Final Product BaselineFPB

Family of SystemsFOS

Full On CapabilityFOC

Functional Flow DiagramFFD

Functional Flow Block DiagramFFBD

Final Functional BaselineFFB

Functional Configuration AuditFCA

Final Allocated BaselineFAB

FinalF

Function, FunctionalF

Earned Value ManagementEVM

End Products Validation ProcessEPVP

Interface Requirements SpecificationIRS

Implementation ProcessIP

Initial Operational Test and EvaluationIOT&E

Initial Operational CapabilityIOC

IntegrationInt

International Council on Systems EngineeringINCOSE

Integrated Master ScheduleIMS

Integrated Master PlanIMP

Information Management,

Investment Management

IM

Integrated Logistics Support PlanILSP

Institute of Electrical and Electronic EngineersIEEE

International Electrotechnical CommissionIEC

Interface Design SpecificationIDD

Initial Capabilities DocumentICD

Integration and Test PlanI&TP

ImplementationI

Hardware Configuration ItemHWCI

HardwareHW

Human Systems Integration PlanHSIP

Acronyms (cont)


221

Open Systems Joint Task ForceOSJTF

Office of the Secretary of DefenseOSD

Operational Requirements DocumentORD

OperationOp

Operational Concepts Document OCD

Organizational Breakdown StructureOBS

National Security SystemsNSS

Naval Sea Systems CommandNAVSEA

Naval Air Systems CommandNAVAIR

N x NN2

MaintenanceMT

MilestoneMS

Manual OperationMO

Military StandardMIL-STD

Limited Rate Initial ProductionLRIP

Joint Requirements Oversight Council JROC

John O. ClarkJOC

Interim System ReviewISR

International Organization for StandardizationISO

Quality ManagementQM

Program Work Breakdown StructurePWBS

ProcessPROC

Preliminary Requirements BaselinePRB

Preliminary Product BaselinePPB

Project PlanningPP

Program Management PlanPMP

Personal Identification NumberPIN

Preliminary Functional BaselinePFB

Project Executive OfficerPEO

Preliminary Design ReviewPDR

Preliminary DesignPD

Physical Configuration AuditPCA

Product Breakdown StructurePBS

Product Assurance PlanPAP

Preliminary Allocated baselinePAB

Process AreaPA

Pre-Planned Product ImprovementP3I

PreliminaryP

Acronyms (cont)


222

System Life Cycle Management ProcessSLCM

System Functional ReviewSFR

Systems Engineering Master ScheduleSEMS

Systems Engineering Master PlanSEMP

Systems Engineering Detailed ScheduleSEDS

Systems EngineeringSE

Solution Definition ProcessSDP

Software Development PlanSDP

Software Design DescriptionSDD

System Critical Design ReviewSCDR

System Breakdown StructureSBS

Systems Analysis ProcessSAP

SystemS

Risk Management PlanRMP

Reliability, Maintainability and Availability PlanRM&AP

Resource ManagementRESM

Requirements Definition ProcessRDP

Requirements AnalysisRA

RequirementR

System Test Readiness ReviewSTRR

System Test Completion ReviewSTCR

System/Subsystem SpecificationSSS

Subsystem Requirements ReviewSSRR

Software Specification ReviewSSR

Subsystem Preliminary Design ReviewSSPDR

Subsystem Functional ReviewSSFR

System/Subsystem Design DescriptionSSDD

Subsystem Critical Design ReviewSSCDR

Software SpecificationSS

System SpecificationSS

Software Requirements SpecificationSRS

System Requirements ReviewSRR

System Requirements DocumentSRD

Stakeholder RequirementsSR

System Preliminary Design ReviewSPDR

System Physical Configuration Audit SPCA

Statement of WorkSOW

System of SystemsSOS

Acronyms (cont)


223

Test and Evaluation Management PlanTEMP

Test CompletionTC

Test ReportT Rpt

Test ProceduresT Proc

Test PlanT Pln

Software Te3st Readiness ReviewSWTRR

Software Test Completion ReviewSWTCR

Software Requirements ReviewSWRR

Software Preliminary Design ReviewSWPDR

Software Physical Configuration AuditSWPCA

Software Functional ReviewSWFR

Software Functional Configuration AuditSWFCA

Software Critical Design ReviewSWCDR

SoftwareSW

System Verification ReviewSVR

System Verification ProcessSVP

Schedule VarianceSV

System VerificationSV

SupplySup

Work Breakdown StructureWBS

VerificationVer

ValidationVal

Under Secretary of DefenseUSD

UpdatedU

Theater Surface CombatantsTSC

TrainingTrn

Technical Review ManualTRM

Test ReadinessTR

Technical Performance MeasurementTPM

Transition to Use ProcessTP

Training PlanTP

Top Level RequirementsTLR

Acronyms (cont)
