Towards a Grand Unified Theory of Systems Engineering (GUTSE)

Temasek Defence Systems InstituteTemasek Defence Systems Institute
Towards a Grand Unified Theory
of Systems Engineering
(GUTSE)
Joseph Kasser
Yang-Yang Zhao
Version 1.0
1

Topics
• Need for a GUTSE
• Characteristics of a GUTSE
• Frameworks
• A brief summary of candidate Frameworks
• Summary
• Conclusions
• Questions and comments
2

State of the art?
• Systems engineering has been defined as
– “the science of designing complex systems in their
totality to ensure that the component subsystems
making up the system are designed, fitted together,
checked and operated in the most efficient way”
(Jenkins, 1969).
• However, in the ensuring 45 years, systems
engineers seem to have been busy creating more
and more complex models and processes.
3

Building artificial complexity
4

IS 2009 submission (not in proceedings)
Streamlined? 5

Published perceptions over 20 years
• Systems engineering overlaps problem-solving, project
management and other disciplines
• The role of the systems engineer in the workplace depends on
the situation
• Myths and defects abound unquestioned
• Various views and opinions on the nature of systems
engineering
– Process, problem-solving, meta-discipline, etc.
– Different process views
• Use of language that encourages confusion
– Terminology with overlapping and different meanings
6

Text books (a selection)
7

Need for a GUTSE
• Articulated at NCOSE*
1994
– Closing session of NCOSE
symposium
– George Friedman, PINCOSE
– About the same time this
research started
• Written in Insight 2006
8
* Before INCOSE there was NCOSE

Applying Holistic Thinking
http://signature-strength.com/confidence/changing-perspective/,
accessed 28/2/2014
• Descriptive HTPs
• Provide understanding
• Scientific HTP
• Different views of systems engineering
are views of ‘something’ from different
single perspectives
• Problem is to determine the ‘something’
• It is like solving a jig-saw puzzle
without a picture
9

And our elephant is … ?
• If all views are partial, can they be used to create a
conceptual whole (A GUTSE)?
– Similar to creating a model by finding relationships between
sets of parameters and then combining them into a model
1. Differentiates SE from other disciplines
2. Founded on theory rather than opinion
3. Encompasses all current views
4. Fills gaps in current combination of views
5. Remedies overlaps
6. Encourages best practice
7. Provides a fundamental framework or frameworks
10

Framework (chemistry)
Pictures from Wikipedia Commons, March 2014
Sorted
elements
based on
properties
and left
gaps in the
Table
11

Frameworks (electrical engineering)
Ohm’s law
1827
Maxwell’s
equations
1873
Pictures from Wikipedia commons
12
Allowed predictions

Frameworks (systems engineering)
• Lifecycle?
– Projects
• Process?
13

Candidate Frameworks to build a GUTSE
1. Holistic Thinking*
2. Types of Systems Engineering
3. A Problem Classification Matrix*
4. Hitchins-Kasser-Massie Framework (HKMF) for
understanding systems engineering*
5. Differentiating between Systems Engineering the Role
(SETR) and Systems Engineering the Activity (SETA)*
6. A Systems Engineering Competency Maturity Model
Framework*
7. The extended problem-solving process*
8. The Nine-Systems Model*
* Published
14

Holistic Thinking Perspectives (HTP)
1. Big picture
2. Operational
3. Functional
4. Structural
5. Generic
6. Continuum
7. Temporal
8. Quantitative
9. Scientific
Systems
Engineering
1
2
9
5
4
7
3
8
6
15

Holistic Thinking: Structural perspective
Systems thinking Analysis
16

Framework*
* Published
17

Types of systems engineering
1. Pure systems engineering
– Systems, cognitive skills, problem formulation/solving,
quantitative methods, decision-making
1. Applied systems engineering
– Requirements, architectures, V&V, engineering
management, engineering, ‘*.ilities, etc.
1. Domain systems engineering
– Defence, commercial, etc.
18
Similar to Pure and
Applied Math
Similar to Pure and
Applied Math

Framework*
* Published
19

