|
Introduction to Software
Engineering |
|
Lecture 10 – Sociotechnical
Systems |
Topics
covered
² Complex
systems
² Systems
engineering
² Systems
procurement
² System
development
² System
operation
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.
The
sociotechnical systems stack
Layers
in the STS stack
² Equipment
§
Hardware devices, some of which may be computers.
Most devices will include an embedded system of some kind.
² Operating
system
§
Provides a set of common facilities for higher
levels in the system.
² Communications
and data management
§
Middleware that provides access to remote systems
and databases.
² Application
systems
§
Specific functionality to meet some organization
requirements.
² Business
processes
§
A set of processes involving people and computer
systems that support the activities of the business.
² Organizations
§
Higher level strategic business activities that
affect the operation of the system.
² Society
§
Laws, regulation and culture that affect the
operation of the system.
Holistic
system design
² There
are interactions and dependencies between the layers in a system and changes at
one level ripple through the other levels
§
Example: Change in regulations (society) leads to
changes in business processes and application software.
² For
dependability, a systems perspective is essential
§
Contain software failures within the enclosing
layers of the STS stack.
§
Understand how faults and failures in adjacent
layers may affect the software in a system.
Complex systems
² A system is 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. This leads to complexity.
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.
§ Example: A word processor
used to write a book.
² 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.
§ Example: A publishing
system to produce a book.
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 in an organization may be affected by
the introduction of a new system.
² Organizational
changes
§
Systems may change the political power structure in
an organization. If an organization depends on a system than those that control
the system have more power.
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.
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
Examples
of emergent properties
|
Property |
Description |
|
Volume |
The volume of a system (the total space occupied) varies depending on
how the component assemblies are arranged and connected. |
|
Reliability |
System reliability depends on component reliability but unexpected
interactions can cause new types of failures and therefore affect the
reliability of the system. |
|
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. |
|
Reparability |
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. |
|
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. |
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.
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.
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.
Failure
propagation
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.
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 procurement.
Conflicting
views of success
² MHC-PMS
designed to support multiple, conflicting goals
§
Improve quality of care.
§
Provide better information and care costs and so
increase revenue.
² Fundamental
conflict
§
To satisfy reporting goal, 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.
Systems
engineering
² Procuring,
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 to fulfill its purpose or purposes.
Stages
of systems engineering
² Procurement
(acquisition)
§
The purpose of the system is established,
high-level system requirements are defined, decisions are made on how
functionality is distributed and the system components are purchased.
² Development
§
The system is developed – requirements are defined
in detail, the system is implemented and tested and operational processes are
defined.
² Operation
§
The system is deployed and put into use. Changes
are made as new requirements emerge. Eventually, the system is decommissioned.
Security
and dependability considerations
² Design
options limited by procurement decisions
§
Purchased components may make some safeguards
impossible to implement.
² Human
errors made during development may introduce faults into the system.
² Inadequate
testing may mean faults are not discovered before deployment.
² Configuration
errors during deployment may introduce vulnerabilities.
² Assumptions
made during procurement may be forgotten when system changes are made.
Professional
disciplines involved in systems engineering
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.
Key
points
² Socio-technical systems include computer hardware,
software and people and are designed to meet some business goal.
² Human and organizational factors, such as the
organizational structure, have a significant effect on the operation of
socio-technical systems.
² Emergent properties are properties that are
characteristic of the system as a whole and not its component parts.
² The fundamental stages of systems engineering are
procurement, development and operation.
System
procurement
² Acquiring
a system (or systems) to meet some identified organizational need.
² Before
procurement, decisions are made on:
§
Scope of the system
§
System budgets and timescales
§
High-level system requirements
² Based
on this information, decisions are made on whether to procure a system, the
type of system and the potential system suppliers.
Decision
drivers
² The
state of other organizational systems
² The
need to comply with external regulations
² External
competition
² Business
re-organization
² Available
budget
Procurement and development
² Some system specification
and architectural design is usually necessary before procurement
§ You need a specification to
let a contract for system development
§ The specification may allow
you to buy a commercial off-the-shelf (COTS) system. Almost always cheaper than
developing a system from scratch
² Large complex systems usually consist of a mix of
off the shelf and specially designed components. The procurement processes for
these different types of component are usually different.
System
procurement processes
Procurement issues
² Requirements may have to be modified to match the
capabilities of off-the-shelf components.
² The requirements specification may be part of the
contract for the development of the system.
² There is usually a contract negotiation period to
agree changes after the contractor to build a system has been selected.
Contractors and
sub-contractors
· The procurement of large hardware/software systems
is usually based around some principal contractor.
· Sub-contracts are issued to other suppliers to
supply parts of the system.
· Customer liases with the
principal contractor and does not deal directly with sub-contractors.
Procurement
and dependability
· Procurement
decisions have profound effects on system dependability as these decisions
limit the scope of dependability requirements.
· For
an off-the-shelf system, the procurer has very limited influence on the
security and dependability requirements of the system.
· For
a custom system, considerable effort has to be expended in defining security
and dependability requirements.
System development
² Usually follows a plan-driven approach 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.
§
As explained, different disciplines use a different
vocabulary and much negotiation is required. Engineers may have personal
agendas to fulfil.
Systems
development
System requirements definition
o Three types of requirement defined at this stage
§
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.
o Should also define overall organisational
objectives for the system.
The system design process
² Partition requirements
§
Organise requirements into related groups.
² Identify sub-systems
§
Identify a set of sub-systems which collectively can meet the system
requirements.
² Assign requirements to sub-systems
§
Causes particular problems when COTS are integrated.
² Specify sub-system functionality.
² Define sub-system interfaces
§
Critical activity for parallel sub-system development.
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.
Requirements
and design spiral
Sub-system development
· Typically parallel projects developing the
hardware, software and communications.
· May involve some COTS (Commercial Off-the-Shelf) systems
procurement.
· Lack of communication across implementation teams
can cause problems.
· There may be a bureaucratic and slow mechanism for proposing
system changes, which means that the development schedule may be extended
because of the need for rework.
System integration
² The process of putting hardware, software and people
together to make a system.
² Should ideally be tackled incrementally so that
sub-systems are integrated one at a time.
² The system is tested as it is integrated.
² Interface problems between sub-systems are usually
found at this stage.
² May be problems with uncoordinated deliveries of
system components.
System delivery and deployment
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);
·
Data clean-up may be
required;
·
Operator training has to be
identified.
Development
and dependability
² Decisions
are made on dependability and security requirements and trade-offs made between
costs, schedule, performance and dependability.
² Human
errors may lead to the introduction of faults into the system.
² Testing
and validation processes may be limited because of limited budgets.
² Problems
in deployment mean there may be a mismatch between the system and its
operational environment.
System
operation
· Operational
processes are the processes involved in using the system for its defined
purpose.
· For
new systems, these processes may have to be designed and tested and operators
trained in the use of the system.
· Operational
processes should be flexible to allow operators to cope with problems and
periods of fluctuating workload.
Human
error
o Human
errors occur in operational processes that influence the overall dependability
of the system.
o Viewing
human errors:
§
The person
approach makes errors the responsibility of the individual and places the blame
for error on the operator concerned. Actions to reduce error include threats of
punishment, better training, more stringent procedures, etc.
§
The systems
approach assumes that people are fallible and will make mistakes. The system is
designed to detect these mistakes before they lead to system failure. When a
failure occurs, the aim is not to blame an individual but to understand why the
system defenses did not trap the error.
System
defenses
² To
improve security and dependability, designers should think about the checks for
human error that should be included in a system.
² As
I discuss in later lectures, there should be multiple (redundant) barriers
which should be different (diverse)
² No
single barrier can be perfect.
§
There will be latent conditions in the system that
may lead to failure.
² However,
with multiple barriers, all have to fail for a system failure to occur.
Reason’s
Swiss cheese model of system failure
Defenses
in an Air Traffic Control system
² Conflict
alert system
§
Raises an audible alarm when aircraft are on
conflicting paths
² Recording
of instructions
§
Allows instructions issues to be reviewed and
checked.
² Sharing
of information
§
The team of controllers cross-check each other’s
work.
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.
Evolution
and dependability
² Changes
to a system are often a source of problems and vulnerabilities.
² Changes
may be made without knowledge of previous design decisions made for security
and dependability reasons.
§
Built-in
safeguards may stop working.
² New
faults may be introduced or latent faults exposed by changes.
§
These may not
be discovered because complete system retesting is too expensive.
Key
points
· System procurement covers all of the activities
involved in deciding what system to buy and who should supply that system.
· System development includes requirements
specification, design, construction, integration and testing.
· When a system is put into use, the operational
processes and the system itself have to change to reflect changing business
requirements.
· Human errors are inevitable and systems should
include barriers to detect these errors before they lead to system failure.