SlideShare a Scribd company logo
Success and failure
Ian Sommerville

Success and failure in sociotechnical systems, 2013

Slide 1
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

Success and failure in sociotechnical systems, 2013

Slide 2
• A socio-technical system will not always
produce the same sequence of outputs
from the same input sequence

Success and failure in sociotechnical systems, 2013

Slide 3
• Human operational behaviour
– People do not always behave in the same
way
– Their actions are determined by a range of
internal and external factors

Success and failure in sociotechnical systems, 2013

Slide 4
• System changes
– System behaviour is unpredictable because
of frequent changes to hardware, software
and data in seperately managed systems or
components

Success and failure in sociotechnical systems, 2013

Slide 5
Subjective behaviour
• Whether or not a system has is effective
in ‘doing its job’ depends on the
observer of a system

Success and failure in sociotechnical systems, 2013

Slide 6
• Complex socio-technical systems serve
different stakeholder groups, which may have
conflicting objectives
• Behaviour that is effective for one group, may
be ineffective for another

Success and failure in sociotechnical systems, 2013

Slide 7
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.

Success and failure in sociotechnical systems, 2013

Slide 8
• 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.

Success and failure in sociotechnical systems, 2013

Slide 9
Conflicting views of success
• A medical information system may be
designed to support multiple, conflicting
goals
– Improve quality of care.

– Provide better information and care costs
and so increase revenue.
Success and failure in sociotechnical systems, 2013

Slide 10
Success and failure in sociotechnical systems, 2013

Slide 11
•

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.

Success and failure in sociotechnical systems, 2013

Slide 12
What is failure?
•

A failure is ‘a deviation from a specification’.

•

An oracle can examine a specification, observe a
system’s behaviour and detect failures.

•

Failure is an absolute - the system has either
failed or it hasn’t

Success and failure in sociotechnical systems, 2013

Slide 13
Success and failure in sociotechnical systems, 2013

Slide 14
A hospital system
•

A hospital information system is designed to maintain
information about available beds for incoming
patients and to provide information about the number
of beds to the admissions unit.

•

It is assumed that the hospital has a number of empty
beds and this changes over time. The variable B
reflects the number of empty beds known to the
system.

Success and failure in sociotechnical systems, 2013

Slide 15
•

Sometimes the system reports that the number of
empty beds is the actual number available;
sometimes the system reports that fewer than the
actual number are available .

•

When the system reports that an incorrect number of
beds are available, is this a failure?

Success and failure in sociotechnical systems, 2013

Slide 16
• The percentage of system users who
considered the system’s incorrect
reporting of the number of available
beds to be a failure was 0%.

Success and failure in sociotechnical systems, 2013

Slide 17
Bed management system
•

Mostly, the number did not matter so long as it was
greater than 1. What mattered was whether or not
patients could be admitted to the hospital.

•

When the hospital was very busy (available beds =
0), then people understood that it was practically
impossible for the system to be accurate.

Success and failure in sociotechnical systems, 2013

Slide 18
Failure is a judgement
• Specifications are a gross simplification of
reality for complex systems.
• Users don’t read and don’t care about
specifications

Success and failure in sociotechnical systems, 2013

Slide 19
•

Whether or not system behaviour should be
considered to be a failure, depends on the observer’s
judgment

•

This judgment depends on:
–

The observer’s expectations

–

The observer’s knowledge and experience

–

The observer’s role

–

The observer’s context or situation

–

The observer’s authority

Success and failure in sociotechnical systems, 2013

Slide 20
Failures are inevitable
• Technical reasons
– When systems are composed of opaque and
uncontrolled components, the behaviour of these
components cannot be completely understood
– Failures often can be considered to be failures in data
rather than failures in behaviour

Success and failure in sociotechnical systems, 2013

Slide 21
Success and failure in sociotechnical systems, 2013

Slide 22
• Socio-technical reasons
– Changing contexts of use mean that the
judgement on what constitutes a failure changes
as the effectiveness of the system in supporting
work changes

– Different stakeholders will interpret the same
behaviour in different ways because of different
interpretations of ‘the problem’
Success and failure in sociotechnical systems, 2013

Slide 23
Conflict inevitability
• It is usually impossible to establish a set of
requirements where all stakeholder conflicts
are resolved
• Therefore, successful operation of a system
for one set of stakeholders will inevitably
mean ‘failure’ for another set of stakeholders