Problem classification matrix*
Wicked
Here be dragons
(there are no solutions)Ill-structured
Well-
structured Simple Complicated
Non-complex
Easy Medium Ugly Hard
Level of difficulty
Subjective
Objective
* Kasser, J.E., “Complex solutions for complex problems”, proceedings of the Third International Engineering
Systems Symposium (CESUN), Delft, Holland, 2012.
20

Framework*
* Published
21

HKMF: Applied systems engineering
Lifecycle phases
Complexity
22

Framework*
* Published
23

Systems engineering paradigms*
• SETR: activities performed by personnel known as systems
engineers.
– Examples are network systems engineering, control system engineering,
communications systems engineering, etc.
– In many instances the type of system is dropped from the title.
– This systems engineering overlaps other disciplines and the exact
role depends on the situation
• Broad range of competencies
• SETA: activities concerned with problem identification and
solution realization at the system level
– This systems engineering is an enabling discipline (like mathematics)
for remedying undesirable situations
* Kasser and Hitchins, 2009 (FUSE, Chapter 29) 24

SETR and SETA
• Systems Engineering -
The Role (SETR)
– Cannot be differentiated
from other disciplines
– What systems engineers do
in the workplace
– Combination of SETA and
non-SETA
– “Growing” into Meta-
discipline
• Systems Engineering -
The Activity (SETA)
– Can be differentiated
from other disciplines
– Can be performed by
anyone
* Kasser and Hitchins, 2012
25

Framework*
* Published
26

Five types of systems engineers*
• Type V [Innovator, engineer-leader]
– Problem formulator and problem solver
– Directs and performs systems engineering
• Type IV [Problem formulator]
– Has the ability to examine the situation and define the problem
– [Cannot conceptualise a solution]
• Type III [Problem solver]
– Has the expertise to conceptualize the solution system and plan the
implementation of the solution
• Type II [Apprentice, doer]
– Has the ability to follow a process to implement a physical solution system
• Type I [Problem causer]
– Has to be told “how” to so something
27
* Kasser, Hitchins and Huynh, 2009

Mapping abilities to Types
Ability to find
similarities among
objects which seem
to be different
High Problem solvers Innovators
Low Imitators, Doers Problem
formulators
Low High
Ability to find differences among
objects which seem to be similar
* Original table in Gordon G. et al. “A Contingency Model for the Design of Problem Solving Research Program”, Milbank
Memorial Fund Quarterly, p 184-220, 1974 cited by Gharajedaghi, System Thinking: Managing chaos and Complexity,
Butterworth-Heinemann, 1999
Generic perspective
Continuum perspective
“Ability to find” generally
comes mainly from
application of Generic and
Continuum HTPs
(Type III) (Type V)
(Type II) (Type IV)
6-28

A Systems Engineering Competency
Maturity Model Framework
Type I Type II Type III Type IV Type V
Knowledge areas Applied systems engineering in a domain
Systems engineering Declarative Procedural Conditional Conditional Conditional
Problem domain Declarative Declarative Conditional Conditional Conditional
Solution domain Declarative Declarative Conditional Conditional Conditional
Implementation
domain
Declarative Declarative Conditional Conditional Conditional
Cognitive characteristics (Holistic Thinking) – Pure systems engineering
Descriptive HTPs(8) Declarative Procedural Conditional Conditional Conditional
Prescriptive HTP (1) No No Procedural No Conditional
Critical Thinking Confused fact
finder
Perpetual
analyser
Pragmatic
performer
Pragmatic
performer
Strategic re-visioner
Individual traits (sample)
Communications Needed Needed Needed Needed Needed
Management Not needed Needed Needed Needed Needed
Leadership Not needed Not needed Needed Needed Needed
Others (specific to
situation)
Organization
specific
Organization
specific
Organization
specific
Organization
specific
Organization
specific 29

Framework*
* Published
30

Holistic systems approach to managing
problems and solutions
Undesirable
situation (t0)
Feasible Conceptual
Future Desirable
Situation (FCFDS)
(t0)
Problem
Remedial
action
(problem
solving)
Solution
Actual situation
(t1)
Still
undesirable?
No
Yes or partial
End
Undesirable
situation (t2)
32

