Systems engineering

and measurement

what do they have to do

with one another?

Geilson Loureiro, geilson@lit.inpe.br

November 29th, 2012, São Paulo, SP

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

2

INCOSE OVERVIEW

The International Council on Systems Engineering (INCOSE)

is a not-for-profit membership organization founded in 1990

to develop and disseminate the interdisciplinary principles

and practices that enable the realization of successful

systems.

www.incose.org

MISSION: Share,

promote and

advance the best

of systems

engineering from

across the globe

for the benefit of

humanity and the

planet.

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

3

Network with over 7,000 members in 40 countries.

Quarterly e-Publication, INSIGHT.

Electronic version of Systems Engineering, the

Journal of INCOSE.

Collaborate with experts and practitioners.

Access to i-Pub, the INCOSE publications database

(over 2,000 papers).

Exclusive access to INCOSE Connect (collaborative

space for Members).

Annual International Symposia.

Local Chapter Operations.

INCOSE Representation on Standards Committees.

INCOSE Main Benefits

JOIN INCOSE! CHOOSE INCOSE BRASIL AS YOUR CHAPTER!

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

4

Systems Engineering and Metrics

Systems Engineering Process

Laboratory of Integration and Testing

Metrics along the systems engineering process

Broader scope for modern SE

Conclusion

CONTENTS

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

5

Systems engineering is an inter and

multidisciplinary, collaborative, engineering

approach to derive, evolve and verify a system

solution balanced over its life cycle in order to

provide satisfaction to stakeholders.

IEEE 1220

SYSTEMS ENGINEERING and METRICS

A metric is a composite of quantifiable process and

product attributes that communicate important

information about quality, process, technology,

product and/or resources.

INCOSE Metrics Guidebook for

Integrated Systems and Product Development

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

SYSTEMS ENGINEERING PROCESS OVERVIEW

Detailed

Design

Unit Test/

Acceptance

Validation

Baseline: firm and approved reference for all teams to proceed.

Requirements

Baseline (SRR) Architecture

Baseline (PDR)

Design

Baseline (CDR)

Design

Baseline

(Release for

Testing)

Product

Baseline

Controlled Changes: impact analysis, approval,

control

CM Configuration

management

Stk’s needs,

requirements

and approval

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

LABORATORY OF INTEGRATION AND TESTING

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

LIT’S FACILITIES

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

LIT’s Testing Hall – 100.000 Class

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

LIT’s Integration Hall – 10.000 Class

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

LIT’s industrial

customers

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

SYSTEMS ENGINEERING PROCESS OVERVIEW

Detailed

Design

Unit Test/

Acceptance

Validation

Baseline: firm and approved reference for all teams to proceed.

Requirements

Baseline (SRR) Architecture

Baseline (PDR)

Design

Baseline (CDR)

Design

Baseline

(Release for

Testing)

Product

Baseline

Controlled Changes: impact analysis, approval,

control

CM Configuration

management

Stk’s needs,

requirements

and approval

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

STAKEHOLDER NEEDS ANALYSIS

AND METRICS

Aircraft in [life cycle

process or scenario]

e.g Aircraft in preventive

maintainance Stakeholders

who are

sources

of Inputs

e.g. Crew

Stakeholders

who are

destination

of outputs,

e.g. Aircraft

operators

Stakeholders

who control

[process or scenario]

e.g. Safety Inspectors

Stakeholders

who are mechanisms

or who provide mechanisms

e.g. Maintainance

technicians

IDEF0 Inputs Outputs

Mechanisms

Controls

concerns

concerns

concerns

concerns

Statement of Need

Goal_1 Goal_2 Goal_3

Objective_2.1 Objective_2.2

Metric_2.1.1

Measure_1.1.2,1 Measure_1.1.2.2 Measures of effectiveness

Qualification strategy How to verify

Set of attributes that describe the achievement

of the objective

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

SYSTEM REQUIREMENTS AND METRICS

System at

‘Perform flight

operations’

scenario

Pilot

Co-pilot Other_crew_members

Passengers

Cargo

Atmosphere Air taffic control

commands

Flight info

Flight reaction

weight

movement

Cargo_weight

entertainment

damping

lift

dragging

Exhaust gases

Heat_from

pressure

Heat_to

Experience

Training level

Maturity

Health

Discrete values

Wind speed Turbulence level

Continuous values

Functions

Performance

Conditions

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

The <system> shall <function> not less than <quantity> <object> while

<operational condition>.

Example: The communications system shall sustain telephone contact with not