Success and failure in sociotechnical systems, 2013

Slide 24
Normal failures
•

‘Failures’

are not just catastrophic
events but normal, everyday system
behaviour that disrupts normal work and
that mean that people have to spend
more time on a task than necessary

Success and failure in sociotechnical systems, 2013

Slide 25
A system failure occurs when a direct or
indirect user of a system has to carry out
extra work, over and above that normally
required to carry out some task, in
response to some inappropriate or
unexpected system behaviour
Success and failure in sociotechnical systems, 2013

Slide 26
Summary
•

Success and failure are not absolute but depend on
the judgment of the observer

•

It is impossible to reconcile all conflicts in a complex
STS – therefore some stakeholders may consider
system behaviour as ‘failure’

•

Failures are normal and inevitable in system
operation

Success and failure in sociotechnical systems, 2013

Slide 27

More Related Content

What's hot

Aspect Oriented Software Development
Aspect Oriented Software DevelopmentAspect Oriented Software Development
Aspect Oriented Software Development
Jignesh Patel
 
Ch6-Software Engineering 9
Ch6-Software Engineering 9Ch6-Software Engineering 9
Ch6-Software Engineering 9
Ian Sommerville
 
Requirements Engineering Processes in Software Engineering SE6
Requirements Engineering Processes in Software Engineering SE6Requirements Engineering Processes in Software Engineering SE6
Requirements Engineering Processes in Software Engineering SE6
koolkampus
 
Legacy Systems in Software Engineering SE26
Legacy Systems in Software Engineering SE26Legacy Systems in Software Engineering SE26
Legacy Systems in Software Engineering SE26
koolkampus
 
Ch21-Software Engineering 9
Ch21-Software Engineering 9Ch21-Software Engineering 9
Ch21-Software Engineering 9
Ian Sommerville
 
Ch2-Software Engineering 9
Ch2-Software Engineering 9Ch2-Software Engineering 9
Ch2-Software Engineering 9
Ian Sommerville
 
Ch9-Software Engineering 9
Ch9-Software Engineering 9Ch9-Software Engineering 9
Ch9-Software Engineering 9
Ian Sommerville
 

What's hot (20)

Ariane 5 launcher failure
Ariane 5 launcher failure Ariane 5 launcher failure
Ariane 5 launcher failure
 
Use case Diagram
Use case DiagramUse case Diagram
Use case Diagram
 
software failures
 software failures software failures
software failures
 
Use case diagrams
Use case diagramsUse case diagrams
Use case diagrams
 
Aspect Oriented Software Development
Aspect Oriented Software DevelopmentAspect Oriented Software Development
Aspect Oriented Software Development
 
Ch6-Software Engineering 9
Ch6-Software Engineering 9Ch6-Software Engineering 9
Ch6-Software Engineering 9
 
Requirements Engineering Processes in Software Engineering SE6
Requirements Engineering Processes in Software Engineering SE6Requirements Engineering Processes in Software Engineering SE6
Requirements Engineering Processes in Software Engineering SE6
 
IT445_Week_3.pdf
IT445_Week_3.pdfIT445_Week_3.pdf
IT445_Week_3.pdf
 
Legacy Systems in Software Engineering SE26
Legacy Systems in Software Engineering SE26Legacy Systems in Software Engineering SE26
Legacy Systems in Software Engineering SE26
 
Capella Days 2021 | How I pack my suitcase
Capella Days 2021 | How I pack my suitcaseCapella Days 2021 | How I pack my suitcase
Capella Days 2021 | How I pack my suitcase
 
UML diagrams and symbols
UML diagrams and symbolsUML diagrams and symbols
UML diagrams and symbols
 
Software Failure Modes Effects Analysis Overview
Software Failure Modes Effects Analysis OverviewSoftware Failure Modes Effects Analysis Overview
Software Failure Modes Effects Analysis Overview
 
Insulin pump overview
Insulin pump overviewInsulin pump overview
Insulin pump overview
 
Sadcw 7e chapter01-done
Sadcw 7e chapter01-doneSadcw 7e chapter01-done
Sadcw 7e chapter01-done
 
Ch21-Software Engineering 9
Ch21-Software Engineering 9Ch21-Software Engineering 9
Ch21-Software Engineering 9
 