Framing the problem
1. The undesirable situation
2. The FCFDS
3. The problems
1. To determine the cause(s) of undesirability
2. To determine the transition approach
4. The solution
– A system operating in the context of the
evolved actual situation
33

Activities in the context of problem solving
Problem solving
process[Solution] System
development process (SDP)
Large or complex problems
Small problems
Are elaborated
into many
Uses
Undesirable situation
Solution
system
Series of (sequential and
parallel) activities
remedies
Produces
Kick
s off
Uses
Based on IEEE 1220
34

Framework*
* Published
35

Undesirable
situation (t0)
Feasible
Conceptual Future
Desirable Situation
(FCFDS) (t0)
Problem
Remedial
action
(problem
solving)
Solution
Actual situation
(t1)
Still
undesirable?
No
Yes or partial
End
Undesirable
situation (t2)
What happens here?
What happens in here?
36

Undesirable
situation (t0)
Feasible
Conceptual Future
Desirable Situation
(FCFDS) (t0)
Problem
Remedial
action
(problem
solving)
Solution
Actual situation
(t1)
Still
undesirable?
No
Yes or partial
End
Undesirable
situation (t2)
S1
S2
S3
S4 S5 S6
S7
S8
S1’
Nine-
System
Model
37
37

The Nine-System model
1. The solution systems and
the adjacent systems are
subsystems in the actual
situation
2. Considered as one [class
of] system but generally
is at least two
organizations
(S1) Undesirable
situation (S3) Feasible Conceptual
Future Desirable Situation
(FCFDS)
(S7) Actual
(created)
situation1
(S8) Process to determine
degree of remedy
(S6)
Solution
system
(S5) Process performing
transition to S7
(S2) Process
developing S3
Operating in
context of
(S4) Process planning
transition to S7
S8S5S2
Organization(s) (S9)2
S4 S6
Functional HTP
Structural
HTP
Realizes
39

The Nine-System model
Undesirable Situation S1
Concept dev. process S2
FCFDS S3
Planning process S4
Realization process S5
Solution system S6
Created situation S7
Validation process S8
Undesirable Situation’ S1’
t0
t1 t2
Time
Temporal HTP
SRR
40
40

S1. Undesirable situation
• Perceived from
– Holistic Thinking Perspectives
– Checkland’s Soft Systems Methodology
• As-is
• Baselined at t0
– Eight descriptive perspectives
• Observations
• Assumptions
– Scientific perspective
• Causes of undesirability
– May be more than one
• Statement of problems
– A hypothesis of
1. cause of undesirability
2. what it will take to remedy the undesirable situation
41

S2. Process: early stage
• Develops FCFDS
• Develops CONOPS of solution system
operating within FCFDS
• Uses Steps 2-6 in Hitchins’ systems
engineering approach to problem solving
– Hitchins, 2007
42

S3. FCFDS
• Begin with the end in mind
– 7 Habits of …, Covey, 1989
• Work back from the answer
– Ackoff 1991
• Assumption
– FCFDS will remedy the undesirable situation
• Sometimes consensus on FCFDS may be
achieved without consensus on the underlying
cause of the undesirable situation
• Described from eight descriptive HTPs
43

S4. Process: planning the transition
• Planning/creating the process that will provide the solution
system
– Assembled from activities documented in textbooks, Standards,
experience, etc.
– Build/buy decisions
– Creates SEMP and TEMP
– Biemer and Sage 2009, Kasser and Palmer 2005
• Step 7 in Hitchins systems engineering process
• Creating the matched set of specifications for the solution
system
• Taught in Project Management classes
• Generally terminates with a SRR
44

S5. Process: performing the transition
• Short problem-solving process
– Problem – process - solution
• Commonly known as the
– ‘system development process (SDP)’
– ‘system development lifecycle (SDLC)’
– “systems engineering process (SEP)”
• Three streams of work between milestones
1. Management
2. Development/production
3. Development Test and Evaluation (DT&E)
• May require several iterations
– Temporal perspective
• Must be able to cope with changes in need before process terminates
45