less than 10 callers while in the absence of external power.

The <system> shall <function> <object> every <performance> <units>.

Example: The coffee machine shall produce a hot drink every 10 seconds.

Source: Hull et al, 2005

REQUIREMENTS WRITING AND METRICS

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

ARCHITECTURAL DESIGN AND METRICS

System

analysis

Assess technology

alternatives

Identify system

design element

alternatives

Partition and

aggregate system

functions aiming at

allocatable functions

Allocate functions to

system elements

Deploy down

requirements to

functions and

system design

elements

Select system

design elements

Perform functional

analysis of system

design elements

aiming at defining

physical interfaces

Define physical

interfaces

Deploy

requirements to

lower level functions

Compose functional

architecture (s)

Compose preferred

physical architecture (s)

Allocate elements in the

functional architecture to

system design elements

and physical interfaces

in the physical

architecture

Allocate requirements to

system design elements

and physical interfaces

in the physical

architecture

Syste

m a

na

lysis

fo

r a

rch

ite

ctu

ral d

esig

n

Select

preferred

physical

architecture (s)

Synthesis Solution Functional Analysis Arch Selection

Re

fin

am

ent

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

17

PRODUCT VS SYSTEM – AN EXAMPLE

Exploration Value Delivery System Scientific - Economic - Security

Exploration System

Flight Systems

Ground Systems

Implementing

and

Building Training and

Skill Development

Maintaining

and

Supplying

Exploration Enterprise

Hardware Software

Humans

Hardware Software

Humans

Exploration Value Delivery System Scientific - Economic - Security

Exploration System

Flight Systems

Ground Systems

Implementing

and

Building Training and

Skill Development

Maintaining

and

Supplying

Exploration Enterprise

Hardware Software

Humans

Hardware Software

Humans

CEV

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

18

TRADITIONAL CONOPS

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

19

NECESSARY SCOPE FOR MISSION

SUCCESS

Microgravidade Experimentos

Trajetória

Lançamentonavegadores

Reentrada

Resgate

comunidades locaisnavegadores

Aquisição de dados

Logística

AIT

Solo

C3Recuperação

comunidades locaisnavegadores

Logistics

Launching

Trajectory

Microgravity Experiments

Reentry

Recovery

Rescue

Data acquisition Ground

AIT

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

SE for product and organization

Mission

Life cycle processes

Scenarios Scenarios within the scope

of the development effort

Product stk

Concerns Organization stk

Concerns

Product

functional

context

Organization

functional

context

Product

implementation

context

Organization

implementation

context

Modes Modes

MoEs External

interface

reqs

System requirements

Product functional structure

Product functional behaviour

Organization functional structure

Organization functional behaviour

Product functional attributes Organization functional attributes

Product implementation attributes

Product implementation architecture interconnects

MoEs External

interface

reqs

Organization implementation architecture interconnects

Organization implementation attributes

System architecture

Stk

requirements

Stk

requirements

Hazard and risk analysis Hazard and risk analysis

Product implementation architecture flows Organization implementation architecture flows

Attributes relationship

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

21

PRODUCT AND ORGANIZATION CONCURRENT ENGINEERING

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

IPD FRAMEWORK

Systems

Engineering

Concurrent

Engineering

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

INTEGRATED PRODUCT DEVELOPMENT

Stakeholder Need

Requirement

Function Form

Product

Life Cycle Process

Organization

Attribute

has

derives

is translated by

derives

is

described

by

Evolution

Innovation

Learning has

is performed by

validation

verification

affects relationships

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

IT´S ALL ABOUT METRICS

Problem Domain

Solution Domain

Requirements Attributes

Stakeholders

System

Relationships

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

25

Systems engineering is

all about metrics!

Systems engineering is

simply not possible

without metrics!

CONCLUSIONS

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

26

Thanks for your attention!

Questions?

geilson@lit.inpe.br

www.lit.inpe.br

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

27

Back up slides

Mé

tric

as

20

12

, S

ão

Pa

ulo

, S

P

28

Electronics engineering, 1987, ITA

Concurrent engineering, MSc, 1994, ITA

Systems engineering, PhD, 1999, Loughborough University,

UK

System of systems for Space Exploration, 2004 and 2005,

Post Doc, MIT, USA

Managerial position at LIT from 1999 to 2008, worked on

satellite manufacturing, assembly, integration, testing since

1988 at INPE

Professor of systems engineering, requirements engineering,

quality engineering and AIT at INPE and at ITA, since 2003

7 Master completions and 1 Doctoral completion since 2005

Background