Unit 2(advanced class modeling & state diagram)
Unit  2(advanced class modeling & state diagram)Unit  2(advanced class modeling & state diagram)
Unit 2(advanced class modeling & state diagram)
 
Ch5 system modeling
Ch5 system modelingCh5 system modeling
Ch5 system modeling
 
Ch2-Software Engineering 9
Ch2-Software Engineering 9Ch2-Software Engineering 9
Ch2-Software Engineering 9
 
SOFTWARE ENGINEERING
SOFTWARE ENGINEERINGSOFTWARE ENGINEERING
SOFTWARE ENGINEERING
 
Ch9-Software Engineering 9
Ch9-Software Engineering 9Ch9-Software Engineering 9
Ch9-Software Engineering 9
 

Viewers also liked

Introducing sociotechnical systems
Introducing sociotechnical systemsIntroducing sociotechnical systems
Introducing sociotechnical systems
sommerville-videos
 
System of systems classification
System of systems classificationSystem of systems classification
System of systems classification
sommerville-videos
 

Viewers also liked (20)

Emergent properties
Emergent propertiesEmergent properties
Emergent properties
 
Introducing sociotechnical systems
Introducing sociotechnical systemsIntroducing sociotechnical systems
Introducing sociotechnical systems
 
Socio Technical Systems
Socio Technical SystemsSocio Technical Systems
Socio Technical Systems
 
Software engineering socio-technical systems
Software engineering   socio-technical systemsSoftware engineering   socio-technical systems
Software engineering socio-technical systems
 
Ian Sommerville, Software Engineering, 9th Edition Ch 4
Ian Sommerville,  Software Engineering, 9th Edition Ch 4Ian Sommerville,  Software Engineering, 9th Edition Ch 4
Ian Sommerville, Software Engineering, 9th Edition Ch 4
 
Industry 4.0 and the Internet of Things
Industry 4.0 and the Internet of Things Industry 4.0 and the Internet of Things
Industry 4.0 and the Internet of Things
 
Airbus Flight Control System
Airbus Flight Control SystemAirbus Flight Control System
Airbus Flight Control System
 
Critical systems engineering
Critical systems engineeringCritical systems engineering
Critical systems engineering
 
Agile and plan based development processes
Agile and plan based development processesAgile and plan based development processes
Agile and plan based development processes
 
User stories
User storiesUser stories
User stories
 
Agile methods for large systems
Agile methods for large systemsAgile methods for large systems
Agile methods for large systems
 
Scaling agile
Scaling agileScaling agile
Scaling agile
 
Introduction to systems of systems
Introduction to systems of systemsIntroduction to systems of systems
Introduction to systems of systems
 
Reuse landscape
Reuse landscapeReuse landscape
Reuse landscape
 
Architectural patterns for real-time systems
Architectural patterns for real-time systemsArchitectural patterns for real-time systems
Architectural patterns for real-time systems
 
Intro to requirements eng.
Intro to requirements eng.Intro to requirements eng.
Intro to requirements eng.
 
Stakeholders, viewpoints and concerns
Stakeholders, viewpoints and concernsStakeholders, viewpoints and concerns
Stakeholders, viewpoints and concerns
 
Why se script
Why se scriptWhy se script
Why se script
 
System of systems classification
System of systems classificationSystem of systems classification
System of systems classification
 
Fundamental software engineering activities
Fundamental software engineering activitiesFundamental software engineering activities
Fundamental software engineering activities
 

Similar to System success and failure

46393833 e banking
46393833 e banking46393833 e banking
46393833 e banking
dipali2009
 
Requirement engineering in S/W Engineering
Requirement engineering in S/W EngineeringRequirement engineering in S/W Engineering
Requirement engineering in S/W Engineering
Mikel Raj
 
CS 5032 L4 requirements engineering 2013
CS 5032 L4 requirements engineering 2013CS 5032 L4 requirements engineering 2013
CS 5032 L4 requirements engineering 2013
Ian Sommerville
 

Similar to System success and failure (20)

Designing Complex Systems for Recovery (LSCITS EngD 2011)
Designing Complex Systems for Recovery (LSCITS EngD 2011)Designing Complex Systems for Recovery (LSCITS EngD 2011)
Designing Complex Systems for Recovery (LSCITS EngD 2011)
 
Resilience and recovery
Resilience and recoveryResilience and recovery
Resilience and recovery
 