S6. Solution system
• Conceived as part of FCFDS
• Realized in providing actual situation
• May comprise more than one system
• Contains mission and support functions
• Conforms to 7 principles paper
– Kasser, J. E. and Hitchins, D. K., "Unifying systems
engineering: Seven principles for systems engineered
solution systems", proceedings of the 21st
International
Symposium of the INCOSE, Denver, 2011.
• May be provided in stages or Builds
• Contains a mixture of technology and people
46

S6: Solution system
• Big Picture perspective
– Subsystem of S7
• Operational perspective
– Interactions with adjacent systems
– What the system does (mission and support scenarios)
• Functional perspective
– Internal functions
• Structural perspective
– Technology and physical components
• Quantitative perspective
– Numbers associated with functions, structures and other aspects
• costs, reliability, etc.
• Continuum perspective
– May contain unanticipated undesirable emergent properties
47

S7. Actual (created) situation
• Realization of the FCFDS
– Situation at time solution system (S6) is realized
• Contains solution system (S6) and adjacent systems
operating interdependently
• May only partially remedy original undesirable situation
• May not remedy new undesirable aspects that show up
during time taken by realization process
• May contain unanticipated undesirable emergent
properties from solution system (S6) and its interactions
with adjacent systems in the situation
• May be realized in partial remedies
48

S8. Process closing stage
• Determines if the solution system, operating in
its context, remedies the new evolved
undesirable situation at t1.
• Operational Test and Evaluation (OT&E)
• Acceptance test at end of first iteration
• Evolves into change management process
– Triggers new iteration via change process to
modify/upgrade solution system
– May lead to disposal phase
49

S9. System containing processes
• Organizations
– Generally at least two organizations
• Customer and contractor
– Grouped as one system because of common
features
• Each organization is an instance of a class of
systems
• Provides personnel and other resources to
process systems
50

Focus of the Standards, Hitchins, SIMILAR, SSM,
problem-solving, MBSE and the nine systems
System MIL-
STD-499
EIA-
632
IEEE
1220
ISO/IEC
15288
Hitchins
(2007)
SIMILAR MBSE SSM problem-
solving
S1 X X X
S2 X X
S3 X X X
S4 X Partial X X X
S5 X X X X X X
S6 X X X X X
S7 X
S8 X X
S9 Partial X
51

GUTSE Frameworks Summary
52
1. Holistic
Thinking
Perspectives
1. Holistic
Thinking
Perspectives
ThinkingThinking
2. Types of
Systems
Engineering
3. A Problem
Classification
Matrix
2. Types of
Systems
Engineering
3. A Problem
Classification
Matrix
Nature of
Problem
Nature of
Problem
4.HKMF
5. SETR and
SETA
4.HKMF
5. SETR and
SETA
Nature of
Project
Nature of
Project
6.
Competency
Maturity
Model
Framework
6.
Competency
Maturity
Model
Framework
Human &
Knowledge
Assets
Human &
Knowledge
Assets
7. Extended
problem-
solving
process
8. Nine-
Systems
Model
7. Extended
problem-
solving
process
8. Nine-
Systems
Model
MethodologyMethodology

Summary
• Need for a GUTSE
• Frameworks
• A brief summary of candidate Frameworks
• Summary
• Conclusions
• Questions and comments
53

Conclusions
1. Differentiates SE from other disciplines
2. Founded on theory rather than opinion
3. Encompasses all current views
4. Fills gaps in current combination of views
5. Remedies overlaps
6. Encourages best practice
7. Provides a fundamental framework or
frameworks
• Not quite there yet
54

Systems engineering
Systems engineering is a part of
the application of a systemic and
systematic holistic approach to
remedying complex problems
55

Questions?
0-56

Towards a Grand Unified Theory of Systems Engineering (GUTSE)

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (15)

Similar a Towards a Grand Unified Theory of Systems Engineering (GUTSE)

Similar a Towards a Grand Unified Theory of Systems Engineering (GUTSE) (20)

Más de Joseph KAsser

Más de Joseph KAsser (10)

Último

Último (20)

Towards a Grand Unified Theory of Systems Engineering (GUTSE)

Notas del editor