1 institute for software research, international methods of software development problem frames 3...

1Institute for Software Research, International

Methods of Software Development

Problem Frames 3

(This lecture is largely based on material graciously provided by Professor Mary Shaw)

2

Institute for Software Research, International

Are there any questions?

3


News article, 20 Oct 1992

AMBULANCE CHIEF QUITS AFTER PATIENTS DIE IN COMPUTER CRASH

By Ian MacKinnon and Stephen Goodwin The Chief executive of the London Ambulance Service resigned yesterday over allegations that up to 20 people may have died because of the collapse of a new computer system controlling emergency calls. Virginia Bottomley, Secretary of Sate for Health, was forced to announce an external inquiry into the 36 hours over Monday and Tuesday which led to delays of up to three hours in ambulances arriving. …

4


London Ambulance Manual Dispatch

Call Taking Control Assistant (CA) writes down the call details on a pre-printed form Incident location is identified from a map book Incident form is placed into a conveyor belt system The conveyor belt then transports the forms to a central collection point

Resource Identification Staff member collects the forms from the central collection point Uses information on the form to decide which resource allocator should

deal with it three London Divisions - North East, North West, and South

Identifies potential duplicated calls Resource allocator then uses status and location information provided

through the radio operator and noted on forms maintained in the "activation box" for each vehicle, decides which resource should be mobilised

This resource is then also recorded on the form which is passed to a despatcher

Resource Mobilisation The despatcher will telephone the relevant ambulance station (if that is

where the resource is) or will pass mobilisation instructions to the radio operator if the ambulance is already in the field

This whole process should take no more than 3 minutes.

5


London Ambulance Manual System Problems

identification of the precise location can be time consuming due to often incomplete or inaccurate details from the caller and the consequent need to explore a number of alternatives through the map books;

the physical movement of paper forms around the Control Room is inefficient;

maintaining up to date vehicle status and location information from allocators' intuition and reports from ambulances as relayed to and through the radio operators is a slow and laborious process;

communicating with ambulances via voice is time consuming and, at peak times, can lead to mobilization queues;

identifying duplicated calls relies on human judgment and memory. This is error prone;

dealing with call backs is a labor intensive process as it often involves CA's leaving their posts to talk to the allocators;

identification of special incidents needing a Rapid Response Unit or the helicopter (or a major incident team) relies totally on human judgment.

6


London Ambulance Automation Issues

The London Ambulance Service decided to install a Computer-Aided Dispatch system.

There were numerous problems. We focus here on the design of the system architecture. This does not diminish the role of management,

political, procurement, scaling, training, and deployment problems.

We are only provided with Report of the Inquiry. http://www.cs.ucl.ac.uk/staff/a.finkelstein/las.html From this we can infer a requirement.

This study used in the software architecture research community as an example for trying out new ideas.

7


Critical Requirements

Ambulance dispatch functionality Calls report incidents and other needs for transport An ambulance arrives at the location of an incident

promptly; the ambulance may take patient(s) to hospital

Other requirements Timely response without communication overload Resilience to faulty communication Resilience to independent field decisions by personnel Incremental information about incident Efficient use of resources, efficient response

System considerations Incremental deployment Fit with existing system processes

8


First cut at context and problem

Resources

Calls

AmbulanceDispatchMachine

Ambulance arrives atincident promptly, maytake patient to hospital

Commanded behavior

a

a: 911 call

b: dispatch message

c: requests

b

c

b

9


Problem Domains

Calls: telephone calls from the public and doctors

Resources: ambulances, personnel, special equipment

But … Calls do not correspond directly to incidents Detailed knowledge of geography is required to

interpret calls and to know which ambulance to send So add domains … Incidents: discrete events that require

ambulance response Geography: Streets, addresses, hospital

locations, etc

10


Ambulance Context

ResourcesIncidents

Calls Real WorldGeography


a

a: 911 call d: {create,update,close} incidentb: dispatch message e: geographic factsc: requests

d b

e

11


Ambulance Problem

ResourcesIncidents

Calls Real WorldGeography


a

d b

e

bc



12


Call Taking

Resources

CallsReal WorldGeography

Incid

en

ts r

efl