Dependability requirements for LSCITS
Dependability requirements for LSCITSDependability requirements for LSCITS
Dependability requirements for LSCITS
 
Requirements engineering challenges
Requirements engineering challengesRequirements engineering challenges
Requirements engineering challenges
 
System dependability
System dependabilitySystem dependability
System dependability
 
L7 Design For Recovery
L7 Design For RecoveryL7 Design For Recovery
L7 Design For Recovery
 
Requirements Engineering for LSCITS
Requirements Engineering for LSCITSRequirements Engineering for LSCITS
Requirements Engineering for LSCITS
 
Fact finding techniques
Fact finding techniquesFact finding techniques
Fact finding techniques
 
Requirements change - requirements engineering
Requirements change - requirements engineeringRequirements change - requirements engineering
Requirements change - requirements engineering
 
Software System Engineering - Chapter 8
Software System Engineering - Chapter 8Software System Engineering - Chapter 8
Software System Engineering - Chapter 8
 
Towards Dementia-friendly Smart Home
Towards Dementia-friendly Smart HomeTowards Dementia-friendly Smart Home
Towards Dementia-friendly Smart Home
 
46393833 e banking
46393833 e banking46393833 e banking
46393833 e banking
 
Requirement engineering in S/W Engineering
Requirement engineering in S/W EngineeringRequirement engineering in S/W Engineering
Requirement engineering in S/W Engineering
 
Requirementengg
RequirementenggRequirementengg
Requirementengg
 
How Impact Investors Think about Measuring Impact
How Impact Investors Think about Measuring ImpactHow Impact Investors Think about Measuring Impact
How Impact Investors Think about Measuring Impact
 
Usability requirements
Usability requirements Usability requirements
Usability requirements
 
Lecture10.ppt
Lecture10.pptLecture10.ppt
Lecture10.ppt
 
CS 5032 L4 requirements engineering 2013
CS 5032 L4 requirements engineering 2013CS 5032 L4 requirements engineering 2013
CS 5032 L4 requirements engineering 2013
 
Requirements engineering
Requirements engineeringRequirements engineering
Requirements engineering
 
Data Protection Governance IT
Data Protection Governance ITData Protection Governance IT
Data Protection Governance IT
 

More from sommerville-videos

More from sommerville-videos (10)

Introduction to real time software systems script
Introduction to real time software systems scriptIntroduction to real time software systems script
Introduction to real time software systems script
 
Introducing Software Engineering
Introducing Software EngineeringIntroducing Software Engineering
Introducing Software Engineering
 
Warsaw airbus accident
Warsaw airbus accidentWarsaw airbus accident
Warsaw airbus accident
 
Requirements engineering processes
Requirements engineering processesRequirements engineering processes
Requirements engineering processes
 
System security
System securitySystem security
System security
 
System safety
System safetySystem safety
System safety
 
Cybersecurity 4 security is sociotechnical issue
Cybersecurity 4 security is sociotechnical issueCybersecurity 4 security is sociotechnical issue
Cybersecurity 4 security is sociotechnical issue
 
Cybersecurity 3 cybersecurity costs and causes
Cybersecurity 3 cybersecurity costs and causesCybersecurity 3 cybersecurity costs and causes
Cybersecurity 3 cybersecurity costs and causes
 
Cybersecurity 2 cyber attacks
Cybersecurity 2 cyber attacksCybersecurity 2 cyber attacks
Cybersecurity 2 cyber attacks
 
Cybersecurity 1 intro to cybersecurity
Cybersecurity 1 intro to cybersecurityCybersecurity 1 intro to cybersecurity
Cybersecurity 1 intro to cybersecurity
 

Recently uploaded

Essentials of Automations: Optimizing FME Workflows with Parameters
Essentials of Automations: Optimizing FME Workflows with ParametersEssentials of Automations: Optimizing FME Workflows with Parameters
Essentials of Automations: Optimizing FME Workflows with Parameters
Safe Software
 
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo DiehlFuture Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Peter Udo Diehl
 

Recently uploaded (20)

In-Depth Performance Testing Guide for IT Professionals
In-Depth Performance Testing Guide for IT ProfessionalsIn-Depth Performance Testing Guide for IT Professionals
In-Depth Performance Testing Guide for IT Professionals
 
