Chapter 19 – Systems Engineering
26/11/2014 Chapter 19 Systems Engineering 1
Systems
Software engineering is not an isolated activity but is part
of a broader systems engineering process.
Software systems are therefore not isolated systems but
are essential components of broader systems that have
a human, social or organizational purpose.
Example
Wilderness weather system is part of broader weather recording
and forecasting systems
These include hardware and software, forecasting processes,
system users, the organizations that depend on weather
forecasts, etc.
26/11/2014 Chapter 19 Systems Engineering 2
Types of system
Technical computer-based systems
Include hardware and software but not humans or organizational
processes.
Off the shelf applications, control systems, etc.
Sociotechnical systems
Include technical systems plus people who use and manage
these systems and the organizations that own the systems and
set policies for their use.
Business systems, command and control systems, etc.
26/11/2014 Chapter 19 Systems Engineering 3
Systems engineering
Procuring, specifying, designing, implementing,
validating, deploying and maintaining sociotechnical
systems.
Concerned with the services provided by the system,
constraints on its construction and operation and the
ways in which it is used to fulfil its purpose or purposes.
26/11/2014 Chapter 19 Systems Engineering 4
Systems and software engineering
Software is now the dominant element in all enterprise
systems. Software engineers have to play a more active
part in high-level systems decision making if the system
software is to be dependable and developed on time and
to budget.
As a software engineer, it helps if you have a broader
awareness of how software interacts with other hardware
and software systems, and the human, social and
organizational factors that affect the ways in which
software is used.
26/11/2014 Chapter 19 Systems Engineering 5
Stages of systems engineering
26/11/2014 Chapter 19 Systems Engineering 6
Systems engineering stages
Conceptual design
Sets out the purpose of the system, why it is needed and the
high-level features that users might expect to see in the system
Procurement or acquisition
The conceptual design is developed so that decisions about the
contract for the system development can be made.
Development
Hardware and software is engineered and operational processes
defined.
Operation
The system is deployed and used for its intended purpose.
26/11/2014 Chapter 19 Systems Engineering 7
Stages of systems engineering
26/11/2014 Chapter 19 Systems Engineering 8
Professional disciplines involved
26/11/2014 Chapter 19 Systems Engineering 9
Inter-disciplinary working
Communication difficulties
Different disciplines use the same terminology to mean different
things. This can lead to misunderstandings about what will be
implemented.
Differing assumptions
Each discipline makes assumptions about what can and can’t be
done by other disciplines.
Professional boundaries
Each discipline tries to protect their professional boundaries and
expertise and this affects their judgments on the system.
26/11/2014 Chapter 19 Systems Engineering 10
Sociotechnical systems
26/11/2014 Chapter 19 Systems Engineering 11
Sociotechnical systems
Large-scale systems that do not just include software
and hardware but also people, processes and
organizational policies.
Sociotechnical systems are often ‘systems of systems’
i.e. are made up of a number of independent systems.
Systems of systems are covered in Chapter 20
The boundaries of sociotechnical system are subjective
rather than objective
Different people see the system in different ways
26/11/2014 Chapter 19 Systems Engineering 12
Layered structure of sociotechnical systems
26/11/2014 Chapter 19 Systems Engineering 13
Systems and organizations
Sociotechnical systems are used within organizations
and are therefore profoundly affected by the
organizational environment in which they are used.
Failure to take this environment into account when
designing the system is likely to lead to user
dissatisfaction and system rejection.
26/11/2014 Chapter 19 Systems Engineering 14
Organisational elements
26/11/2014 Chapter 19 Systems Engineering 15
Organizational affects
Process changes
Systems may require changes to business processes so training
may be required. Significant changes may be resisted by users.
Job changes
Systems may de-skill users or cause changes to the way they
work. The status of individuals may be affected by a new
system.
Organizational policies
The proposed system may not be consistent with current
organizational policies.
Organizational politics
Systems may change the political power structure in an
26/11/2014organization. Those Chapter
that control the system have more power.
19 Systems Engineering 16
Complex systems
A system may include software, mechanical, electrical
and electronic hardware and be operated by people.
System components are dependent on other
system components.
The properties and behaviour of system components
are inextricably inter-mingled. This leads to
complexity.
Complexity is the reason why sociotechnical systems
have emergent properties, are non-deterministic and
have subjective success criteria.
26/11/2014 Chapter 19 Systems Engineering 17
Socio-technical system characteristics
Emergent properties
Properties of the system of a whole that depend on the system
components and their relationships.
Non-deterministic
They do not always produce the same output when presented
with the same input because the systems’s behaviour is partially
dependent on human operators.
Complex relationships with organisational objectives
The extent to which the system supports organisational
objectives does not just depend on the system itself.
26/11/2014 Chapter 19 Systems Engineering 18
Emergent properties
Properties of the system as a whole rather than
properties that can be derived from the properties of
components of a system
Emergent properties are a consequence of the
relationships between system components
They can therefore only be assessed and measured
once the components have been integrated into a
system
26/11/2014 Chapter 19 Systems Engineering 19
Examples of emergent properties
Property Description
Reliability System reliability depends on component reliability but unexpected
interactions can cause new types of failures and therefore affect the reliability
of the system.
Repairability This property reflects how easy it is to fix a problem with the system once it
has been discovered. It depends on being able to diagnose the problem,
access the components that are faulty, and modify or replace these
components.
Security The security of the system (its ability to resist attack) is a complex property
that cannot be easily measured. Attacks may be devised that were not
anticipated by the system designers and so may defeat built-in safeguards.
Usability This property reflects how easy it is to use the system. It depends on the
technical system components, its operators, and its operating environment.
Volume The volume of a system (the total space occupied) varies depending on how
the component assemblies are arranged and connected.
26/11/2014 Chapter 19 Systems Engineering 20
Types of emergent property
Functional properties
These appear when all the parts of a system work together to
achieve some objective. For example, a bicycle has the
functional property of being a transportation device once it has
been assembled from its components.
Non-functional emergent properties
Examples are reliability, performance, safety, and security.
These relate to the behaviour of the system in its operational
environment. They are often critical for computer-based systems
as failure to achieve some minimal defined level in these
properties may make the system unusable.
26/11/2014 Chapter 19 Systems Engineering 21
Reliability as an emergent property
Because of component inter-dependencies,
faults can be propagated through the system.
System failures often occur because of
unforeseen inter-relationships between
components.
It is practically impossible to anticipate all
possible component relationships.
Software reliability measures may give a false
picture of the overall system reliability.
26/11/2014 Chapter 19 Systems Engineering 22
Influences on reliability
Hardware reliability
What is the probability of a hardware component failing and how
long does it take to repair that component?
Software reliability
How likely is it that a software component will produce an
incorrect output. Software failure is usually distinct from
hardware failure in that software does not wear out.
Operator reliability
How likely is it that the operator of a system will make an error?
Failures are not independent and they propagate from
one level to another.
26/11/2014 Chapter 19 Systems Engineering 23
Failure propagation
26/11/2014 Chapter 19 Systems Engineering 24
Reliability and system context
System reliability depends on the context where the
system is used.
A system that is reliable in one environment may be less
reliable in a different environment because the physical
conditions (e.g. the temperature) and the mode of
operation is different.
26/11/2014 Chapter 19 Systems Engineering 25
Non-determinism
A deterministic system is one where a given sequence of
inputs will always produce the same sequence of
outputs.
Software systems are deterministic; systems that include
humans are non-deterministic
A socio-technical system will not always produce the same
sequence of outputs from the same input sequence
Human elements
• People do not always behave in the same way
System changes
• System behaviour is unpredictable because of frequent changes to
hardware, software and data.
26/11/2014 Chapter 19 Systems Engineering 26
Success criteria
Complex systems are developed to address ‘wicked
problems’ – problems where there cannot be a complete
specification.
Different stakeholders see the problem in different ways
and each has a partial understanding of the issues
affecting the system.
Consequently, different stakeholders have their own
views about whether or not a system is ‘successful’
Success is a judgment and cannot be objectively measured.
Success is judged using the effectiveness of the system when
deployed rather than judged against the original reasons for
procuement.
26/11/2014 Chapter 19 Systems Engineering 27
Conflicting views of success
The Mentcare system is designed to support multiple,
conflicting goals
Improve quality of care.
Provide better information and care costs and so increase
revenue.
Fundamental conflict
Doctors and nurses had to provide additional information over
and above that required for clinical purposes.
They had less time to interact with patients, so quality of care
reduced. System was not a success.
However, managers had better reports
System was a success from a managerial perspective.
26/11/2014 Chapter 19 Systems Engineering 28