ect

info

in

calls

Prioritizes callsEstablishes location of incidentCombines multiple calls

about each incident

Call Taking

Incidents

a: 911 call d: {create,update,close} incident

a

d

Workpiece

13


Geographic facts

ResourcesIncidents

Calls

GeographyModel

Real WorldGeography

Geog is OK

GeographyMachine

Model domain (ch 7)

14


Call Taking

Resources

Calls

Incid

en

ts r

efl

ect

info

in

calls

an

d g

eog

rap

hy

Call Taking

Incidents

a: 911 call d: {create,update,close} incident

a

d

GeographyModel

Real WorldGeography

Geog is OK

GeographyMachine


e

15


Ambulance Dispatch


Dispatch ResourcesIncidents

CallsReal WorldGeography

Actually dispatches ambulances basedon incidents and status of resources

d b

Commanded behavior

16


Ambulance Dispatch


Dispatch ResourcesIncidents

Calls

d b

GeographyModel

Real WorldGeography

Geog is OK

GeographyMachine

e

17


Combined Ambulance Dispatch


Dispatch ResourcesIncidentsd b

GeographyModel

Real WorldGeography

Geog is OK

GeographyMachine

e

Calls

Incid

en

ts r

efl

ect

info

in

calls

Call Taking

Incidents

a

d

e

Note: Incidents islexical in CallTaking, biddable in Dispatch

18


Size Color

Composition by Sharing Domains

A domain is a view, or projection, of physical reality that emphasizes properties of interest

Different subproblems deal with different properties Composition requires consistent views

Lexical Biddable

RealityReality

19


Revisit Call Taking

Calls

Incid

en

ts r

efl

ect

info

in

calls

Call Taking

Incidents

a

d

Workpiece assumes Calls are biddable and Incidents lexical

That would work if call taking were completely automatic.

It isn’t. Human operators have to map calls to incidents. So split into two subproblems – one with operators editing the Incident workpieces, another transforming calls mechanically to a form the operator can handle (prioritizing based on origin, adding inferable geography, etc)

20


Processing Incoming Calls

1 A sequence of calls2 A sequence of 999, Doctor’s urgent, and transport calls3 A sequence of typed calls, identifiable by location

location from call box location or query by operator

4 A sequence of typed calls, with ringing and waiting handled criteria for delay, policy for ordering (?)

5 A buffered, sorted sequence of <call, type, caller-id> with other location information

6 A buffered, sorted sequence of <call, type, caller-id> with other information that identifies the incident

OperatorOperator

CallsCalls

What’s going on here?

21


Revisit Call Taking

Calls

Incid

en

ts r

efl

ect

info

in

calls

Call Taking

Incidents

Reformater

Operator

ReformattedCalls

Workpieces

Transformation

22


Revisit Dispatch


Dispatch Resourcesd b

Commanded behavior assumes Incidents are biddable and Resources are causal. This assumption is one of the major causes of the original failure

In fact, Resources turned out to be a model of the real resources, and the model was not accurate. Causes were radio and location failure, equipment malfunction, poor tracking of equipment, but most severely, initiative on the part of the ambulance crews (they were biddable-active, not reactive-causal).

Incidents

23


Heuristics used in finding subproblems

Identify core problem, find ancillary problems Start from dispatch, recognize need for calls,

geography Standard decomposition

Geography is clearly a model, so we found model-using and model-building subproblems. Refer to the previous lecture (and Chapter 7) for details on model variants.

Concerns and difficulties Treating resources as reactive-causal caused major

trouble Modeling the user (who’s actually the user here?)

Failure to model ambulance crews caused major trouble

24


Things to think about on your own:How would you decompose Dispatch?


Dispatch ResourcesIncidentsX B

25


Things to think about on your own:Making Problem Frames work in

practice.

Based on what you’ve learned about Problem Frames,

Name one thing that you plan to do in software development after you graduate.

(Or put another way, name one thing that you have learned from Problem Frames that will help you in your career.)

26


Are there any questions?

1 institute for software research, international methods of software development problem frames 3...

Documents

software research

south v

london ambulance service

ambulance chief

conveyor belt system

map book v incident

v control assistant

location information