Transcript Systems Engineering - University of Nebraska Omaha

The Big Picture
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 1
Outline

Socio-technical systems
•
•
•
•

Software as part of the system
People and organisations
Systems engineering
Legacy systems
Critical systems
•
•
Dimensions of system dependability
Engineering dependable systems
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 2
What is a system?




A purposeful collection of inter-related components
working together to achieve some common objective.
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
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 3
System categories

Technical computer-based systems
•

Systems that include hardware and software but
where the operators and operational processes are
not normally considered to be part of the system.
The system is not self-aware.
Socio-technical systems
•
Systems that include technical systems but also
operational processes and people who use and
interact with the technical system. Socio-technical
systems are governed by organisational policies and
rules.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 4
Socio-technical system characteristics

Emergent properties
•

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
•

Properties of the system of a whole that depend on the system
components and their relationships.
The extent to which the system supports organisational
objectives does not just depend on the system itself.
Susceptible to “wicked problems”
•
Solving one problem uncovers a more complex problem
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 5
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
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 6
Types of emergent properties

Functional emergent properties
•

These appear when all the parts of a system work together to
achieve some objective. For example, for IPTV to work, a
suitable network infrastructure must be in place.
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.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 7
Organizations: The Bigger Picture


Socio-technical systems are organisational
systems intended to help deliver some
organisational or business goal.
If you do not understand the organisational
environment where a system is used, the system
is less likely to meet the real needs of the
business and its users.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 8
Human and organisational factors

Process changes
•

Job changes
•

Does the system require changes to the work
processes in the environment?
Does the system de-skill the users in an environment or
cause them to change the way they work?
Organisational changes
•
Does the system change the political power structure in
an organisation?
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 9
Systems engineering


Specifying, designing, implementing, validating,
deploying and maintaining socio-technical
systems.
Concerned with the services provided by the
system, constraints on its construction and
operation and the ways in which it is used.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 10
The system engineering process

Usually follows a ‘waterfall’ model because of the need
for parallel development of different parts of the system
•

Little scope for iteration between phases because hardware
changes are very expensive. Software may have to
compensate for hardware problems.
Inevitably involves engineers from different disciplines
who must work together
•
Much scope for misunderstanding here. Different disciplines
use a different vocabulary and much negotiation is required.
Engineers may have personal agendas to fulfil.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 11
The systems engineering process
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 12
System objectives


Should define why a system is needed for a
particular environment.
Example: functional objective
•

To provide a fire and intruder alarm system for the
building which will provide internal and external
warning of fire or unauthorized intrusion.
Example: organisational objective
•
To ensure that the normal functioning of work carried
out in the building is not seriously disrupted by
events such as fire and unauthorized intrusion.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 13
System requirements definition

Define system requirements
•
•
•


Abstract functional requirements. System functions are defined
in an abstract way;
System properties. Non-functional requirements for the system
in general are defined;
Undesirable characteristics. Unacceptable system behaviour is
specified.
Based on emergent properties
Define overall organisational objectives for the system.
•
•
•
Procurement processes
Life-cycle plans
Operational processes
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 14
System requirements problems

Complex systems are usually developed to
address wicked problems
•
•


Problems that are not fully understood;
True nature emerges only as the solution is being
developed.
Must anticipate hardware/communications
developments over the lifetime of the system.
Hard to define non-functional requirements
(particularly) without knowing the
component structure of the system.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 15
The system design process

Partition requirements
•

Identify sub-systems
•


Identify a set of sub-systems which collectively can meet the
system requirements.
Assign requirements to sub-systems
•

Organise requirements into related groups.
Causes particular problems when COTS are integrated.
Specify sub-system functionality.
Define sub-system interfaces
•
Critical activity for parallel sub-system development.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 16
The system design process
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 17
System design problems



Requirements partitioning to hardware,
software and human components may involve a
lot of negotiation.
Difficult design problems are often assumed to
be readily solved using software.
Hardware platforms may be inappropriate for
software requirements so software must
compensate for this.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 18
Requirements and design




Requirements engineering and system design
are inextricably linked.
Constraints posed by the system’s environment
and other systems limit design choices so the
actual design to be used may be a requirement.
Initial design may be necessary to structure the
requirements.
As you do design, you learn more about the
requirements.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 19
Spiral model of requirements/design
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 20
System modelling




An architectural model presents an abstract view
of the sub-systems making up a system
May include major information flows between
sub-systems
Usually presented as a block diagram
May identify different types of functional
component in the model
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 21
Sub-system development



