INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Systems Engineering - In Retrospect and In

Prospect

Peter RobsonSystems Engineering Consultant

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Overview of Paper

• Introduction

• Generic Systems Engineering

• Systems Engineering Maturity – Performance

– Methodology

– Focus

– Life Cycle

• In Retrospect

• In Prospect

• Conclusions

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Disclaimers

• My views only!

• Examples come primarily from defence background

– but read across / translate to other sectors

• Examples are mostly end customer – prime supplier

– but don’t forget that prime suppliers are customers down

the supply chain

• Not an analysis of thirty years of systems theory

– but subjective identification of key issues

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Introduction

• Resurgence of national interest in systems engineering during the last decade

• DTI’s Foresight Systems Engineering Working Party

• MOD’s initiative on ‘Smart’ Procurement’ • Importance of systems engineering to other

sectors of industry • Signs that the resurgence has not taken

sufficient root• Systems engineering is a shared interest

throughout the whole supply-and-use chain for a project or product

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Thesis

“Complementary systems engineering capabilities are needed

within and between the various enterprises in the supply chain, in particular between customers and

suppliers”

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Generic Systems Engineering

• What is a System? – “A system is an interacting combination of elements,

viewed in relation to function” – the human element– emergent properties

• What is Systems Engineering? – “Systems engineering is the art and science of creating

complex systems” (Hitchins)

– Discovery, a specialist type that involves significant analysis, particularly of the problem space (Sheard)

– Program Systems Engineering, a co-ordination or generalist type that emphasises the solution space and technical and human interfaces (Sheard)

– Approach, a process type that can (and should) be performed by any engineer (Sheard)

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Generic Systems Engineering

• The Human Foundation of Systems Engineering– Propositions about Humans and Problems– Propositions about Knowledge – Propositions about Systems Engineering

• Systems Hierarchies

Constituents of a system

Systems engineering hierarchy

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Structure based on SE Maturity Model

based on Brian Mar’s “Systems Engineering Maturity Model”NCOSE 1993

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Performance

Have we just promised to provide

SE (Level 1) or have we demonstrated

it (Level 2) or have we made it

repeatable (Level 3) or have we already

improved our (repeatable) systems engineering process (Level 4)?

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

The Best of Cost-Plus :The heady days of Ptarmigan

• Succinct top-level User requirement• Strong MOD/SRDE/Industry team built-up

through earlier studies and demonstrator activities

• Green-field approach to management and technical processes (top-down)

• Time to think first then act• Trade-offs ‘round the table’ - an integrated

project team!• How do we recapture the best of this?

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

The Worst of Fixed-Price

• The requirement is assumed complete and fixed• Implementation defined as part of the

requirement• Lip-service paid to whole-life costs• Jump off the cliff if you want to win

– Don’t bother to explain the potential problems and how they’ve been allowed for in the price

– The customer won’t be impressed, he’s looking for someone that doesn’t have problems

• Sort it out after you’ve won– You’re bound to make a loss reworking and retesting– The customer will slag you off because of late delivery– Next time, someone else can jump!

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Becoming Smarter?

• Match the chosen procurement approach to the feasibility of the systems engineering involved – A cry for “faster, cheaper, better” in accordance with

the principles of systems engineering is unlikely to be successful unless complemented by other changes

• Recognise precedented ‘project systems’ should be delivering the ‘unprecedented systems’

• Complete the bridges between – systems engineering and project management– customer and supplier

• Customers must have a full systems engineering capability– education and training in SE process, methods and

tools

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Laws & Principles

• Foresight SEWP Report

– Build the right system

– Build the system right

• EIA/IS 632 Standard

– The right things should be done

– The right things should be done at the right time

– The right things should be done by the right people

– The right things should be done right the first time

• Simple, even trivial, statements but often

forgotten and difficult to achieve

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Methodology

Do we think SE is just documents (Level 1)

or about producing a self-consistent set of

requirements, functions and architectures (Level 2) or are we able to simulate our systems dynamically before trying to build them (Level 3) or have we done all this and

have now optimised our approach (Level 4)?

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Methodology

• Level 1 - documents, documents and more documents• Level 2 - process together with recognition that SE is

about ‘joined up information’ – base on needs design analysis not requirements

analysis design

– ‘process’ not ‘lifecycle’

– but more than ‘process’, more than ‘information’ - emphasis on design or architecting

– systems engineering plans

– systems engineering tools

– ‘tribalism’ becomes more visible

• Level 3 - dynamic interactions between system elements – discover emergent properties sooner!

• Becoming smarter - does concurrency help? – handle increased concurrency in the ‘project production

system’ with care!

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Focus

Are we doing SE on our products only for

those customers that have demanded it (Level 1)

