Reference no: EM132651626
London Ambulance Service System Failure
In the 1980s the London Ambulance Service (LAS) used a manual system for ambulance mobilization and dispatch services. Central Ambulance Control (CAC) would receive a London emergency 999 call, and the control assistant (CA) receiving the call would write down the call details on a pre-printed form. The incident would be located in a map book with reference coordinates, and the set of information would be sent off on a conveyor belt to a central collection point. A CAC staff member would collect the paperwork and identify which of several resource allocators should be called (North East, North, West, or South divisions of London). Using status and location information for ambulances provided by a radio operator, the resource allocator decides which resource should be mobilized. The resource is then recorded on the form and passed on to a dispatcher who contacts the ambulance directly. The whole process should take less than 3 minutes.
The new plan was to implement a state of the art London Ambulance Service Computer Aided Dispatch (LASCAD) system. The software requirements specification (SRS) was ambitious. It called for a totally automated system where the majority of incoming calls would result in "an automatic allocation proposal of the most suitable ambulance resource". In complex cases, a human resource allocator would be called upon to identify and allocate the best resources, but for the most part the original CAC staff member receiving the call would see the incident through to completion. In late 1990, work was begun on the SRS transitioning to design in summer of 1991. The LAS management mandated that the entire system, in a single phase-over process, be up and running by January 8, 1992. While concerns were raised about the non-negotiable time frame, a consortium of Apricot, Systems Option, and Datatrak won the contract for £1.1 million. It is interesting to note that the competing contractors were asking around £8 million. Questions were later raised as to why the bid was significantly cheaper than those of the competitors.
After an unplanned phased implementation process over the course of the first nine months of 1992 inwhich the untested system proved itself to be unstable in each phase, the decision was made to migrate directly to the fully implemented, fully automatic system on October 26, 1992. Pandemonium ensued.
The system was lightly loaded on start up, but as the day progressed and the number of calls increased, a build-up of emergencies in the system increased. The system bottlenecked in several areas of operation and entered a vicious spiral of cause and effect where the bottlenecks caused more bottlenecks. On October 28, at 11 pm, after two consecutive days of system failure and personnel frustration, the LAS instigated an unplanned manual backup procedure. When the dust settled and the disaster was contained, over twenty would-be patients had lost their lives.
(Adapted from Kornecki, A.J. & Lewis, J. (2003). Software tragedies: Case studies in software safety. Proceedings of the 21st International System Safety Conference, pp. 896-905).
Required:
a) Identify and explain TWO (2) information system problem areas that were mentioned in the above case scenario.
b) What type of software acquisition method was adopted in the above case scenario to develop London Ambulance Service Computer Aided Dispatch (LASCAD) system? Justify your answer.