Typically parallel projects developing the
hardware, software and communications.
May involve some COTS (Commercial Off-theShelf) systems procurement.
Continued communication (assumptions and
changes) across implementation teams is
crucial.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 22
System integration




The process of putting hardware, software and
people together to make a system.
Should be tackled incrementally so that subsystems are integrated one at a time.
Interface problems between sub-systems are
usually found at this stage.
May be problems with uncoordinated deliveries
of system components.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 23
System installation

After completion, the system has to be installed
in the customer’s environment
•
•
•
•
•
Environmental assumptions may be incorrect;
May be human resistance to the introduction of
a new system;
System may have to coexist with alternative
systems for some time;
May be physical installation problems (e.g.
cabling problems);
Operator training has to be identified.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 24
System evolution


Large systems have a long lifetime. They must evolve to
meet changing requirements.
Evolution is inherently costly
•
•
•
•

Changes must be analysed from a technical and business
perspective;
Sub-systems interact so unanticipated problems can arise;
There is rarely a rationale for original design decisions;
System structure is corrupted as changes are made to it.
Existing systems which must be maintained are
sometimes called legacy systems.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 25
System decommissioning


Taking the system out of service after its useful
lifetime.
May require removal of materials (e.g.
dangerous chemicals) which pollute the
environment
•

Should be planned for in the system design by
encapsulation.
May require data to be restructured and
converted to be used in some other system.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 26
Legacy systems


Socio-technical systems that have been developed using
old or obsolete technology.
Crucial to the operation of a business and it is often too
risky to discard these systems
•
•

Bank customer accounting system;
Aircraft maintenance system.
Legacy systems constrain new business processes and
consume a high proportion of company budgets.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 27
Support software
Runs-on
System
hardware
Based on originals from Sommerville
Uses
Runs-on
Embeds
knowledge of
Application
software
Uses
Business policies
and rules
Uses
Application
data
Software Engineering, 7th edition. Chapters 2 & 3
Constrains
Business
processes
Slide 28
Legacy system components






Hardware - may be obsolete mainframe hardware.
Support software - may rely on support software from
suppliers who are no longer in business.
Application software - may be written in obsolete
programming languages.
Application data - often incomplete and inconsistent.
Business processes - may be constrained by software
structure and functionality.
Business policies and rules - may be implicit and
embedded in the system software.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 29
Why can’t we just replace them?




Cannot justify the business case
Their function is too critical that its users could
not take the risk of replacing them with
something new (which almost always are not
error-free)
Customers do not like change (involves training
and possibly a steep learning curve)
Organization is used to doing things a certain
way
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 30
Critical Systems


Systems whose failure have severe human or economic
consequences
Safety-critical systems
•
•

Mission-critical systems
•
•

Failure results in loss of life, injury or damage to the
environment;
Chemical plant protection system;
Failure results in failure of some goal-directed activity;
Spacecraft navigation system;
Business-critical systems
•
•
Failure results in high economic losses;
Customer accounting system in a bank;
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 31
Long-distance telephone system
Focus on one Node (Oakland) – October 17, 1989
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 32
Dimensions of dependability
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 33
Availability and reliability

Reliability
•

Availability
•

The probability of failure-free system operation over
a specified time in a given environment for a given
purpose
The probability that a system, at a point in time, will
be operational and able to deliver the requested
services
Both of these attributes can be expressed
quantitatively (e.g., system uptime, MTTF, etc)
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 34
Availability and reliability

It is sometimes possible to subsume system
availability under system reliability
•


Obviously if a system is unavailable it is not
delivering the specified system services
However, it is possible to have systems with low
reliability that must be available. Solutions: fast
repair times, redundant systems.
Availability takes repair time into account
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 35
Reliability terminology
Term
Descri ption
System failure
An event that occurs at some point in t ime when
the system does not deliver a service as expected
by it s users
System error
An erroneous system state that can lead to system
behaviour that is unexpected by system users.
System fault
A characterist ic of a software system that can
lead to a system error. For example, failure to
init ialise a variable could lead to that variable
having t he wrong value wh en it is used.
Human error or
mistake
Human behaviour that results in the introduct ion
of faults into a system.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 36
Faults and failures


Failures are a usually a result of system errors that are
derived from faults in the system
However, faults do not necessarily result in system errors
•