or do we apply SE to the process as well but again only at customer demand

(Level 2) or are we mature enough to apply SE to all our products

because we believe in SE as a contractor (Level 3) or do we apply it to our

processes as well (Level 4)?

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Focus

• Dimension reflects a contractor’s motivation or enlightened self-interest

• Focus metric is defined as two state pairs – is systems engineering driven by the customer or the

producer (contractor)?– is systems engineering used to develop the product or

the process?

• Level 1 harks back to the days when the contract would stipulate the applicable standards

• Relates to the role of systems engineering standards and maturity models

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

External standards - just what are they for?

• Provide an external and believable reference– rather like a consultant, only impersonal and cheaper!

• Level the playing field for procurers and suppliers

• Capture of best practice

• Avoid inappropriate practice– e.g. misapplication of software-based systems approaches to

levels of systems well above software

• Establish a common language– eliminate the need for the SE Babel Fish!

• Aid to the conduct of Program Systems Engineering– not so useful for mandating that “the fundamental concepts

of generic systems engineering shall be followed”

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Key Issues for SE Standards

• Essence of SE v detailed systematic engineering• Needs Design Analysis rather than

Requirements Analysis Design?• Process v Life Cycles?• Synthesis v Decomposition?• Hard (Products) or Hard Soft (Services)?• SE component of SW standards?• Project management - in or out?• Humans - in or out?• Software engineering - in or out?

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Capability Maturity Models - do they help?

• EIA 731 SECM – can really help an organisation assess its capability to

carry out systems engineering – not a standard for systems engineering, or for a

systems engineering process – encourages systematic engineering in a more capable

way

• EIA 731 status and intended use

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

EIA 731 status and intended use

“This Interim Standard is intended solely to be used for self-development, self-improvement, and self-appraisal. Organizations should not apply this Interim Standard to suppliers as a means of source selection or as a

means of qualification to be a supplier.”

EIA 731 Part 1 Section 2.3

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Capability Maturity Models - do they help? • EIA 731 SECM

– can really help an organisation assess its capability to carry out systems engineering

– not a standard for systems engineering, or for a systems engineering process

– encourages systematic engineering in a more capable way

• EIA 731 status and intended use– but customers using SECM in source selection to help give

confidence in the outcome of a resultant contract

• Pursuit of ‘Focus maturity’ – mixture of self-assessment and third-party assessment on an

annual cycle

• Customers need to apply SECM to themselves – SE is not done only by suppliers

– SE is a critical capability for customers who want their projects to succeed

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

The tyranny of requirements

• The apparent inability of customers to ‘focus’ on the wider aspects of systems engineering is a major cause of project failure

• Customers must aspire to more than ‘systematic requirements engineering’ – even though this contains much good practice – e.g. establish a minimal and abstracted set of project

requirements, fully traceable and verifiable and which do not constrain the creativity of both customer and supplier

• Over-emphasis on functional requirements at the expense of non-functional requirements – desired ‘emergent properties’ often relate to NFRs

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Requirements and Options

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

The tyranny of requirements- quote from a past INCOSE President

“If someone is trying to contract for a system, and they can properly identify all the necessary ‘requirements’, then it makes sense to do so. The preference then usually becomes: “meet the requirements, and pick the lowest cost.” But the reality is, in every complex system I've seen, “most ‘requirements’ aren't.” Given the right combination, nearly any ‘requirement’ will be relaxed to obtain some other gain. The real preferences are hidden behind the ‘requirements’ in some operational analysis space. This is the ‘real’ reason behind the recent Acquisition Reform initiatives to contract based on performance specifications - but even these initiatives don't go far enough. As soon as someone lists a set of ‘requirements’ without indicating what makes one system better than another, they've lost the information for comparison.”

Eric Honour

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Life Cycle

Do we apply SE only during the concept

phase of projects (Level 1) or throughout the

development phase (Level 2)

or throughout production and delivery (Level 3)

or does SE form the basis for all project activities, including operation, modification and

decommissioning (Level 4)?

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Life Cycle

• Lifecycles are well appreciated – but the ordering of the four levels of maturity is telling

• Processes associated with all stages of the lifecycle are active throughout the lifecycle

• Stakeholders associated with all stages of the lifecycle need to be active throughout the lifecycle as well – Sponsor, User, Procurer, Technical Adviser, Supplier,

Operator, Maintainer, ….

• Exclusion of suppliers during the formative work on a project significantly increases the risk to the project

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

SE Maturity of UK Industry

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

The ‘People Problem’

• Common factor many problems is ‘people’ rather than technical issues – particularly true for Program Systems Engineering – SE is not the responsibility of a single ‘tribe’ of

Systems Engineers within industry– Project management must use SE principles to design

projects – Software engineers (and other engineering disciplines)