IESVE for Early Stage Design and Planning
IESVE for Early Stage Design and PlanningIESVE for Early Stage Design and Planning
IESVE for Early Stage Design and Planning
 
Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder
Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya HalderCustom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder
Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder
 
SOQL 201 for Admins & Developers: Slice & Dice Your Org’s Data With Aggregate...
SOQL 201 for Admins & Developers: Slice & Dice Your Org’s Data With Aggregate...SOQL 201 for Admins & Developers: Slice & Dice Your Org’s Data With Aggregate...
SOQL 201 for Admins & Developers: Slice & Dice Your Org’s Data With Aggregate...
 
Knowledge engineering: from people to machines and back
Knowledge engineering: from people to machines and backKnowledge engineering: from people to machines and back
Knowledge engineering: from people to machines and back
 
IOS-PENTESTING-BEGINNERS-PRACTICAL-GUIDE-.pptx
IOS-PENTESTING-BEGINNERS-PRACTICAL-GUIDE-.pptxIOS-PENTESTING-BEGINNERS-PRACTICAL-GUIDE-.pptx
IOS-PENTESTING-BEGINNERS-PRACTICAL-GUIDE-.pptx
 
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...
 
Essentials of Automations: Optimizing FME Workflows with Parameters
Essentials of Automations: Optimizing FME Workflows with ParametersEssentials of Automations: Optimizing FME Workflows with Parameters
Essentials of Automations: Optimizing FME Workflows with Parameters
 
"Impact of front-end architecture on development cost", Viktor Turskyi
"Impact of front-end architecture on development cost", Viktor Turskyi"Impact of front-end architecture on development cost", Viktor Turskyi
"Impact of front-end architecture on development cost", Viktor Turskyi
 
Mission to Decommission: Importance of Decommissioning Products to Increase E...
Mission to Decommission: Importance of Decommissioning Products to Increase E...Mission to Decommission: Importance of Decommissioning Products to Increase E...
Mission to Decommission: Importance of Decommissioning Products to Increase E...
 
JMeter webinar - integration with InfluxDB and Grafana
JMeter webinar - integration with InfluxDB and GrafanaJMeter webinar - integration with InfluxDB and Grafana
JMeter webinar - integration with InfluxDB and Grafana
 
UiPath Test Automation using UiPath Test Suite series, part 3
UiPath Test Automation using UiPath Test Suite series, part 3UiPath Test Automation using UiPath Test Suite series, part 3
UiPath Test Automation using UiPath Test Suite series, part 3
 
AI revolution and Salesforce, Jiří Karpíšek
AI revolution and Salesforce, Jiří KarpíšekAI revolution and Salesforce, Jiří Karpíšek
AI revolution and Salesforce, Jiří Karpíšek
 
Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head...
Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head...Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head...
Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head...
 
Designing Great Products: The Power of Design and Leadership by Chief Designe...
Designing Great Products: The Power of Design and Leadership by Chief Designe...Designing Great Products: The Power of Design and Leadership by Chief Designe...
Designing Great Products: The Power of Design and Leadership by Chief Designe...
 
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
 
ODC, Data Fabric and Architecture User Group
ODC, Data Fabric and Architecture User GroupODC, Data Fabric and Architecture User Group
ODC, Data Fabric and Architecture User Group
 
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo DiehlFuture Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
 
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
 
Speed Wins: From Kafka to APIs in Minutes
Speed Wins: From Kafka to APIs in MinutesSpeed Wins: From Kafka to APIs in Minutes
Speed Wins: From Kafka to APIs in Minutes
 

