Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


London Ambulance System Software Failure

First presentation of the Critical Software class

Gus Gusman

on 20 December 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of London Ambulance System Software Failure

London Ambulance System Software Failure Background Manual Dispatch System
and the
Need for CAD The System goes Live Monday October 26th, 1992 Monday October 26th, 1992 The system lost some calls, leading to duplicate calls and up to 30-minute queues
The system failed to recognize some roads, so ambulance drivers had to revert to using maps
Unattended calls generated exception messages
High number of exceptions swamped dispatchers
The exception queue was cleared, but this increased lost calls
This caused the 'vicious cycle' to start again Founded in 1930
2000 and 2500 calls per day
750 vehicles under its disposal
600 square miles London Ambulance Service (LAS) LAS Manual Operation When operation stared, the system had 81 known bugs
Operation began 10 months after the first training session
The 4 primary flaws present in the system at this point:
System failed when incomplete data was supplied
System did not accept normal day-to-day errors
Interface contained 'black spots' which obstructed the user's view
System stored useless information, quickly filling up memory and locking up Manual System Shortcomings Finding incident co-ordinates from a map book was time consuming and error prone, particularly given the often distressed calls.
The movement of paper around the control centre was inefficient.
The requirements for maintaining location and status information for ambulances by the resource allocator was labour intensive and time consuming.
Sometimes more than one person would call an ambulance to the same incident. Identification of such duplicated calls relied on human judgement and memory and was error prone.
Conformity with prevailing performance standards required that this manual process was to be completed within three minutes, but that is not mostly the case Computer Aided Despatch
Components and Functions Tuesday October 27th, 1992 Components at Command Center CAD hardware and software
Mapping software
A communications interface
A radio system Components at the Ambulance Mobile data terminals
Automatic vehicle location system System had to be shut down. Dispatchers reverted to a manual and computerized combination procedure
This provided a slight improvement in call waiting time
Mixed-procedure carried on for seven days, until the system fully locked up
Rebooting failed
Backup system failed
Dispatchers reverted back to the fully manual paper-based system Main Functions Taking calls about incidents
Automatic resource allocation
Communication of incident details to the chosen ambulance
Management and location of suitably equipped and staffed vehicles in order to minimize response times
Production of MIS reports to support longer term resource planning The Effects (1/2) Human Claims made that up to 20 or 30 people may have died from late ambulance arrivals Organizations in the Context Wide exploration of the case to determine what had failed
LAS CAD case became typical example in Software Engineering university courses of "what went wrong"
UK IT professionals took steps to prevent similar experiences First Attempt The Effects (2/2) Political BCS president claimed: "The public are entitled to expect that the same professional disciplines apply in IT as in other professions such as medicine and law" Economical LAS CAD estimated cost of between £1 and £1.5 million
Not significant when compared to other large-scaled software failure
UK Taurus stock exchange program: £75-£30 million
US CONFIRM system: US$ 125 million The first attempt to automate LAS' dispatch system was made at cost of £7.5 million Second Attempt Began shortly after the first attempt was abandoned Autumn 1990 to February 1991 – Writing of System Requirements Specification (SRS)
7 February 1991 – Invitation to tender published in the Journal of European Communities
May 1991 – Contract to supply the CAD software signed with System Options Ltd.
June and July 1991 – System design specification
September 1991 - Contract to supply mobile data equipment with Solo Electronic Systems Ltd.
8 January 1992 – planned date of original implementation What Went WRONG Conclusions Management Problems Preconditions of the CAD contract Negotiation between stakeholders required a better definition of:
Time and financial requirements
SRS definition (include minor staff) System Specifications and Design Unhealthy working relationship and lack of trust between the staff and management of LAS
Reduction of about 20% in the number of managers increasing stress in the remaining managers
LAS board members were appointed without knowing their responsibilities making bad decisions Testing procedures never contemplated the system as a whole, no one (LAS or contractor) knew how problems would appear LAS top management set a nonnegotiable date of 8 January 1992 for full implementation (only 6 months to finish all)
Cost restriction, spend a maximum of £1.5 million. (only 1/5 of the FAILED first attempt money spent)
The lower bidders where contracted Training was not properly planned and scheduled. The system changed constantly, making previous training obsolete. LAS CAD project would have benefited from external Quality Assurance. Lack of experience of the contractors is important to consider in large, critical systems. Project committee left out relevant key roles to analyze the system requirements
LAS top management failed to follow the guidelines of the UK Government project management methodology; the PRINCE (Project in Controlled Environment)
The CAD system relied in accurate information and imperfect information/communication was not take into account by the project team
There was no independent software quality assurance team Staff Training Training was not enough (the staff complained about inadequate training)
They only receive 2 days of training
There where several changes to the system design and long delay before its live operation LAS CAD is a system with strong coupling and linear interaction. Testing Only functional testing was carried out
There was no testing to see if the system can operate together as a whole
No testing about the system reaction to the different circumstances such as high call rate
Avoidable errors that testing could discover where introduced in the final product Implementation LAS CAD system failure was the result of cumulative consequences of these individual problems. The problems experienced during the implementation/live operation are summarized below: The importance of the LAS CAD failure lies in the knowledge obtained from its experience. Incomplete software.
Inability of the CAD software to identify and allocate the nearest available resource.
The AVLS not being able to identify all the ambulances in the fleet.
Communication problems among the CAD system, AVLS and Mobile data system.
Slow operation of the system.
Locking up of workstations.
Inaccurate status reporting by ambulance crew when wrong buttons were pressed
Use of different vehicle by the crew from the one assigned by the system. Alejandro Bustamante
Carlos Cardozo
Jonathan Araujo
Full transcript