must adopt a SE approach, which complements that on the overall project

– Customers must carry out SE activities in cooperation with their suppliers

• So – what are the prospects for Systems Engineering?

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

In Prospect

• Overview

• Barriers to SE excellence

• SE research objectives

• Management of SE research projects/programmes

• Barriers in a SE research programme

• Conclusions

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

In Prospect - Overview

• SE has had many major successes

– but it clear that much remains to be done

• What are its prospects for the coming decade?

• What aspects need to be tackled?

• The ‘SERF’ Report

– Boardman, J, Tully, C & Rose, M; ‘Systems

Engineering: A Research Framework’; Report published

by De Montfort University, 1997

• Update of personal input to the study

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Barriers to SE excellence

• Lack of understanding of the potential of SE within industry • Ill-considered systems procurements• Poor conceptual understanding of SE

– i.e. regarded only as a engineering specialisation, domain by domain

• Lack of training, both on and off job• Lack of recognised qualifications• Reluctance to apply SE to other than deliverable engineering

projects– i.e. not to project or business processes or to service-providing

systems

• Too close association of SE with software engineering– leading to demarcation issues which give impression that SE only

applies to computer-based systems

• Over-reliance on SECM and (potentially) CMMI models for SE capability improvement

• Over-specialisation in UK educational system (leading to fragmentation of engineering disciplines)

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Barriers to SE excellence

• Lack of understanding of the potential of SE within industry • Ill-considered systems procurements• Poor conceptual understanding of SE• Lack of training, both on and off job• Lack of recognised qualifications• Reluctance to apply SE to other than deliverable engineering

projects• Too close association of SE with software engineering• Over-reliance on SECM and (potentially) CMMI models for SE

capability improvement• Over-specialisation in UK educational system (leading to

fragmentation of engineering disciplines)

The ‘People Problem’ is very apparent in the above list. For systems engineering to take its proper place in the

future, these barriers need to be removed or steps taken to overcome them.

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Systems Engineering Research Objectives

• Generic system architectures for complex systems• Taxonomies for systems• Approaches to requirements elicitation and subsequent cost/benefit

analysis to facilitate trade-offs• Generic SE process with per-domain interpretations • Techniques for information-based SE

– e.g. to allow greater abstraction than process-based SE

• Interaction of SE with project management • Application of SE to project design

– i.e. to the system for producing the system

• Methods for system behavioural and performance modelling• SE tool integration & interfacing• Assessment of quality of a system design and appropriate metrics• SE processes tailored to evolving systems and to ‘systems of

systems’ rather than just to unprecedented systems • SE applied to human aspects of systems and to human

organisations in general

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Systems Engineering Research Objectives

• Generic system architectures for complex systems

• Taxonomies for systems

• Approaches to requirements elicitation and subsequent cost/benefit analysis to facilitate trade-offs

• Generic SE process with per-domain interpretations

• Techniques for information-based SE

• Interaction of SE with project management

• Application of SE to project design

• Methods for system behavioural and performance modelling

• SE tool integration & interfacing

• Assessment of quality of a system design and appropriate metrics

• SE processes tailored to evolving systems and to ‘systems of systems’ rather than just to unprecedented systems

• SE applied to human aspects of systems and to human organisations in general

Work on many topics is on-going; no claims for originality! The need for more work on and a better understanding of ‘soft’ systems engineering is apparent, together with

techniques to facilitate ‘read across’ from one application domain to another.

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Management of SE research projects/ programmes

• National Systems Engineering Research Agenda supported by Government, Academia and Industry (not tied to specific engineering disciplines or domains)

• Evolution of INCOSE UK Chapter into THE recognised body for Systems Engineering (not tied to specific engineering disciplines or domains

• Network of excellence for systems engineering, provided in association with INCOSE

The DTI’s System Integration Initiative was a major achievement of the Foresight work but it has not been adequately consolidated by the Systems Engineering National Advisory Committee or networks of excellence.

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Barriers in a systems engineering research programme

• Emphasis on discipline boundaries in academia and engineering institutions

• Lack of formally trained and industrially experienced academic staff

• Unwillingness/inability of industry to release experienced SE staff to help overcome academia's shortfalls

• INCOSE UK Chapter may not be able to evolve beyond group of "enthusiasts“– hence be unable to exercise influence over the national

agenda

These barriers need to be tackled to assure the future of systems engineering.

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

INC

OS

E U

K S

pri

ng

Sy

mp

os

ium

20

01

PGR

Conclusions

“In some ways, the whole paper is a conclusion, or rather an interim conclusion. Perhaps the point that stands out above all others is the extent of the ‘People Problem’; this is far more likely to hold back the advancement of systems engineering than a lack of systems theory.”