The faulty system state may be transient and ‘corrected’ before
an error arises
Errors do not necessarily lead to system failures
•
•
The error can be corrected by built-in error detection and
recovery
The failure can be protected against by built-in protection
facilities. These may, for example, protect system resources
from system errors
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 37
Building reliable systems

Fault avoidance
•

Fault detection and removal
•

Development techniques are used that either minimise the
possibility of mistakes or trap mistakes before they result in the
introduction of system faults
Verification and validation techniques that increase the
probability of detecting and correcting errors before the system
goes into service are used
Fault tolerance
•
Run-time techniques are used to ensure that system faults do
not result in system errors and/or that system errors do not lead
to system failures
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 38
The ‘shall-not’ properties


Properties such as performance and reliability
can be measured.
However, some properties are properties that the
system should not exhibit
•
•

Safety - the system should not behave in an unsafe
way;
Security - the system should not permit unauthorised
use.
Measuring or assessing these properties is very
hard.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 39
Safety



Safety is a property of a system that reflects the system’s
ability to operate, normally or abnormally, without danger
of causing human injury or death and without damage to
the system’s environment
It is increasingly important to consider software safety as
more and more devices incorporate software-based
control systems
Safety requirements are exclusive requirements i.e. they
exclude undesirable situations rather than specify
required system services
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 40
Safety criticality

Primary safety-critical systems
•

Secondary safety-critical systems
•

Embedded software systems whose failure can cause the
associated hardware to fail and directly threaten people.
Systems whose failure results in faults in other systems which
can threaten people
Discussion here focuses on primary safety-critical
systems
•
Secondary safety-critical systems can only be considered on a
one-off basis
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 41
Safety and reliability

Safety and reliability are related but distinct
•


In general, reliability and availability are necessary
but not sufficient conditions for system safety
Reliability is concerned with conformance to a
given specification and delivery of service
Safety is concerned with ensuring system cannot
cause damage irrespective of whether
or not it conforms to its specification
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 42
Unsafe reliable systems

Specification errors
•

Hardware failures generating spurious inputs
•

If the system specification is incorrect then the
system can behave as specified but still cause an
accident
Hard to anticipate in the specification
Context-sensitive commands i.e. issuing the right
command at the wrong time
•
Often the result of operator error
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 43
Safety terminology
Term
Defi n ition
Accident (or
mishap)
An unplanned event or sequence of events which result s in human deat h or injury,
damage to property or to the environment . A computer-cont rolled machine injuring its
operator is an example of an accident.
Hazard
A condition with the potent ial for causing or contribut ing to an accident . A failure of
the sensor that detects an obstacle in front of a machine is an example of a hazard.
Damage
A measure of the loss result ing from a mishap. Damage can range from many people
killed as a result of an accident to minor injury or propert y damage.
Hazard
severity
An assessment of the worst possible damage that could result from a part icular
hazard. Hazard severity can range from catastrophic where many people are killed to
minor where only minor damage results.
Hazard
probabilit y
The probability of the event s occurring which create a hazard. Probability values tend
to be arbitrary but range from probable (say 1/100 chance of a hazard occurring) to
implausible (no conceivable sit uations are likely where the hazard could occur).
Risk
This is a measure of the probability that the system will cause an accident . The risk is
assessed by considering the hazard probability, the hazard severit y and the probability
that a hazard will result in an accident.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 44
Building safe systems

Hazard avoidance
•

Hazard detection and removal
•

The system is designed so that some classes of
hazard simply cannot arise.
The system is designed so that hazards are detected
and removed before they result in an accident
Damage limitation
•
The system includes protection features that
minimise the damage that may result from an
accident
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 45
Normal accidents

Accidents in complex systems rarely have a single cause
as these systems are designed to be resilient to a single
point of failure
•


Designing systems so that a single point of failure does not
cause an accident is a fundamental principle of safe systems
design
Almost all accidents are a result of combinations of
malfunctions
It is probably the case that anticipating all problem
combinations, especially, in software controlled systems
is impossible so achieving complete safety is impossible
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 46
Security



The security of a system is a system property
that reflects the system’s ability to protect itself
from accidental or deliberate external attack
Security is becoming increasingly important as
systems are networked so that external access
to the system through the Internet is possible
Security is an essential pre-requisite for
availability, reliability and safety
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 47
Fundamental security