System success and failure

  • 1. Success and failure Ian Sommerville Success and failure in sociotechnical systems, 2013 Slide 1
  • 2. 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 Success and failure in sociotechnical systems, 2013 Slide 2
  • 3. • A socio-technical system will not always produce the same sequence of outputs from the same input sequence Success and failure in sociotechnical systems, 2013 Slide 3
  • 4. • Human operational behaviour – People do not always behave in the same way – Their actions are determined by a range of internal and external factors Success and failure in sociotechnical systems, 2013 Slide 4
  • 5. • System changes – System behaviour is unpredictable because of frequent changes to hardware, software and data in seperately managed systems or components Success and failure in sociotechnical systems, 2013 Slide 5
  • 6. Subjective behaviour • Whether or not a system has is effective in ‘doing its job’ depends on the observer of a system Success and failure in sociotechnical systems, 2013 Slide 6
  • 7. • Complex socio-technical systems serve different stakeholder groups, which may have conflicting objectives • Behaviour that is effective for one group, may be ineffective for another Success and failure in sociotechnical systems, 2013 Slide 7
  • 8. 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. Success and failure in sociotechnical systems, 2013 Slide 8
  • 9. • 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. Success and failure in sociotechnical systems, 2013 Slide 9
  • 10. Conflicting views of success • A medical information system may be designed to support multiple, conflicting goals – Improve quality of care. – Provide better information and care costs and so increase revenue. Success and failure in sociotechnical systems, 2013 Slide 10
  • 11. Success and failure in sociotechnical systems, 2013 Slide 11
  • 12. • 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. Success and failure in sociotechnical systems, 2013 Slide 12
  • 13. What is failure? • A failure is ‘a deviation from a specification’. • An oracle can examine a specification, observe a system’s behaviour and detect failures. • Failure is an absolute - the system has either failed or it hasn’t Success and failure in sociotechnical systems, 2013 Slide 13
  • 14. Success and failure in sociotechnical systems, 2013 Slide 14
  • 15. A hospital system • A hospital information system is designed to maintain information about available beds for incoming patients and to provide information about the number of beds to the admissions unit. • It is assumed that the hospital has a number of empty beds and this changes over time. The variable B reflects the number of empty beds known to the system. Success and failure in sociotechnical systems, 2013 Slide 15
  • 16. • Sometimes the system reports that the number of empty beds is the actual number available; sometimes the system reports that fewer than the actual number are available . • When the system reports that an incorrect number of beds are available, is this a failure? Success and failure in sociotechnical systems, 2013 Slide 16
  • 17. • The percentage of system users who considered the system’s incorrect reporting of the number of available beds to be a failure was 0%. Success and failure in sociotechnical systems, 2013 Slide 17
  • 18. Bed management system • Mostly, the number did not matter so long as it was greater than 1. What mattered was whether or not patients could be admitted to the hospital. • When the hospital was very busy (available beds = 0), then people understood that it was practically impossible for the system to be accurate. Success and failure in sociotechnical systems, 2013 Slide 18
  • 19. Failure is a judgement • Specifications are a gross simplification of reality for complex systems. • Users don’t read and don’t care about specifications Success and failure in sociotechnical systems, 2013 Slide 19
  • 20. • Whether or not system behaviour should be considered to be a failure, depends on the observer’s judgment • This judgment depends on: – The observer’s expectations – The observer’s knowledge and experience – The observer’s role – The observer’s context or situation – The observer’s authority Success and failure in sociotechnical systems, 2013 Slide 20
  • 21. Failures are inevitable • Technical reasons – When systems are composed of opaque and uncontrolled components, the behaviour of these components cannot be completely understood – Failures often can be considered to be failures in data rather than failures in behaviour Success and failure in sociotechnical systems, 2013 Slide 21
  • 22. Success and failure in sociotechnical systems, 2013 Slide 22
  • 23. • Socio-technical reasons – Changing contexts of use mean that the judgement on what constitutes a failure changes as the effectiveness of the system in supporting work changes – Different stakeholders will interpret the same behaviour in different ways because of different interpretations of ‘the problem’ Success and failure in sociotechnical systems, 2013 Slide 23
  • 24. Conflict inevitability • It is usually impossible to establish a set of requirements where all stakeholder conflicts are resolved • Therefore, successful operation of a system for one set of stakeholders will inevitably mean ‘failure’ for another set of stakeholders Success and failure in sociotechnical systems, 2013 Slide 24
  • 25. Normal failures • ‘Failures’ are not just catastrophic events but normal, everyday system behaviour that disrupts normal work and that mean that people have to spend more time on a task than necessary Success and failure in sociotechnical systems, 2013 Slide 25
  • 26. A system failure occurs when a direct or indirect user of a system has to carry out extra work, over and above that normally required to carry out some task, in response to some inappropriate or unexpected system behaviour Success and failure in sociotechnical systems, 2013 Slide 26
  • 27. Summary • Success and failure are not absolute but depend on the judgment of the observer • It is impossible to reconcile all conflicts in a complex STS – therefore some stakeholders may consider system behaviour as ‘failure’ • Failures are normal and inevitable in system operation Success and failure in sociotechnical systems, 2013 Slide 27