1 Institute 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 Institute for Software Research, International 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 Institute for Software Research, International London Ambulance Manual Dispatch  Call Taking v Control Assistant (CA) writes down the call details on a pre-printed form v Incident location is identified from a map book v Incident form is placed into a conveyor belt system v The conveyor belt then transports the forms to a central collection point  Resource Identification v Staff member collects the forms from the central collection point v Uses information on the form to decide which resource allocator should deal with it F three London Divisions - North East, North West, and South v Identifies potential duplicated calls v 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 v This resource is then also recorded on the form which is passed to a despatcher  Resource Mobilisation v 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 v This whole process should take no more than 3 minutes.

5 Institute for Software Research, International 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 Institute for Software Research, International 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. v This does not diminish the role of management, political, procurement, scaling, training, and deployment problems.  We are only provided with Report of the Inquiry. v v 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 Institute for Software Research, International Critical Requirements  Ambulance dispatch functionality v Calls report incidents and other needs for transport v An ambulance arrives at the location of an incident promptly; the ambulance may take patient(s) to hospital  Other requirements v Timely response without communication overload v Resilience to faulty communication v Resilience to independent field decisions by personnel v Incremental information about incident v Efficient use of resources, efficient response  System considerations v Incremental deployment v Fit with existing system processes

8 Institute for Software Research, International First cut at context and problem Resources Calls Ambulance Dispatch Machine Ambulance arrives at incident promptly, may take patient to hospital Commanded behavior a a: 911 call b: dispatch message c: requests b c b

9 Institute for Software Research, International Problem Domains  Calls: telephone calls from the public and doctors  Resources: ambulances, personnel, special equipment  But … v Calls do not correspond directly to incidents v 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 Institute for Software Research, International Ambulance Context ResourcesIncidents Calls Real World Geography Ambulance Dispatch Machine a a: 911 calld: {create,update,close} incident b: dispatch messagee: geographic facts c: requests d b e

11 Institute for Software Research, International Ambulance Problem ResourcesIncidents Calls Real World Geography Ambulance Dispatch Machine a d b e b c Ambulance arrives at incident promptly, may take patient to hospital a: 911 calld: {create,update,close} incident b: dispatch messagee: geographic facts c: requests

12 Institute for Software Research, International Call Taking Resources Calls Real World Geography Incidents reflect info in calls Prioritizes calls Establishes location of incident Combines multiple calls about each incident Call Taking Incidents a: 911 calld: {create,update,close} incident a d Workpiece

13 Institute for Software Research, International Geographic facts ResourcesIncidents Calls Geography Model Real World Geography Geog is OK Geography Machine Model domain (ch 7)

14 Institute for Software Research, International Call Taking Resources Calls Incidents reflect info in calls and geography Call Taking Incidents a: 911 calld: {create,update,close} incident a d Geography Model Real World Geography Geog is OK Geography Machine a: 911 calld: {create,update,close} incident b: dispatch messagee: geographic facts c: requests e

15 Institute for Software Research, International Ambulance Dispatch Ambulance arrives at incident promptly, may take patient to hospital Dispatch ResourcesIncidents Calls Real World Geography Actually dispatches ambulances based on incidents and status of resources db Commanded behavior

16 Institute for Software Research, International Ambulance Dispatch Ambulance arrives at incident promptly, may take patient to hospital Dispatch ResourcesIncidents Calls db Geography Model Real World Geography Geog is OK Geography Machine e

17 Institute for Software Research, International Combined Ambulance Dispatch Ambulance arrives at incident promptly, may take patient to hospital Dispatch ResourcesIncidents db Geography Model Real World Geography Geog is OK Geography Machine e Calls Incidents reflect info in calls Call Taking Incidents a d e Note: Incidents is lexical in CallTaking, biddable in Dispatch

18 Institute for Software Research, International 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 Reality

19 Institute for Software Research, International Revisit Call Taking Calls Incidents reflect 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 Institute for Software Research, International Processing Incoming Calls 1A sequence of calls 2A sequence of 999, Doctor’s urgent, and transport calls 3A sequence of typed calls, identifiable by location F location from call box location or query by operator 4A sequence of typed calls, with ringing and waiting handled F criteria for delay, policy for ordering (?) 5A buffered, sorted sequence of with other location information 6A buffered, sorted sequence of with other information that identifies the incident Operator Calls What’s going on here?

21 Institute for Software Research, International Revisit Call Taking Calls Incidents reflect info in calls Call Taking Incidents Reformater Operator Reformatted Calls Workpieces Transformation

22 Institute for Software Research, International Revisit Dispatch Ambulance arrives at incident promptly, may take patient to hospital Dispatch Resources db 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 Institute for Software Research, International Heuristics used in finding subproblems  Identify core problem, find ancillary problems v Start from dispatch, recognize need for calls, geography  Standard decomposition v 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 v Treating resources as reactive-causal caused major trouble  Modeling the user (who’s actually the user here?) v Failure to model ambulance crews caused major trouble

24 Institute for Software Research, International Things to think about on your own: How would you decompose Dispatch? Ambulance arrives at incident promptly, may take patient to hospital Dispatch Resources Incidents X B

25 Institute for Software Research, International 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 Institute for Software Research, International Are there any questions?