1. Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture #12 Problem Frames III

2. Fall 2005 2 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Picture of the Day: Schenley Park in Winter

3. Fall 2005 3 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Today ’ s Plan Frames in the generality/power space Frames in the generality/power space Finding subproblems Finding subproblems Addressing them as individual problems Addressing them as individual problems Dealing with their frame concerns Dealing with their frame concerns Assembling subsolutions into solutions Assembling subsolutions into solutions Composite frames Composite frames Example: London Ambulance Problem Example: London Ambulance Problem An example that ’ s not in the book An example that ’ s not in the book More examples: the Studio projects More examples: the Studio projects Find structure for your problems Find structure for your problems Identify specific implementation or design issues Identify specific implementation or design issues Identify the V&V issues (frame concerns) Identify the V&V issues (frame concerns) The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

4. Fall 2005 4 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Attaching Things Generality Specialization The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

5. Fall 2005 5 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Power Tradeoffs “ A good software-development method prescribes a very specific problem frame and fully exploits its properties ” -- Jackson -- Jackson PowerPower Generality Product Lines CMM, XP, open source (as claimed) Problem Frames The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

6. Fall 2005 6 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University A Case Study: London Ambulance System

7. Fall 2005 7 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University 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. … The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

8. Fall 2005 8 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University London Ambulance Manual Dispatch Call Taking Call Taking Control Assistant (CA) writes down the call details on a pre-printed form Control Assistant (CA) writes down the call details on a pre-printed form Incident location is identified from a map book Incident location is identified from a map book Incident form is placed into a conveyor belt system Incident form is placed into a conveyor belt system The conveyor belt then transports the forms to a central collection point The conveyor belt then transports the forms to a central collection point Resource Identification Resource Identification Staff member collects the forms from the central collection point Staff member collects the forms from the central collection point Uses information on the form to decide which resource allocator should deal with it Uses information on the form to decide which resource allocator should deal with it three London Divisions - North East, North West, and South three London Divisions - North East, North West, and South Identifies potential duplicated calls 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 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 This resource is then also recorded on the form which is passed to a despatcher Resource Mobilisation 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 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. This whole process should take no more than 3 minutes. R e v i e w The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

9. Fall 2005 9 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Resource Allocator -Decides which resource to mobilize Form Router -Collect forms from all CAs -Route form to correct resource allocator -Identify duplicates Radio Operator -Update records of resource utilization -Contact ambulance drivers Control Assistant -Record call details -Locate incident on map -Place incident form on conveyor Caller -Give location of emergency -Describe emergency Dispatcher -Contacts resource Ambulance Station -Send ambulance Ambulance request Printed form Status and location information Form noting resource Instructions Ambulance -Respond Instructions Callback status request Status request Status info London Ambulance Manual System Flow Model R e v i e w The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

10. Fall 2005 10 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University London Ambulance System Problems with Manual Dispatch 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. 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. 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. 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. The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 1/2 R e v i e w

11. Fall 2005 11 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University London Ambulance System Problems with Manual Dispatch Communicating with ambulances via voice is time consuming and, at peak times, can lead to mobilization queues. 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. 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. 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. Identification of special incidents needing a Rapid Response Unit or the helicopter (or a major incident team) relies totally on human judgment. The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 2/2 R e v i e w

12. Fall 2005 12 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University London Ambulance Manual System Flow Model R e v i e w Resource Allocator -Decides which resource to mobilize Form Router -Collect forms from all CAs -Route form to correct resource allocator -Identify duplicates Radio Operator -Update records of resource utilization -Contact ambulance drivers Control Assistant -Record call details -Locate incident on map -Place incident form on conveyor Caller -Give location of emergency -Describe emergency Dispatcher -Contacts resource Ambulance Station -Send ambulance Ambulance request Printed form Status and location information Form noting resource Instructions Ambulance -Respond Instructions Callback status request Status request Status info The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

13. Fall 2005 13 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University London Ambulance Automation Issues The London Ambulance Service decided to install a Computer-Aided Dispatch system. 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. 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. This does not diminish the role of management, political, procurement, scaling, training, and deployment problems. We are only provided with Report of the Inquiry. We are only provided with Report of the Inquiry. http://www.cs.ucl.ac.uk/staff/a.finkelstein/las.html http://www.cs.ucl.ac.uk/staff/a.finkelstein/las.html http://www.cs.ucl.ac.uk/staff/a.finkelstein/las.html From this we can infer a requirement. From this we can infer a requirement. This study used in the software architecture research community as an example for trying out new ideas. This study used in the software architecture research community as an example for trying out new ideas. The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

14. Fall 2005 14 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Critical Requirements Ambulance dispatch functionality Ambulance dispatch functionality Calls report incidents and other needs for transport 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 An ambulance arrives at the location of an incident promptly; the ambulance may take patient(s) to hospital Other requirements Other requirements Timely response without communication overload Timely response without communication overload Resilience to faulty communication Resilience to faulty communication Resilience to independent field decisions by personnel Resilience to independent field decisions by personnel Incremental information about incident Incremental information about incident Efficient use of resources, efficient response Efficient use of resources, efficient response System considerations System considerations Incremental deployment Incremental deployment Fit with existing system processes Fit with existing system processes The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