If a system is a networked system and is
insecure then statements about its reliability and
its safety are unreliable
These statements depend on the executing
system and the developed system being the
same. However, intrusion can change the
executing system and/or its data
Therefore, the reliability and safety assurance is
no longer valid
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 48
Security terminology
Term
Defi n ition
Exposure
Possible loss or harm in a comput ing system. This can be loss or
damage to data or can be a loss of t ime and effort if recovery is
necessary after a security breach.
Vulnerability
A weakness in a computer-based system that may be exploited to
cause loss or harm.
At tack
An exploitation of a system vulnerability. Generally, this is from
outside the syst em and is a deliberate at tempt to cause some damage.
Threats
Circumst ances that have potent ial to cause loss or harm. You can
think of these as a syst em vulnerabilit y that is subjected t o an at tack.
Cont rol
A protective measure that reduces a system vulnerability. Encryption
would be an example of a control that reduced a vulnerability of a
weak access control system.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 49
Damage from security failures

Denial of service
•

Corruption of programs or data
•

The system is forced into a state where normal services are
unavailable or where service provision is significantly degraded
The programs or data in the system may be modified in an
unauthorised way
Disclosure of confidential information
•
Information that is managed by the system may be exposed to
people who are not authorised to read or use that information
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 50
Building secure systems

Vulnerability avoidance
•

Attack detection and elimination
•

The system is designed so that vulnerabilities do not occur. For
example, if there is no external network connection then
external attack is impossible
The system is designed so that attacks on vulnerabilities are
detected and neutralised before they result in an exposure. For
example, virus checkers find and remove viruses before they
infect a system
Exposure limitation
•
The system is designed so that the adverse consequences of a
successful attack are minimised. For example, a backup policy
allows damaged information to be restored
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 51
Other dependability properties

Repairability
•

Maintainability
•

Reflects the extent to which the system can be adapted to new
requirements;
Survivability
•

Reflects the extent to which the system can be repaired in the
event of a failure
Reflects the extent to which the system can deliver services
whilst under hostile attack;
Error tolerance
•
Reflects the extent to which user input errors can be avoided
and tolerated.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 52
Maintainability



A system attribute that is concerned with the
ease of repairing the system after a failure has
been discovered or changing the system to
include new features
Very important for critical systems as faults are
often introduced into a system because of
maintenance problems
Maintainability is distinct from other dimensions
of dependability because it is a static and not a
dynamic system attribute.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 53
Survivability



The ability of a system to continue to deliver its
services to users in the face of deliberate or
accidental attack
This is an increasingly important attribute for
distributed systems whose security can be
compromised
Survivability subsumes the notion of resilience the ability of a system to continue in operation in
spite of component failures
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 54
Development methods for critical systems


The costs of critical system failure are so high that
development methods may be used that are not costeffective for other types of system.
Examples of development methods
•
•
•


Formal methods of software development
Static analysis
External quality assurance
Developers of critical systems must guard against
potential hardware, software and operational failures
Strategies fall into the categories of avoidance, detection,
and mitigation
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 55
Causes of failures

Hardware failure
•

Software failure
•

Hardware fails because of design and manufacturing
errors or because components have reached the end
of their natural life.
Software fails due to errors in its specification,
design or implementation.
Operational failure
•
Human operators make mistakes. Now perhaps the
largest single cause of system failures.
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 56
Dependability costs


Dependability costs tend to increase
exponentially as increasing levels of
dependability are required
There are two reasons for this
•
•
The use of more expensive development techniques
and hardware that are required to achieve the higher
levels of dependability
The increased testing and system validation that is
required to convince the system client that the
required levels of dependability have been achieved
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 57
Costs of increasing dependability
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 58
Dependability economics



Because of very high costs of dependability
achievement, it may be more cost effective to
accept untrustworthy systems and pay for failure
costs
However, this depends on social and political
factors. A reputation for products that can’t be
trusted may lose future business
Depends on system type - for business systems
in particular, modest levels of dependability may
be adequate
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 59
Key points








Socio-technical systems include computer hardware, software and
people and are designed to meet some business goal.
Emergent properties are properties that are characteristic of the
system as a whole and not its component parts.
The systems engineering process must identify the system’s relevant
emergent properties and take organizational factors into account.
Legacy systems have one or more obsolete components.
Legacy systems are difficult to replace.
Critical systems failures lead to human or economic losses.
The cost of developing a critical system increases exponentially
relative to the level of system dependability required by its customer.
Dependability improvement requires a socio-technical approach to
design where you consider the humans as well as the hardware and
software
Based on originals from Sommerville
Software Engineering, 7th edition. Chapters 2 & 3
Slide 60