Socio-technical Systems

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1

 Objectives
z To explain system engineering and system procurement
processes
z To explain why the organisational context of a system
affects its design and use

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 2

 What is a system?
z Appurposeful
p collection of inter-related components
p
working together to achieve some common objective.
z A system may include software, mechanical, electrical
andd electronic
l t i h hardware
d and dbbe operated
t db
by people.
l
z System components are dependent on other
system components
z The properties and behaviour of system components are
inextricably inter-mingled

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 3

 System categories
z Technical computer-based
computer based systems
• Systems that include hardware and software but
where the operators and operational processes are
not normally
normall considered to be part of the ssystem.
stem
The system is not self-aware.
z Socio-technical systems
y
• Systems that include technical systems but also
operational processes and people who use and
interact with the technical system
system. Socio-technical
Socio technical
systems are governed by organisational policies and
rules.
• Not discussed

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 4

 Systems engineering
z Specifying, designing
Specifying designing, implementing
implementing, validating
validating,
deploying and maintaining socio-technical
systems.
y
z Concerned with the services provided by the
system,
y constraints on its construction and
operation and the ways in which it is used.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 5

 The system engineering process
z Usually follows a ‘waterfall’
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.
expensive Software may have to
compensate for hardware problems.
z Inevitably involves engineers from different disciplines
who must work together
• Much scope for misunderstanding here. Different disciplines
use a different vocabulary
y and much negotiation
g is required.
q
Engineers may have personal agendas to fulfil.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 6

 The systems engineering process

Requirements System
definition decommissioning

System System
design evolution

Sub-system System
development installation

System
integration

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 7

 Inter-disciplinary
Inter disciplinary involvement

Software Electronic Mechanical

engineering engineering engineering

Structural ATC systems User interface

engineering engineering design

Civil Electrical
Architecture
engineering engineering

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 8

 (1) System requirements definition
z Three types of requirement defined at this stage
• Abstract functional requirements. System functions
are defined in an abstract way;
y
• System properties. Non-functional requirements for
the system in general are defined;
• U d i bl characteristics.
Undesirable h t i ti U
Unacceptable
t bl system
t
behaviour is specified.
z Should also define overall organisational
objectives for the system.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 9

 System objectives
z Should define why a system is being procured
for a particular environment.
z Functional objectives
j
• To provide a fire and intruder alarm system for the
building which will provide internal and external
warning of fire or unauthorized intrusion
intrusion.
z Organisational 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.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 10

 (2) The system design process
z Partition requirements
• Organise requirements into related groups.
z Identify sub-systems
• Identify a set of sub-systems which collectively can meet the
system requirements.
z Assign requirements to sub-systems
sub systems
• Causes particular problems when COTS are integrated.
z Specify sub-system functionality.
z Define sub-system interfaces
• Critical activity for parallel sub-system development.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 11

 The system design process

Partition Define sub-system

requirements interfaces

Identify Specify sub-system

sub-systems functionality

Assign requirements
to sub-systems

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 12

 Spiral model of requirements/design

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 13

 (3) System modelling
z An architectural model presents an abstract view
of the sub-systems making up a system
z May include major information flows between
sub-systems
z Usually presented as a block diagram
z May identify different types of functional
component
p in the model

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 14

 Burglar alarm system

Movement Door
sensors sensors

Alarm
controller

External
control centre
Voice Telephone
Siren
synthesiser caller

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 15

 Sub-system
Sub system description

Sub-system Description
Movement sensors Detects movement in the rooms monitored by the system
Door sensors Detects door opening in the external doors of the building
Alarm controller Controls the operation of the system
Siren Emits an audible warning when an intruder is suspected
Voice synthesizer Synthesizes a voice message giving the location of the suspected intruder
Telephone caller Makes external calls to notify security, the police, etc.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 16

 (4) Sub-system
Sub system development
z Typically parallel projects developing the
hardware, software and communications.
z May involve some COTS (Commercial Off-the-Shelf)
systems procurement.
z Lack of communication across implementation
teams.
teams
z Bureaucratic and slow mechanism for
proposing system changes means that the development
schedule may be extended because of the need for
rework.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 17

 (5) System integration
z The process of putting hardware
hardware, software and
people together to make a system.
z Should be tackled incrementally so that sub-
sub
systems are integrated one at a time.
z Interface problems between sub-systems
sub systems are
usually found at this stage.
z Mayy be problems
p with uncoordinated deliveries
of system components.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 18

 (6) System evolution
z Large systems have a long lifetime
lifetime. They must evolve to
meet changing requirements.
z Evolution is inherently costly
• Changes must be analysed from a technical and business
perspective;
• Sub-systems
y interact so unanticipated
p p
problems can arise;
• There is rarely a rationale for original design decisions;
• System structure is corrupted as changes are made to it.
z Existing systems which must be maintained are
sometimes called legacy systems.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 19

 (7) System decommissioning
z Taking the system out of service after its useful
lifetime.
z May require removal of materials (e
(e.g.
g
dangerous chemicals) which pollute the
environment
• Should be planned for in the system design by
encapsulation.
z May require data to be restructured and
converted to be used in some other system.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 20

 Key points
z The systems
y engineering
g gpprocess includes specification,
p ,
design, development, integration and testing. System
integration is particularly critical.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 21