15. Fall 2005 15 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University 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: 999 call b: dispatch message c: requests b c b The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

16. Fall 2005 16 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Problem Domains Calls: telephone calls from the public and doctors Calls: telephone calls from the public and doctors Resources: ambulances, personnel, special equipment Resources: ambulances, personnel, special equipment But … But … Calls do not correspond directly to incidents Calls do not correspond directly to incidents Detailed knowledge of geography is required to interpret calls and to know which ambulance to send Detailed knowledge of geography is required to interpret calls and to know which ambulance to send So add domains … So add domains … Incidents: discrete events that require ambulance response Incidents: discrete events that require ambulance response Geography: Streets, addresses, hospital locations, etc Geography: Streets, addresses, hospital locations, etc The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

17. Fall 2005 17 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Ambulance Context ResourcesIncidents Calls Real World Geography Ambulance Dispatch Machine a a: 999 calld: {create,update,close} incident b: dispatch messagee: geographic facts c: requests d b e The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

18. Fall 2005 18 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Ambulance Context 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: 999 calld: {create,update,close} incident b: dispatch messagee: geographic facts c: requests The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

19. Fall 2005 19 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University 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: 999 calld: {create,update,close} incident a d Workpiece The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

20. Fall 2005 20 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Geographic Facts ResourcesIncidents Calls Geography Model Real World Geography Geog is OK Geography Machine Model domain (ch 7) The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

21. Fall 2005 21 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University 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: 999 calld: {create,update,close} incident b: dispatch messagee: geographic facts c: requests e The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

22. Fall 2005 22 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University 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 The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

23. Fall 2005 23 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University 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 The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

24. Fall 2005 24 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University 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 The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

25. Fall 2005 25 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Size Color Composition by Sharing Domains A domain is a view, or projection, of physical reality that emphasizes properties of interest A domain is a view, or projection, of physical reality that emphasizes properties of interest Different subproblems deal with different properties Different subproblems deal with different properties Composition requires consistent views Composition requires consistent views Lexical Biddable Reality The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

26. Fall 2005 26 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University 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 The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

27. Fall 2005 27 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Processing Incoming Calls 1.A sequence of calls 2.A sequence of 999, Doctor ’ s urgent, and transport calls 3.A sequence of typed calls, identifiable by location location from call box location or query by operator 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 (?) criteria for delay, policy for ordering (?) 5.A buffered, sorted sequence of with other location information 6.A buffered, sorted sequence of with other information that identifies the incident Ambulance Dispatch Software Ambulance Dispatch Software Calls What’s going on here? The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

28. Fall 2005 28 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Revisit Dispatch Ambulance arrives at incident promptly, may take patient to hospital Dispatch ResourcesIncidents 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. The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

29. Fall 2005 29 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Heuristics Used in Finding Subproblems Identify core problem, find ancillary problems Identify core problem, find ancillary problems Start from dispatch, recognize need for calls, geography Start from dispatch, recognize need for calls, geography Different tempi Different tempi Calls and incidents have different tempi Calls and incidents have different tempi Standard decomposition Standard decomposition Geography is clearly a model, so we found model-using and model-building subproblems. (Ch. 7) Geography is clearly a model, so we found model-using and model-building subproblems. (Ch. 7) Concerns and difficulties Concerns and difficulties Treating resources as reactive-causal caused major trouble Treating resources as reactive-causal caused major trouble Modeling the user (who ’ s actually the user here?) Modeling the user (who ’ s actually the user here?) Failure to model ambulance crews caused major trouble Failure to model ambulance crews caused major trouble The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

30. Fall 2005 30 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Grayson Wheatley Model of Problem Solving Read the problem Read the problem Now read the problem again Now read the problem again Write down what you hope is the relevant information Write down what you hope is the relevant information Draw a picture, make a list, or write an equation or formula to help you begin to understand the problem Draw a picture, make a list, or write an equation or formula to help you begin to understand the problem Try something Try something Try something else Try something else See where this gets you See where this gets you Read the problem again Read the problem again Try something else Try something else See where this gets you See where this gets you Test intermediate results to see whether you are making any progress toward an answer Test intermediate results to see whether you are making any progress toward an answer Read the problem again Read the problem again When appropriate, strike your forehead and say, “ son of a... ” When appropriate, strike your forehead and say, “ son of a... ” Write down ‘ an ’ answer (not necessarily ‘ the ’ answer) Write down ‘ an ’ answer (not necessarily ‘ the ’ answer) Test the answer to see if it makes sense Test the answer to see if it makes sense Start over if you have to, celebrate if you don ’ t Start over if you have to, celebrate if you don ’ t The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

31. Fall 2005 31 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Questions??