5/2/2014

1
Know what is meant by socio-technical system and
understand the difference between a technical computer-
based system and a socio-technical system
Have been introduced to the concept of emergent system
properties such as reliability, performance, safety and
security
Understand the activities that are involved in the systems
engineering process
Understand why the organizational context of a system
affects its design and use
Know what is meant by a legacy system, and why these
systems are often critical to the operation of many business
2
What is a system?
A purposeful collection of inter-related components that
work together to achieve some 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 behavior of system components are
inextricably inter-mingled
3
5/2/2014
2
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 organizational
policies and rules.

4
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 behavior is partially
dependent on human operators.
Complex relationships with organizational objectives
The extent to which the system supports organizational objectives
does not just depend on the system itself.

5
Emergent system properties
System engineering
Organizations, people and computer systems
Legacy systems
6
5/2/2014
3
Properties of the system as a whole rather than
properties that can be derived from the properties
of components of a system
a consequence of the relationships between system
components
only be assessed and measured once the components
have been integrated into a system
7
Volume
Total space occupied
Reliability
Depends on component reliability
Unexpected interactions cause new failure
Security
Ability to resist attack
Reparability
How easy to fix a problem
Usability
How easy to use the system
8
Functional emergent properties
All the parts of a system work together to achieve some
objective
a bicycle has the functional property of being a transportation
device once it has been assembled from its components.
Non-functional emergent properties
Relate to the behavior of the system in its operational
environment
Reliability, performance, safety, and security
Critical for computer-based systems
Failure to achieve some minimal defined level in these properties
may make the system unusable.
9
5/2/2014
4
Consider the property of system reliability
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 probably impossible to anticipate all
possible component relationships.
Software reliability measures may give a false
picture of the system reliability.
10
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?
11
Hardware failure can generate spurious signals that
are outside the range of inputs expected by the
software.
Software errors can cause alarms to be activated
which cause operator stress and lead to operator
errors.
The environment in which a system is installed can
affect its reliability.
12
5/2/2014
5
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
Knowing a system is insecure only when someone breaks
into it
13
The activity of specifying, designing, implementing,
validating, deploying and maintaining socio-
technical systems
Concerned with
Software
Hardware
Systems interactions with users and its environment
14
15
5/2/2014
6
Limited scope for rework during system
development
Little scope for iteration between phases because
hardware changes are very expensive
Interdisciplinary involvement
Inevitably involve engineers from different disciplines who
must work together
Different engineers use different terminology and
conventions
16
17
ATC syst ems
engineering
Elect ronic
engineering
Elect rical
engineering
User int erface
design
Mechanical
engineering
Archit ecture
St ruct ural
engineering
Software
engineering
Civil
engineering
Specify
What the system should do (its functions)
Essential and desirable system properties
Involve consultations with system customers/end-users

Derive three types of requirement
Abstract functional requirements
Basic functions at an abstract level
System properties
Non-functional emergent system properties
Characteristics that the system must no exhibit
Must not do vs. should do
e.g. Too much information should not be presented to the controller
18
5/2/2014
7
To establish a set of overall objectives that the
system should meet
Functional objectives
To provide a fire and intruder alarm system for the building which
will provide internal and external warning of fire or unauthorized
intrusion.
Organizational objectives
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.
19
Complex systems are usually developed to address
wicked problems
So many related entities that there is no definitive
problem specification
An extreme example
Earthquake planning
20
How the system functionality is to be provided by
the components of the system
Partition requirements
Analyze requirements and organize them into related groups
Identify sub-systems
Individually or collectively meet the requirements
Assign requirements to sub-systems
Never a clean match between requirements partitions and
identified sub-systems
Specify sub-system functionality
Define sub-system interfaces
21
5/2/2014
8
Double-ended arrows
A lot of feedback and iteration from one stage to another in the
design process
22
Requirements affect design decisions and vice versa
In practice, the are inextricably linked
Constraints posed by the existing systems may
Limit design choices
These choices may be specified in the requirements
Initial design may be necessary to structure the
requirements.
As you do design, you learn more about the
requirements.
23
24
5/2/2014
9
An architectural model
A set of components (sub-systems) and their relationships
An abstract view of the sub-systems making up a system
More appropriate to classify sub-systems according to
their function
Before making decisions about hardware/software trade-offs
Illustrated graphically and presented as a block diagram
Be supplemented by brief descriptions of each subsystem
May be used for all sizes of system
25
26
27
5/2/2014
10
The implementation may involve starting
Another system engineering process
A software process
Commercial off-the-shelf (COTS) systems are
bought for integration into the system
May reenter the design activity
Usually developed in parallel
Problems cutting across sub-system boundaries are
encountered
A system modification must be made - changes in the software
requirements
28
Putting hardware, software and people together to make a
complete system
Two approaches
A big bang approach
All sub-systems are integrated at the same time
An incremental integration approach
Sub-systems are integrated one at a time
Best approach
Impossible to finish all sub-systems at the same time
Reduce the cost of error location
An extensive program of system testing
The interfaces between components
The behavior of the system as a whole
29
After completion, the system has to be installed in
the customers 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
30
5/2/2014
11
Complex systems have a very long lifetime
To correct errors
To implement new requirements
Evolution is inherently costly
Changes must be analyzed 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.

31
Taking the system out of service after its useful
operation 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
32
Socio-technical systems
Enterprise systems to deliver some
organizational/business goal
Embedded in an organizational environment
Need to understand its organizational environment
Human and organizational factors
Process changes
Require changes to the work processes?
Job changes
De-skill the users or change the way they work?
Organizational changes
Change the political power structure in an organization?
33
5/2/2014
12
The development process interacts with
The procurement process
Making decisions about
The best way to acquire a system
The best suppliers
The operational process
Using the system for its intended purpose
34
Large complex systems
a mixture of off-the-shelf and specially built components
Important points
Off-the-shelf components do not usually match
requirements exactly
May have to modify the requirements
The specification of requirements acts as the basis of a
contract for a specially built system
A legal and technical document
After a contractor has been selected, there is a contract
negotiation period
35
36
5/2/2014
13
Large computer-based systems usually have a long
lifetime
20 years for military systems
Air traffic control (ATC) relies on software and operational
processes that were developed in the 1960s and 1970s
Too expensive and too risky to discard such business
critical systems after a few years of use
Their development continues throughout their life
with changes
Requirements
Operating platforms
37
Socio-technical computer-based systems that
developed in the past using older or obsolete
technology
Hardware and software
Legacy processes and procedures
Often business-critical systems
Too risky to replace them
e.g. bank customer accounting system
e.g. aircraft maintenance system
Constrain new business processes and consume a
high proportion of company budgets
38
39
5/2/2014
14
40
Socio-techni cal system
Hardware
Support soft ware
Applicat ion soft ware
Business processes
Ku-Yaw Chang
canseco@mail.dyu.edu.tw

Assistant Professor
Department of Computer Science and Information Engineering
Da-Yeh University