KIP - ASVT
Systems
Models
Systems Engineering
System approach
• System approach: way of thinking and
problem solving based on complex treatment
of phenomena and processes, taking into
account both internal and external links.
• Methodical, objective: understand,
appropriately formulate and solve a problem
• Tools: models, simulation
Common characteristics of systems
•
•
•
•
Systems have a structure that is defined by
its parts and processes.
Systems are generalizations of reality.
Systems tend to function in the same way.
This involves the inputs and outputs of
material (energy and/or matter) that is then
processed causing it to change in some
way.
The various parts of a system have
functional as well as structural
relationships between each other.
Basics of system approach
• System is more than the sum of its parts
• We analyze the system to be able to predict its behaviour
• The main purpose of the system is that in favour of which
we can sacrifice other objectives.
• Every system is an information system: it must analyze
the flow of information
• It may be advisable to decompose complex system into
subsystems, which are then treated individually and in the
end again as one whole.
• System is a dynamic network of interconnected elements.
The change in one element results in changes other
elements.
• The system boundary can change according to the goal of
the analysis.
Systems – basic concepts 1
• system – set of elements and their mutual links that
exhibit specific behaviour as a whole
• structure – way of arrangement of elements and
their links
• subsystem – subset of elements with stronger or
more numerous links
• environment – elements not belonging to the
system, but having links to its elements (however
weaker then within the system)
• input – action from the environment to the system
• output - action from the system to its environment
• process – transformation input
output
Systems – basic concepts 2
• feedback – link monitoring outputs and feeding
information to input
• closed system - system without inputs and outputs
(not interacting with its environment)
• open system – has inputs and outputs, exchanges
mass, energy, information with its environment
• static system – neither system nor its elements
change with time
• dynamic system - system and/or its elements
change in time
• control, regulation – evaluation of inputs,
processes and output and doing changes
System
System as a black box
System with feedback
INPUT
OUTPUT
SYSTEM
FEEDBACK
• negative – system stabilization
• positive – amplification of the response
Try to find examples of both kinds of feedback
Systems thinking
• Hard systems
• Soft systems
• Evolutionary systems
Hard systems
• Useful for problems that can justifiably be
quantified. However it cannot easily take into
account unquantifiable variables (opinions,
culture, politics, etc), and may treat people as
being passive, rather than having complex
motivations.
• Tools: simulations, computer modelling,
techniques of operations research.
Soft systems
• Cannot easily be quantified, especially those
involving people holding multiple and
conflicting frames of reference. Useful for
understanding motivations, viewpoints, and
interactions and addressing qualitative as
well as quantitative dimensions of problem
situations.
• Tools: Morphological analysis as a method for
structuring and analysing non-quantifiable
problem complexes.
Evolutionary systems
• Methodology applicable to the design of
complex social systems; open, complex
systems with potential capacity to
evolve over time.
• Tools: multidisciplinarity, chaos,
complexity, emergence, cybernetics,
cultural anthropology, evolutionary
theory, and others.
Notes - management
• Hard management – command and
control, rigid organizational structures
• Soft management – leadership,
mentoring, coaching, networking
General system theory
• interdisciplinary approach
• study of complexity and relation of the whole
to its parts (holism)
Ludwig von Bertalanffy, Kenneth Boulding
attempt to find common features of complex
systems across disciplines; later on certain
resignation on possibility of finding universal
system principles and laws
Applied system disciplines
•
•
•
•
•
•
•
Operations research
Systems analysis
Cybernetics
Methodology of „soft“ systems
Systems engineering
Development of IS
....
Operations research
• Development and utilization of
mathematical models in decisionmaking
– Problem statement
– Model building
– Finding solution from models
– Solution implementation and control
Systems analysis
• focused on system knowledge;
distinguish principle features of the
system, general from individual;
• tools: decomposition, analysis and
synthesis
warning: the whole is more than sum of
its parts
Cybernetics
from Greek - steering
Nobert Wiener, 1945
• Cybernetics studies systems that can
be mapped using loops in networks
modeling information flows.
• Systems of automatic control must use
at least one feedback loop
Example 1 - controller
• 1868 James Clerk Maxwell analyzed
“steam engine with controlled under
variable load" as a system of non-linear
differential equations and concluded
that, depending on equations
coefficients, the system behaviour will
be described by one of the five following
patterns:
1 - damping
(1) The velocity is smoothly adjusted to desired
value (the best possible response):
2 – damped oscillations
(2) The velocity is adjusted to desired value
after some oscillations (acceptable
response):
3 - oscillations
(3) permanent oscillations – ineffective
response:
4 – non-dumped oscillations
(4) oscillates with growing amplitude until the
explosion:
5 - explosion
or (5) straightly explodes:
Feedback
• Negative (1,2) –system stability ,
homeostasis, frequent in technical and
live systems
• Positive (4,5) – response amplification,
welcome e.g. in economics –
multiplication effects, synergic
phenomena
Example 2 - Thermostat
• Input – gas supplied by gasworks
• Output - heat
• Process – temperature monitoring, sending
signal to switch the burner on/off; gas is
burned and warm air is delivered to the living
room
• Feedback – if the temperature falls below /
raise above the setpoint, the thermostat
sends signal to switch the burner on/off
Example 3- Family finance
• Input –incomes from salaries, gifts, lotteries ...
• Process – saving money in banks, cash/credit card
payments, recording expenses, budgeting
• Output – bought products and services (energy, rent,
insurance, food, home equipment, culture, ...)
• Feedback – bank statements, comparing incomes
with spendings, changing the household economy.
Methodology of soft systems
Extending application of system approaches to social
systems
• reflects subjective interests and attitudes including
fuzziness related to subjective interpretation of
information and vagueness of the language (hard
methods are successful only for well structured,
deterministic problems)
• builds on achievements of biology, informatics,
psychology, anthropology, linguistics, etc.
• cognitive science (P. Thaggard)
• holism, emergency, synergetics vs. reductionism
Systems classification (taxonomy)
growing
complexity
Transcendent systems
Social systems
Man
Animals
Genetic systems
Open systems
Cybernetic systems
Mechanical systems
Physical systems
LIVE SYSTEMS
Symbolic functions,
information
INANIMATE
SYSTEMS
Mass and energy
System and order
• Order: an arrangement of system elements
and links allowing to predict its future
behaviour  system can be controlled even
with incomplete knowledge of all its elements
and links
• Order is based on knowledge; however, due
to our intervention into the system it needn’t
have character of the law of nature
• Deterministic chaos, thriving on chaos (T.
Peters)
• Complex systems, holism, emergence,
synergy
Holism
• Considers the whole system, in its
environment, through its whole life
– System of Interest, collection of elements with a
common identify, e.g. product, organization.
– Viable system, must include everything needed to
maintain its existence and achieve its goals.
• Consequences of Holism:
– The viability of a product generally relies upon
interactions outside of its immediate (product)
boundary.
– Systems are engineered within the context of one
or more “containing systems”.
Emergence
• The whole entity exhibits a property which is
meaningful only when attributed to the whole
and NOT to one of its parts
• Emergent properties vary with environment
and relationships to related systems.
• Consequences of Emergence
– no guarantee of benefit from optimising parts of
the system, or even all of the components
independently
– Changing the elements or interactions within a
system may effect its properties, this can cause
emergent properties to change at a number of
system levels.
Systems engineering
A magician takes something
Bahill and Dean, http://www.sie.arizona.edu/sysengr/slides/
and…..
POOF
turns it into nothing!
An engineer takes nothing
38
and…..
39
Bahill & Dean
turns it into something!
What is Systems Engineering (SE)
• Design and control of complex technical
systems
• Basic resources: 4M - Men, Machines,
Materials, Money (and Time)
• Focuses on artificial systems – artifacts
• Identifying and understanding all the
requirements the system must meet
– Understanding solutions options space
– ‘Optimal’ path from requirements identification, via
solutions, through to customer satisfaction
Purpose
• Produce systems that satisfy the
customers’ needs
• Increase the probability of success
• Reduce risk
• Reduce total-life-cycle cost
Artificial systems
Typical features:
• goals are formulated beforehand and
outside of the system
• system is highly ordered, uncertainty is
not welcome
• man stay outside of the system as its
user, client; plays a passive role or acts
as one of the system‘s resources
Early Systems developments
drew heavily on previous
experience
• Expectations centred on
performance
• Fundamental architecture
based on years of evolution
• Fundamental interactions
and influences in the
environment well
precedented e.g. ‘we know
who the stakeholders are’
• the problem to be tackled
was clear
Automobile technology
about 1890
The Systems challenge is becoming more complex
• Customer / Enterprise expectations
–
–
–
–
Constraints (performance, time, cost .. including through life cost etc)
Customers want Benefits achieved, not features for their own sake
We need to decide what is relevant to achieve those benefits
Customers want customisation & adaptability
• Enterprise environment
– extended, global … organisations, team dynamics & decisions are
complex
• Highly integrated with environment & other systems
– stronger, wider influences & interrelationships
• Increasing rate of change … & uncertainty
– need to establish through life robustness … through life influences
• Situations are becoming increasingly varied &
unprecedented
• An increasing number of subsystem options
(choices) are available
• Systems are more highly integrated than ever
• The relationship between Function & Form is
changing significantly
….. Systems engineers, must decide what is
relevant and critical
….. SE face open problems rather than closed
problems
Implications for SE
• establish a clear, common understanding of the
problem across stakeholders, the SE team etc.
• cannot rely on previous precedents
• system context and associated decisions must be
established and communicated explicitly
• gaining confidence in the system is increasingly
difficult
• Soft methods are essential in dealing with ‘open’
problems
Methodology
• define problem or task (of the system)
• specify (system) goals
• develop conceptual system design
(system synthesis)
• analyze and evaluate systems being
designed
• select suitable (optimum) system
• deploy and operate the system
Define
Requirements
Retirement,
Disposal &
Replacement
The system
life cycle
Operation,
Maintenance
& Evaluation
Investigate
Alternatives
Full-Scale
Design
Integration
& Test
Implementation
The vee life-cycle model
Mission
Analysis
Operation &
Retirement
Continuous Quality Improvement Plan
System
Requirements
Final
System Test
Validation Plan
Functional
Decomposition
Verification Plan
Verify
Subsystems
om
n
tio
si
po
Test
Components
Build
Components
The design downstroke and the manufacturing upstroke
In
te
gr
a
ec
Test Plan
tio
n
D
Physical
Decomposition
Cost evolution for a typical project
100
Final costs locked-in
Cost (%)
80
60
Actual
expenditures
40
20
0
Concept
development Full-scale
design
Start of
production
Time
The systems engineering process
Customer
Needs
State the
Problem
Investigate
Alternatives
Model the
System
Integrate
Launch
the System
Assess
Performance
Re-evaluate
Re-evaluate
Re-evaluate
Re-evaluate
Re-evaluate
Re-evaluate
But, it is not a serial process.
It is parallel and highly iterative
Outputs
SE is not a waterfall process
a waterfall
process
Discover
Requirements
Design
Build
Integrate
Test
Systems engineering is not
Requirements
Designs
Manufacturing
a throw it over the wall process
Systems engineering is a fractal process
System
Subsystem-1
Subsystem-2
Subsystem-3
Component-1
Component-2
Component-3
Assembly-1
Assembly-2
Assembly-3
The systems engineering process is applied at levels of greater
and greater detail. It is applied to the system, then to the
subsystems, then to the components, etc. Similarly for the
fractal pattern above, the same algorithm was applied at the
large structural level, then at the medium-scale level, then at
the fine-detail level, etc.
Incremental iterations
• Even the lowest level systems are
developed with iterations.
• The designs get bigger with each iteration.
• This allows manufacturing to overlap
design.
The foundation for a successful project
• Complete the problem statement before
defining the requirements.
• Avoid stating the problem in terms of
solutions.
• Involve the customer in the process of
defining the problem and the requirements.
• Early in the system design consult all
stakeholders (including manufacturing) about
system requirements
Validation and verification
• Validation:
building the right system
• Verification:
building the system right
Validating requirements
means ensuring that
• the set of requirements is complete and
consistent,
• a real-world solution can be built that satisfies the
requirements, and
• it can be proven that a real-world system satisfies
the requirements.
• If the requirements specify a perpetual-motion
machine, the project should be stopped.
Verifying requirements
Each requirement must be verified by
–
–
–
–
–
–
–
Logical argument
Inspection
Modeling
Simulation
Analysis
Test
Demonstration
Investigate Alternative Concepts
• The systems engineer’s job is to
capture the values and
preferences of the decision
maker, so that the decision
maker (and other stakeholders)
will have confidence in the
decision.
• The decision maker balances
effort with confidence*
• Often this requires
a formal tradeoff
study.
Components of a tradeoff study
•
•
•
•
•
•
•
•
•
•
Problem statement
Evaluation criteria
Weights of importance
Alternative solutions
Evaluation data
Scoring functions
Scores
Combining functions
Preferred alternatives
Sensitivity analysis
Model the System
Modelling myths and the reality
• The modelling process:
– how should you model?
– when should you model?
– to what depth
• Benefits of modelling:
– why are you modelling?
– what value does a model give you?
Where are models used?
• Everywhere:
• Cooking:
– recipe is a process model for a cake
– shopping list is a quantity and cost model
– picture of the output is a graphical model
• Bridge design
–
–
–
–
Gant chart is a process model
Bill of materials a quantity and cost model
Loading calculations are mathematical model
blueprint is a graphical model
Modelling Myths
1. You can think everything through from
the start
2. Modelling is a waste of time
3. The world revolves about modelling
languages
4. All system engineers know how to
model
Myth 1
• You can think everything through from
the start
– managers attempt to freeze requirements
at an early stage of development
The reality
• Paralysis through analysis:
– Spend so long modelling to an infinite level
of detail to determine correct requirements
that the model adds little relative value to
the project
• Build exactly what the customer thinks
he wants, not what he needs:
– No true discussion on requirements leads
to development of incorrect solutions
Myth 2
•
Modelling is a waste of time
The Reality
• “The software
development process is
essentially the same as it
was 40 years ago…”
• “Embedded system
engineers are under
tremendous time-to
market pressure...”
• Doubling the software
size causes the
development time to
increase by a factor of 10
!
The Reality
• 72.8% of Projects are late and the average delay
is 3.8 months
• 86.5% miss functionality expectations
• Embedded designs will double from 2000 to 2003
• Hardware design resources will need to grow
7.7%
• Embedded programming resources will need to
increase by almost 50%…but it can only grow
20%
• Model based specifications are a way
to speed up the development
process and reduce costs (if used
properly)
Points to consider
• People need to ask two questions
– Where can you use models ?
– What benefit do they give ?
• Different stakeholders get different
benefits and use models differently
–
–
–
–
Customer
Systems Engineer
Software Engineer
Miscellaneous benefits dependant upon depth of
modelling and tools used
Myth 3
•
The world revolves about modelling
languages
The reality
• Modelling language is not a
methodology
• Modelling language is useful and have
its place
• Pick the methodology / tools /
processes that are appropriate
Myth 4
• All system engineers know how to
model
The reality
• Most people are creating static
paper/computer based models
• Most people are not taught how to
model, they learn from experience
• To model you need experience based
on domain, process and tool knowledge
Decomposition
• physical
• functional
What do we need to fly?
Physical
Decomposition
For centuries,
humans have been
unsuccessful in their
attempts to fly
because they used
physical
decomposition
(brain, eyes, legs,
and wings).
What do we need to fly?
Functional Decomposition
The Wright Brothers focused on three functions:
control, horizontal thrust, and vertical lift.
Sensitivity analysis
We must use sensitivity analysis because
intuition isn’t always enough.
What if ….
Risk management addresses
• System risk
– Performance, schedule and cost of the
product
• Project risk
• Business risk
– Financial and resource risks to the enterprise
• Safety, environmental and risks to the
public
Risk management
Good risk management will not prevent
bad things from happening. But when
bad things happen, good risk
management will have anticipated them
and will reduce their negative effects.
Risk factors are often coupled
C
Cost
Risk
Technical
Problems
ts
Requiremen
Project
Risk
ule
ed
ch
ms
dS
se
ble
res
Pr o
al
mp
Co chnic
Te
Lim
ite
Te
dF
ch
nic
un
ds
al
Pro
ble
ms
Performance
Risk
Sc
h
Sc ed
he ule
du
les slip
s
ns
u
r r ts
e
v ge
O
d
t
u
s
B
o
Schedule slips
Limited Funds
Schedule
Risk
Risk management
hign
Severity
low
low
Probability of failure
high
Extent of SE depends on risk
• At NASA, the probability of mission failure
was about 10-2, but the severity was near 1.
The product of these numbers was big, so
they did lots of systems engineering.
• At a big software house, the probability that a
new system will destroy user files was about
1, but their perceived severity was around
10-6. They did not care if users lost a few files.
Therefore, they did little systems engineering.
Example - Scenario
• It’s a clear morning
• Temperature below -10 ºC
• A dozen skiers are scheduled to fly to
Grenoble, France
• But there is a half inch of ice on the
runway
• As an airline dispatcher, how would you
manage this Icy Runway Risk?
Risk management
• Transfer: bus the skiers, thus transferring the
risk to bus lines
• Eliminate: cancel the flight
• Accept: send the plane as scheduled
• Mitigate
–
–
–
–
Request removal of ice from runway
Change runways
Change equipment (different type of aircraft)
Change crew
Ignore
• How about ignoring the risk?
• Not acceptable.
• There is no I in TEAM.
SE creates a system of systems
• The product
• The process that produces the product
–
–
–
–
–
–
–
–
The design and development system
The testing system
The production and manufacturing system
The operating system
The maintenance system
The performance evaluation system
The customer service system
The retirement and replacement system
Interfaces
Interface control definitions (ICDs) define
and document the interfaces among
components.
System integration
Interfaces
Between
Subsystems
Interfaces
Between Our
System and the
Rest of the
World
Launch the System
• Configuration management
• Project management
The synergistic roles of SE and PM
• Systems engineering creates
the product documents.
• Project management creates
the process documents.
Creating a new office complex
Systems engineering
Creates the product
Doing the right things
What is it for?
Who is it for?
Alternative concepts
Buy, build or lease
Concrete building or
trailers
Total life cycle cost
Get customer feedback
Create plans
Project management
Creates the process
Doing things right
How to build
When to build
Where to build
Cost to build
Get feedback
Build to plans
Total system test
“People do what you inspect,
not what you expect.”
Make sure that all tasks are done
State the problem
Understand customer
needs
Discover
requirements
System validation
Investigate
alternatives
Define quantitative
measures
Model the system
Functional
decomposition
Design the system
Produce
documentation
Sensitivity analyses
Lead teams
Assess & manage risk Assess performance
Reliability analyses
Integrate system
components
Design & manage
interfaces
Configuration
management
Project management
Prescribe tests
Conduct reviews
Verify requirements
Perform total
system test
Re-evaluate &
Improve quality
Ask yourself “Why?”
• The systems engineering process must be
tailored for each project.
• Often this means omitting certain tasks,
which reduces cost but increases risk.
• If you choose to omit one of these tasks,
you should ask yourself, “Why?”
Summary
• Systems engineering is the glue that
holds it all together
• Systems engineering is responsible for
the big picture. It must ensure that the
system satisfies its requirements
throughout the entire system life cycle;
from birth to death.
Back to basics - can we define
Bart Simpson’s Guide to
Systems Engineering?
H.Sillitto
INCOSE UK Autumn 2004 Assembly
The customer
• I want reassurance that I will get what I
asked for and am paying for.
• If the supplier has to change things or has to
do trade-offs I won’t feel hoodwinked but will
be included in the process.
• Traceability will allow me to understand how
technical features relate to my needs and
help me to decide when it is worth persisting
to solve difficult technical problems.
The CEO
• I have been offered all sorts of silver bullets
over the past ten years - EFQM, 6 sigma, TQM
- and none has delivered the claimed benefits.
• I agree most of my projects are running late
and I’d like to improve that situation.
• But you’re telling me that systems engineering
will add delays up front.
• So if you want me to take you seriously, you
have to show me the ROI from introducing
systems engineering - and prove it!
Technical Director of 10-man SME
• I want systems engineering sold as a
simple exercise to integrating
engineering activities to deliver what’s
wanted when it’s wanted, and give me
a broad perspective on the technical
aspects of the business.
Prime minister
• Systems engineering would be interesting if it can
resolve conflicts to deliver vital public services health service - transportation - schools - and
deal with the huge security issues we now face.
• This is important to me because I want to make
sure I am remembered for the enduring success
of the achievements of my three terms in office
• But there isn’t much time left and I need results
soon.
17-year-old
• Can you explain to me what you do at work
in 2 minutes in words I can understand?
• Why are you often so stressed when you get
home?
• Can you make me a mobile that looks cool
and works properly?
• Will I get paid more as a systems engineer
than as an accountant?
• And by the way, can I have the car keys
please?
Undergraduate
• I’ve only been involved in systems engineering
for 2 months and lots of people have described
systems engineering to me but all the
descriptions are different.
• A “unified theory of everything” would be a
really good idea.
• We need to show how systems engineering
works with other disciplines and what other
disciplines need to understand about systems
engineering.
Recent graduate
• What does a systems engineer do?
– The SE community needs to know what they are selling, and know
how to sell it and show benefits to different groups.
• Show SE is part of all engineering disciplines
– make sure undergraduates on other engineering courses understand
SE needs to be part of their skill base, show them how what they
are learning can be applied within SE
– show the undergrads what they can expect in the future - NOT ALL
OF THEM WILL BE RIGHT FOR SE. Empower them with the
information to make that decision for themselves.
• Unified theory - very difficult but necessary
– SE has many definitions (some complementary, some at different
ends of spectrum)
– Fewer diagrams/processes/lifecycles but better defined;
– Simplify language, remove buzzwords
• Communication very important - relate ideas to known
domains, everyday events,
– Simple ideas, analogies, case studies: supermarket choice,
mountaineering, - – Sell through use of SE on real projects: show successes/failures of
exciting projects with/without SE
– Successes - Battle of Britain - failures - many defence projects
• Final thought
– It’s not just about recruiting new systems engineers - it’s also
making sure that other undergrads understand the role of SE at an
early stage in their career
– Consider re-branding: “Structured problem solving” does it for
schoolkids!