F1 Emergency Response System
From SoftwarePractice.org
F1 HELP System
Human-Emergency Liason Platform
| Name | Student ID | |
|---|---|---|
| Peter Brown | 10434379 | peter_brown15@hotmail.com |
| Andrew Chan | 10594657 | andrew_kk_c@yahoo.com.au |
| Khai Lim Chow | 10446969 | khailim@hotmail.com |
| David Isaacs | 10171066 | hornetfighter@hotmail.com |
| Van Le | 10448557 | vans14le@hotmail.com |
| Hung Tran | 10319628 | hung.d.tran@student.uts.edu.au |
Milestone 1
- Presentation: Media: F1-presentation-M1-31278-48433-S08.zip
- Wiki Document: Wiki As At 11 September 2008
Milestone 2
- Presentation: Media: F1 Milestone 2 Presentation.zip
- Wiki Document: This page is milestone 2
- Individual Reflection: Click Here
System Scope
Scope
The Emergency Response System (ERS) is responsible for maintaining the geographical database, using the database the system will be able to track, add, remove, and suspend the vehicles. The system, with the help of the “miracle” system will be able to determine which unit to dispatch and identify the most efficient route to the scene. Emergency vehicles can be of different types such as ambulance, fire, police, police rescue, coastal and harbour patrol, traffic patrol, accident response units, State Emergency Services, and bushfire services. The System includes the ERS Server, Persistent Storage to hold data, the Dispatch Operator Console, the Emergency Vehicle Console, and Web Report Generation facilities for vehicle movements and dispatch activities.
The Emergency Response System will utilize a variety of third party services and technologies that are not included within the scope of the system. These services and technologies include:
- The “miracle” system that is able to deduce and provide a route between two end points.
- New geographic data from changes in the roads.
- Emergency Call Services numbers in Australia (000, 112, 106)
- Mobile phone standards (3G, GSM)
- Voice over Internet Protocol (VoIP) and Cordless Phones
- The Integrated Public Number Database (IPND) repository/database of all listed and unlisted public telephone numbers.
- Global Positioning System (GPS)
- Government Radio Network or the Ambulance Private Mobile Radio systems
The ERS will meet Privacy And Confidentiality legislation.
System Overview
Current System
When you pick up the phone to call 000, the following occurs:
- You place to the call to the emergency number (000).
- Your call goes to a Telstra call centre where the operator will ask you if you need Police, Fire or Ambulance. Say the Service that you are after. If you are calling from a mobile or satellite phone the operator will ask you for other location information.
- You will be connected to an Emergency Services Operator to provide more details (see below)
In case of --
Fire:
To report a fire, the steps are:
- You request fire and the call is routed to a NSWFB Call centre located at Wollongong, Sydney, Newcastle or Katoomba.
- Once you pass the incident information to the Fire operator, the area is defined as either NSWFB area, or RFS area, the following actions are taken:
- If the area is a N.S.W Fire Brigade
- A 'firecall' is sent to the NSWFB station(s) closest to the incident and a printout is received detailing the location of the call.
- If the area is a Rural Fire Station area
- A call is placed to the RFS Fire Control Centre’s 000 line and the information is passed. The Fire Control Centre then pages the appropriate brigade(s).
The Operator will then ask further questions about the location:
- Street number
- Street name
- Nearest cross street
- Locality
- In rural areas it is important to give the full address and distances from landmarks and roads, not just the name of the property.
- If the caller is travelling on a Motorway or on a rural road, the direction they are travelling and the last exit or town they passed through.
If possible the operator will arrange to wait outside a pre-arranged meeting point or prominent location for Fire Services to arrive to assist them in locating the firel
Police:
To report a crime, the steps are:
- The Police Emergency Services call taker will ask:
- Where is your emergency?
- Location of the incident or where they should go.
- The addresses of houses and units around - either side and over the back fence.
- You may also be asked what the nearest cross street is. The nearest cross street is the nearest intersecting street.
- What has happened?
- When did this happen?
- Where is your emergency?
- Calmly answer all the questions asked by the call taker.
- Police will then be dispatched to assist with the emergency.
When a call is to report a crime in progress, the Operators will also ask for information about offenders:
- Number of persons
- Descriptions
- Vehicles
- Weapons
Ambulance:
To call for a ambulance the steps are:
The Ambulance Emergency Services call taker will ask the following questions:
- What is the exact location of the emergency?
- What is your call back phone number?
- What is the problem? (What exactly happened?)
- How many people are hurt?
- How old is the person?
- Is the person conscious?
- Is the person breathing?
000 Emergency Operators are highly skilled at assisting even the most distressed, angry and upset callers. They will guide the caller.
For urgent matters, response may start while the caller is still on the phone, and details conveyed by radio to Emergency Vehicle.
What if I need police, fire and ambulance together?
When your call is answered by the ECS request the service, which is most urgently needed in terms of threat to life. That service will organize for other emergency services to attend, if needed.
Telstra receive approximately one million calls per month (Australia wide, over two centres - Gosford and Melbourne). On average, they have 20 staff per day (increased during busy periods eg. Easter, Saturday nights).
New System
Dispatch Centre In the New System the Service’s Dispatch Centres are the first to receive all emergency triple 000 telephone requests for emergency services from the public, allied health care providers and other emergency services bypassing the Telstra call centres. Dispatch Centres coordinate the movement of emergency vehicles within their division/ geographical area to meet the needs of the community. The dispatch centre will be strategically place in the areas that they are need base on the numbers of emergencies and population such as (Sydney Operations Centre, Northern Operations Centre, Southern Operations Centre, Western Operations Centre).
Emergency Response System (ERS) The ERS is designed to utilise software for responding and attend emergency scene in the most precise time covering ambulance, police and fire operations. The system is designed to operate for 24 hours a day and 7 days a week and be used by the emergency services providers to assist them in finding the most efficient routes to dispatch emergency units between two ends point depending on their location and status. The system is also able track emergency vehicles and produce reports on vehicles movement and activities on dispatch centre in any circumstances.
- The system maintains a geographic database.
- The system can track emergency vehicles.
- The system can dispatch emergency vehicles.
- The system operates 24 hours, 7 days a week.
- The system knows all vehicles location at anytime.
- The system is able to report on vehicle movements on a specific period - day, week, month.
- The system is able to report movements of a specific vehicle on a specific occasion.
- The system is able to report activity from a nominated dispatch centre.
- The system is able to report activity to a nominated region.
- A vehicle can be added to the system.
- A vehicle can be removed from the system.
- A vehicle can be suspended from the system.
Dispatch Operator The dispatch operator are responsible for receiving all incoming 000 telephone calls, for an emergency from the public requesting a dispatch.
- Dispatch operator can also send emergency resource/s to patients.
- These operators can monitor the location of all emergency vehicles and use the system to send the closest available vehicle depending on the incidents location.
- Depending on the location or condition of the victim, Dispatch operator may also involve the medical retrieval unit and arrange for a helicopter to be sent.
Dispatch Centre staff obtains all relevant information from emergency callers and enters this directly into the ERS system. Each incident is prioritised based on questions answered by the caller, and is then assigned to the closest appropriate emergency vehicle utilising GPS tracking technology.
Details of the call are then transmitted through a government owned data network to the emergency officers who read the details on the emergency vehicle console located in the front cabin of the ambulance.
Emergency Vehicle Console (EVC) The EVC provides the Emergency Officer with relevant patient information entered into the ERS system by Dispatch Centre staff, via an easy to read touch screen.
It also allows the Emergency Officer to respond to each incident, via buttons, to indicate that they have received the case and are responding/at scene/departed scene, as well as sending/receiving messages from the Dispatch Centre.
The EVC system incorporates Global Positioning System (GPS) technology, allowing operations centre officers to locate a vehicles' position on a mapping screen within the ERS system.
In addition to the data network, Emergency Officer also have a separate radio in all Emergency vehicles which operates on the Government Radio Network or the Ambulance Private Mobile Radio systems, used for the transmission of voice messages.
System Context
Contextual Factors The effective and efficient functioning of the System can be the difference between life and death, or a building or other property being saved or destroyed. The triple zero (000) service is meant to be the quickest way to get the right help from emergency services to where and the people that need it in a life threatening or time critical situations.
Criticality The system has a High Criticality, this means that it is critical for the system to be reliable. A system failure has the possibility to result in injury, loss of life, or damage to civil infrastructure.
Time performance The Emergency Call Person currently answers 90% of calls within five seconds and 99% of calls within 10 seconds. The System aims to have 90% of the emergency response within 10minutes from when a 000 call is received at an ambulance operations centre and when the ambulance arrives at the location to treat the sick or injured patient.
Major Disaster In unplanned events such as a major bushfire, there may be a short delay in answer due to an unexpected influx of calls.
When should I call triple Zero (000)? You should call the Emergency Call Service in a life or property threatening time-critical situation (an emergency). You should ring 000 for crimes and other incidents that is actually occurring at the time of the call.
- Where offenders are still on the scene .
- That involve violence (eg. domestic violence, assault and rob, brawl).
- Where a crime has just occurred (eg. disturbing offenders breaking into a house).
- When a person fears for their safety or the safety of others.
- Any suspected offence in progress, being witnessed or just committed.
- Any situation where life or injury is threatened.
- Motor vehicle accident where persons are injured.
- Air, rail or water accident.
- Any event which might cause danger to persons or property.
- Explosion or bomb incident/threat.
- A disturbance or breach of the peace, for example domestic violence incident or anti-social behaviour.
- Traffic emergencies.
Emergency Call Services numbers in Australia
Triple Zero (000), is Australia's primary Emergency Call Service number and should be used to request emergency assistance from all telephones (landline, mobile phones, payphones, and VoIP).
The Emergency Call Service (Triple Zero) is an operator-assisted service that connects you to the relevant emergency service organisation (police, fire or ambulance).
112, is the international standard emergency number which can only be dialled on a digital mobile phone. You cannot use 112 for emergency calls from a fixed line phone at home.
106, is the text-based Emergency Call Service number for people who are deaf, or who have a hearing or speech impairment. This service operates using a teletypewriter (TTY) but does not accept voice calls or SMS messages.
- The 106 service is provided by Australian Communication Exchange, which operates the National Relay Service. The 106 service is available 24 hours a day, 365 days a year.
- When you call 106, the operator will connect you with the appropriate emergency service organisation and relay your call between text and voice.
- To call this service, you must have a text phone (sometimes called a TTY) or a computer and modem with specialist communications software, such as HyperTerminal. You cannot use SMS to contact the 106 Text Emergency Relay Service.
Both 112 and 106 are secondary emergency service numbers because they are for use only in connection with particular technologies.
Cordless Phones
are dependent on a power source, if a power blackout happens you will not be able to call the Emergency Call Service.
Mobile Phones enable individuals to call the Emergency Call Service from most places in Australia. However, the nature of the mobile phone network means that in some circumstances these calls are not as reliable as calls from the fixed network. Problems that may be experienced when making a call from a mobile phone to the Emergency Call Service include:
- Losing coverage thus terminating the call.
- Many people concurrently reporting an emergency, leading to network congestion.
- Bad reception, making it difficult for the Emergency Call Service operators to understand the caller.
- A remote location may result in limited or no network coverage being available.
- A lack of location information about the call.
When calling from a mobile phone, the operator will not be able to pinpoint your location.
3G mobile phone If you are using a 3G mobile phone, you should dial Triple Zero (000) in an emergency situation.
Global System for Mobile communications (GSM) mobile phone If you are using a GSM mobile phone in Australia, you will be connected to police, fire or ambulance when you dial Triple Zero (000). As GSM is an international standard, the international emergency call number 112 will also connect you to the Emergency Call Service. 112 can be dialled:
- In any area covered by the GSM network - when you are out of your service provider's coverage area but are in another carrier's mobile phone network coverage area, your call will be carried on the other carrier’s network.
- From anywhere overseas where there is GSM service coverage.
- Without having to key in a Personal Identification Number (PIN) to unlock your keypad.
Triple Zero (000) is normally programmed into the firmware as an emergency number. This will allow the call to use any available GSM network to reach the Emergency Call Service, regardless of whose network you are accessing.
GSM coverage
All GSM mobile phone service providers have coverage maps available from their point of sale locations, and upon request. All GSM carriers (Optus,Telstra and Vodafone) have good coverage in the major population centres, but in regional areas only one or two of these are likely to provide sufficient network coverage.
In these areas, you may be able to access 112 if another carrier has GSM network coverage in this area.
Integrated Public Number Database (IPND) The IPND is an industry wide repository/database of all listed and unlisted public telephone numbers. If you are calling from a fixed network line i.e. a land line, your location details will automatically appear on the operator’s screen and will be passed on to the emergency service organisation you request.
Geography Database. The Geography Database must be updated when a possible route for the emergency vehicle changes, such as new roads, or road works.
Unable to Speak English If a person is unable to speak English, if they call Triple Zero (000), say “fire”, “police”, or “Ambulance” and leave the phone off the hook the call will be recorded and traced and an Emergency Vechicle will be sent to that address.
Caller No Response (CNR) When the caller does not respond to the operator's question: "Emergency. Police? Fire? Ambulance?" the call is directed to an interactive voice response (IVR) unit. The caller will be asked this question three times. All callers directed to the IVR unit are asked to press 55 if they cannot speak and require emergency assistance.
- Pressing 55 quickly ensures that the call is, by default, connected to the police by the Emergency Call Service operator. If a caller does not press 55 after three requests from the operator, the call is discontinued.
- As a safety mechanism, the police will attempt to ring back all such callers who press 55 but hang up. If appropriate, the police may also dispatch an officer to the caller's address.
- The CNR process limits the number of non-genuine calls that would otherwise be forwarded to the police and divert police resources from responding to genuine emergencies.
Global Positioning System (GPS)
The Global Positioning System is the only fully functional Global Navigation Satellite System (GNSS). The GPS uses a constellation of between 24 and 32 Medium Earth Orbit satellites that transmit precise microwave signals, that enable GPS receivers to determine their location, speed, direction, and time.
The Emergency Vehicle incorporates Global Positioning System (GPS) technology, allowing operations centre officers to locate a vehicles' position on a mapping screen within the Emergency Response System (ERS).
Radio System Emergency Vehicle officers also have a separate radio in all Emergency vehicles which operates on the Government Radio Network or the Ambulance Private Mobile Radio systems, allowing the transmission of voice messages.
Voice over Internet Protocol (VoIP) VoIP calls don’t use the phone network. They route calls via the internet. To send voice across the internet, the voice information is coded into a digital format and transmitted in packets of information in the form of data. The data packets are then sent across the internet and reassembled into sound at the other end for the receiver to hear.
- In July 2007, the Australian Communications and Media Authority sought comment on the proposal to amend the Telecommunications (Emergency Call Service) Determination 2002 in relation to Voice over Internet Protocol (VoIP) services.
- The proposed key changes are designed to clarify that the providers of such services must provide free of charge access to the Emergency Call Service.
- Two-way VoIP services must also be flagged in the integrated public number database (IPND) so that the emergency service operator will know to ask the caller for location information.
This policy is still in the process of being implemented and not all VoIP service providers are able to guarantee that their service can access the Emergency Call Services.
Australian Communications and Media Authority (ACMA) ACMA regulates and monitors the provision of the Emergency Call Services under Part 8 of the Telecommunications (Consumer Protection and Service Standards) Act 1999.
- The act requires ACMA makes sure that the Emergency Call Persons, carriers and carriage service providers are meeting their responsibilities and obligations with respect to the Emergency Call Service (ECS).
The Telecommunications Numbering Plan 1997, also administered by ACMA, specifies that:
a. The primary emergency service number is Triple Zero (000); and
b. The secondary emergency service numbers are '106' and '112'.
The Telecommunications (Emergency Call Persons) Determination 1999 specifies both Telstra Corporation Limited and the National Relay Service (NRS) provider as national operators of emergency call persons who operate the Emergency Call Service.
- Telstra has the responsibility of providing the service, which answers calls to the emergency service numbers Triple Zero (000) and 112, and transfers them, with relevant associated information, to the requested emergency service organisation.
- The Australian Communication Exchange (ACE) is currently the provider of the NRS. ACE has the same responsibility as Telstra with regard to the emergency service number 106.
Since 2000, ACMA has maintained the Emergency Call Service Advisory Committee (ECSAC) to provide advice on issues relating to the emergency call service. Membership of is comprised of representatives from government, emergency service organisations, carriers, carriage service providers and the emergency call persons.
Carriers and Carriage Service Providers The Telecommunications (Emergency Call Service) Determination 2002 (the Determination) Sets out the responsibilities and obligations of the emergency call persons, the emergency service organisations, carrier and carriage service providers in relation to the provision of the Emergency Call Services.
- Integrated Public Number Database.
- Carriage Service Providers have an obligation to provide listed and unlisted numbers, and service addresses, to the IPND Manager (i.e. Telstra). This information is used by Emergency Services Organisations (ESOs) for the purpose of responding to emergency calls.
- This information is particularly vital where a caller is unable to confirm their location and the ESO will rely on the location details stored in the IPND.
Telstra Corporation Limited has the responsibility to establish and maintain the Integrated Public Number Database (IPND) as part of the:
- Carrier Licence Conditions (Telstra Corporation Limited) Declaration 1997.
- Part 4 of Schedule 2 of the Telecommunications Act (Act) specifies the obligations on Carriage Service Providers (including Telstra) to provide data to the IPND.
Privacy And Confidentiality All information given to 000 Emergency Operators is treated in the strictest confidence. Your name will be kept confidential or you can remain anonymous. When you call 000, the telephone number and address from where you are calling may be given to the emergency service so they can respond more quickly. If you do not wish to have the telephone number and address details disclosed, you must call you local police station or
911 911 is used by emergency services in the United States of America and cannot be used to call the Emergency Call Service in Australia. While there have been instances where people in Australia have dialled 911 in an emergency in Australia, research by ACMA found that 95 per cent of people were able to nominate Triple Zero (000) as the number to dial in an emergency.
Glossary
| Case | A completed Event Ticket |
| Despatch | Awful alternate spelling of Dispatch not used in this document. See Dispatch. |
| Dispatch | The physical deployment or movement of a vehicle and its crew in response to an event |
| Dispatch Operator | The telephone operator in the dispatch centre who takes calls, opens Event Tickets, assigns vehicles to the Tickets etc |
| Dispatch Operator Console (DOC) | The Dispatch Operator Console aids the telephone operator in taking calls, collecting the relevant information from callers, and initiating the dispatch procedure. |
| Dispatch Centre | The physical place where the telephone operator takes calls, opens Event Tickets, assigns vehicles to the Tickets etc |
| Emergency Officer | Driver or responsible person of an emergency vehicle. Acknowledges Dispatches and closes Tickets. |
| Event | An emergency event reported by a caller to an Dispatch Operator |
| Event Ticket | A computerised representation of the ongoing record of an Event and the log of activity in the system regarding the event. Once closed, becomes a Case and is stored in the Case Database |
| Ticket | See Event Ticket |
| Emergency Vehicle Console (EVC) | The EVC provides the Emergency Officer with relevant patient information entered into the ERS system by Dispatch Centre Staff, via an easy to read touch screen. It also allows the Emergency Officer to respond to each incident, via buttons, to indicate that they have received the case and are responding/at scene/departed scene, as well as sending/receiving messages from the Dispatch Centre. The EVC May be installed in any Emergency Vehicle (fire, police, ambulance, SES etc). |
| Emergency Vehicle | An emergency vehicle. May be fire, police, ambulance, SES etc. Crewed by at least an Emergency Officer |
Stakeholders
Stakeholder Identification and Needs
Table of Quality Attribute Importance
| Stakeholder | Performance | Usability | Reliability | Security | Total |
| System Operator - | |||||
| Dispatch Operators | 2 | 5 | 2 | 1 | 10 |
| IT Maintenance | 3 | 4 | 2 | 1 | 10 |
| Management | 4 | 3 | 2 | 1 | 10 |
| Emergency Services Personnel | 4 | 2 | 3 | 1 | 10 |
| Vehicle Mechanic | 3 | 3 | 5 | 1 | 10 |
| Victim | 5 | 1 | 3 | 1 | 10 |
| Caller | 5 | 2 | 2 | 1 | 10 |
| Public | 3 | 0 | 2 | 0 | 5 |
| "Road Using" Public | 1 | 1 | 3 | 0 | 5 |
| Government | 2 | 1 | 2 | 0 | 5 |
| Media | 2 | 1 | 2 | 0 | 5 |
| Total | 34 | 23 | 24 | 7 |
Key:
5 – Very important
4 – Fairly Important
3 – Important
2 – Considered Important
1 – Not Important
0 – N/A
This table shows the importance of the Quality Attributes to the stakeholders. Where 5 indicates a quality the system must possess and perform well at and 0 represents a non-need. From this we have derived that the primary stakeholders as being the following System operators, Emergency service personnel, Vehicle Mechanic, Caller and Victim. The primary stakeholder were chosen in reflection by the users of the system. The two most important Quality Attributes by the stakeholders are Performance and Reliability.
Stakeholder Narratives
Government
Persona: John Simms, Federal Minister for Health
Federal Minister for Health, John Simms anxiously is awaiting the introduction of the Emergency Response System. As it was his bill which brought up the issue he feels a large amount of responsibility for success or failure. As such he needs the system to perform well otherwise it will reflect very poorly on himself.
Emergency Service Personnel
Persona: Rick Shaw, Paramedic
Rick works as a paramedic responding to calls for the Emergency Services. Rick requires that the new Emergency Response System will increase the efficiency of his response. It will also need to help him get to emergency’s quicker with the maximum amount of information available to him to be able to respond accordingly.
Telephone Company
Media
Persona: Rick Colbourne, Journalist
Rick Colbourne works as a journalist for the Fairfax Newspaper. He has been assigned the job of covering the Governments latest project, the Emergency Response System. He is expecting that the development of this system will cause a lot of drama so he can write good articles, short of that he hopes for a scandal of some sort.
System Operators
Dispatch Operators
Persona: Anthony Michelson, Telephone Operator
Anthony is currently employed by the Emergency Services as a telephone operator. He is looking forward to the introduction of the Emergency Response System as he expects the system should simplify his job. He is however concerned that the new interface will be vastly different and will have a steep learning curve.
IT Maintenance
Persona: Marcus Gardin, Command Centre Operator
Marcus, an operator working in one of the Emergency Services command centre is hoping that the new Emergency Response System will facilitate his needs better. His main need is the reports he is required to create for management. Currently the system runs using old COBOL programs which are clunky to operate. As Marcus has been in his current job for a while he has become an expert in this area, but this however means there is few people who are able to assist if Marcus is ever away from work. Concerning this Marcus hopes the new system will be provide a much easier to use interface that does not require an expert to operate. This frees up Marcus to move onto other areas.
Management
Persona: Hannah Mercer, Manager
Hannah spends her days looking after her staff in the IT department of the Emergency Services. Hannah and her team are responsible for following the performance of the system. With the introduction of the new Emergency Response System, Hannah hopes that her job will become more easier. As she spends a lot of her time reading reports she understands that the new system will increase the ease at which these reports can be generated.
Vehicle Mechanics
Persona: Alex Martinez, Mechanic
Alex Martinez currently works as a mechanic contracted by the Government to work on emergency services vehicles. He expects with the introduction of the Emergency Response System he will have an easier time managing the repairing of vehicles. He also expects that the new system will allow him to be better prepared to fix vehicles which will allow him to repair more vehicles than he currently does, hopefully increasing his income.
Public
Persona: Phil Rogen, Private Citizen
Phil Rogen a private citizen has taken great interest in the media coverage that the new Emergency Response System has received. Phil remembers reading about similar systems in the past that have been utter failures. He expects that this new system will not fail but will reduce the time required for someone seeking assistance in an emergency situation.
Persona: May Watkins, Mother
May Watkins of 3 Fantale Crescent has been eagerly following the development of the Governments new Emergency Response System. As a mother of three, May is often worried about the well-being of her children. Knowing that this new initiative of the Government should increase the safety of her children makes her very happy. From what she has read she has come to expect that the system will reduce the time it takes for an Ambulance to get to her home to help if one of her children falls ill, or increase the efficiency of Police as they pursue a suspect who may have just mugged another of her children. In all, May believes that this system will be a betterment for the country.
Victim
Persona: Dimitri Goldberg, Courier
Dimitri lay grasping for air on the cold linoleum floor of a downtown shopping centre. An ambulance has been called and they instructed someone to lie Dimitri on his side and to keep him conscious and await for assistance from the paramedics. Dimitri needs the ambulance to arrive as soon as possible as every breath becomes a struggle, he does not think he can last much longer.
The paramedics arrive on the scene with little time to help Dimitri. On the way back to the hospital Dimitri dies, and is non-responsive to resuscitation methods. If the Ambulance had arrived just one minute sooner Dimitri’s chance for survival would have been much higher, but unfortunately the Ambulance took a shorter route but contained heavy traffic. The new Emergency Response System could have provided a faster route choice to the Ambulance and saved Dimitris’ life.
Reporter/Caller
Persona: Chris Difford, Janitor
Chris Difford can hear lots of shouting coming from the next door neighbours house. He thought he heard the man living there mention something about a gun. Chris becomes worried for the safety of his family and also of the people living next door. So he dials 000 and explains the situation to the operator. He expects that police should arrive promptly to investigate the matter. Also the police should make the family safe.
"Road Using" Public
Persona: Tim Watkins, Truck Driver
Tim is a little indifferent to the new Emergency Response System, it still means that emergency vehicles are on the road and that he will have to move out of their way if they approach with lights flashing. However he thinks the new system should change the route that emergency vehicles take to more less traveled roads.
Usage Narratives
Caller
Persona: Jan Day, Fisherman
Jan’s husband David has collapsed after having breakfast. Jan dials 000 and tells the operator that her husband has collapsed and requires the immediate assistance of an Ambulance. The 000 operator confirms Jan’s address. Due to Jan requiring an Ambulance, the 000 operator also asks her How many people are hurt, how old is the person, is the person conscious is the person breathing and for any other information that might be helpful.
Five minutes later paramedics arrive at Jan’s house and assess David s’ condition before loading him into the ambulance and taking him to hospital where he is diagnosed as having a minor heart-attack. David makes a full recovery after 2 weeks of rest at home and taking prescribed medication.
IT Worker for Emergency Services
Persona: John Carter, IT Department of Emergency Services
John an employee of the Emergency Services is asked by management to produce a report of activity in the South West Sydney region for all ambulance, fire and accident response units only. John then goes to a computer and logs into the Emergency Response System. He then selects the reports option, then the region. Then he selects the units that he wishes to generate a report on. The report is then generated from a template and he is free to email it or print it out to give to management.
Emergency Worker
Persona: Rick Shaw, Paramedic
Rick, an ambulance driver is out driving with his partner Tom. The screen on their onboard computer flashes indicating incoming instructions. Rick taps the screen and views the information. A man has collapsed and is in need of immediate medical assistance. This is followed by the address to respond too. Rick hits an acknowledged button onscreen and is presented with a map as well as directions to take to get to the house. When Rick and Tom arrive at the house they quickly assess the man and then place him into the ambulance to take him to hospital. Tom taps a button on screen and the display promptly shows the fastest route to take to get back to the hospital. Following the route displayed they quickly arrive back at the hospital where the patient receives medical care.
Rick presses a button on the onboard computer which notifies the Emergency Services System that it is finished with that job and is free to accept a new job.
Dispatch Operator
Persona: James Worthington, Telephone Operator
James a telephone operator for the Emergency Services is sitting at his desk waiting for a call. He has his interface to the Emergency Response System logged in, open and waiting to log a call. The telephone rings and the lady at the other end tells him that her husband has just collapsed and is in need of an ambulance. James takes her name and address and inputs this into a form on-screen. Once the required information has been taken down James submits the data and informs the lady that an ambulance will arrive shortly. From here the data taken down is sent to a main server, as well as stored in a database, where the server calculates the closest ambulance and then forwards this information onto it. It also generates the fastest route for the ambulance to take and then the subsequent route it needs to take to get back to a hospital.
Vehicle Mechanic
Persona: Jim Faulkner, Mechanic
Jim, a mechanic employed for maintenance on emergency services vehicles, arrives at work in the morning. Having finished maintenance on the last car the night before Jim goes to the computer to check if any other vehicles are requiring maintenance. Jim logs into the Emergency Response System. As part of his access conditions he is able to view a list of vehicles that are requiring maintenance. He notes that there is a Fire Engine that needs a valve changed on one of its tanks and that it will be in at 11:00AM. Jim logs out of the system and tidies up the workshop until at 11:00 the fire engine arrives.
After two hours of work on the fire engine it is ready to be returned to duty. Jim once again logs into the Emergency Response System and into the part concerning vehicle maintenance. He certifies that the fire engine has had its valve replaced and signs off on it. This changes the status of the vehicle in the system.
Later the fire engine is picked up and taken back to its fire house.
Command Centre Operator
Persona: John Smith, Command Centre Operator
John, an operator working in the Command Centre for the Emergency Response System, intently stares at the big screen in front of his desk. The screen extends almost across the entire wall with desks in an arch around it. The screen displays the position of all the different emergency response vehicles on a geographic map of the region which is updated regularly. From here the position of the vehicles can be tracked throughout the day as their position is updated frequently when they are online.
However John’s main role in the command centre revolves around adding, removing and updating status’ on vehicles. When Emergency Services commission a new vehicle its details must be taken down so it can be stored in a vehicles database. When removing a vehicle data is not removed from the database as keeping it can be useful for record keeping purposes. The status is just changed to ‘Decommissioned’. John may have to update the status of a vehicle for many reasons, such as decommissioning, maintenance and returning to service.
Government
Persona: Natalie DeVoshe, Parliamentary Enquiry Committee
Natalie, employed by the Australian Government, is currently working on an enquiry into the performance of the Emergency Response System and whether the new system has increased efficiency and reduced response times as it was intended. To do this she requires data collected by the Emergency Response System to compare it to data previously obtained on the performance of Emergency Services prior to the introduction of the new system. In order to obtain the data that she needs she is given free access to the records section of the system through a temporary username and password issued to her.
Natalie logs into the system to gather some data on average response times in regions. She enters the username and password she is given and then waits while the system logs her in. Natalie then clicks on the reports button and is presented with a screen with a lot of different things to report on. As she is interested in response times she selects the corresponding option, and then tells the report system to sort it by region. After this is done the generate report button is clicked and Natalie is able to study the results. From the data in the Emergency Response System Natalie is able to determine that the introduction of the system has reduced response times an average of 35%.
Vehicle
(an inanimate user)
Ambulance 3 of the Nepean District with registration TQM-975 solemnly sat in its parking space awaiting the arrival of ambulance officers to whisk her away to danger and adventure. As she sat there she had no need to perform her usually duty of sending her location back to base as she was in an offline state. That is she was recorded as being at base so no further communication was necessary until she came online.
A short while passed and two familiar ambulance officers rushed out and quickly got in to Ambulance number 3. As the ignition switch was turned Ambulance 3 sent out a message to base notifying them that she had come online and that she would begin transmitting her position. Every 10 seconds Ambulance 3 gets its updated position from a GPS device and sends the information back to base, where it is stored in a database as well as plotted on a real-time display. The Ambulance continues to do this till an Ambulance officer changes her status to offline which can only be done when she is back at base and finished with a call. Ambulance 3 then notifies base that she is offline and stops sending up dates of her position.
Quality Narratives
Emergency service’s is always on duty in case of any urgent situations arising. A quick response from emergency services often saves lives and can easy the pressures of the situation like limiting a bush fire, and clearing a road of traffic after an accident. In emergency services the systems have support networks and also contingency plans that are activated when the situation arises, these networks and plans help absorb the pressures of extreme adverse situations.
Performance and Reliability are the two key attributes to the system H.E.L.P, for a two main reasons. Firstly the system narratives list the need for the system to ’operate 24/7’ and also ‘track all vehicles at any time’. Secondly the identified stakeholder needs show the two quality attributes as the most needed and desired for the system.
Performance
Speed is a key determining factor in any emergency situation, from life or death to physical injuries. Performance is a key attribute for any emergency system as attested by the stakeholder narratives and the table of quality attributes. In realizing performance as a key requirement for the system, the plan emphasizes this key attribute in minimizing the number of steps to complete tasks. The following narratives further emphasize the importance of performance for an emergency system.
Persona –
Anthony Michelson, Telephone Operator
Anthony is a dispatch operator that is to answer all incoming calls, within 10 secs from the first tone sound. Included in Anthony’s job is the ability to access and view all the emergency service vehicles available that can assist in the situation that the caller is advising Anthony about over the phone. This information is required to be kept and sent to the emergency vehicles en-route to the location of the situation to help prepare for the situation.
Persona –
Hannah Mercer, Manager
Hannah managers an emergency dispatch centre which requires that Hannah read many reports regarding the ability, capacity and arising situations in the area. As multiple reports are needed to be assessed and created by Hannah, the system is to provide the reports in a timely manner. A report selected to view or created by Hannah should not take more then 5secs to generate and display from selection to the monitor.
Reliability
Break-down of an emergency system is the first step to disaster for the victims that the system was conceived to protect. As an emergency system is depended upon to help protect people the reliability of a system is vital, as the consequences of failure can be insurmountable and can lead to dire situations arising. The reliability of a system is determined by a number of factors, from maintenance to contingency plans. These factors when implemented properly allow a system to handle unexpected pressures and situations that would otherwise cripple the system.
Personas –
Rick Shaw, Paramedic
Rick is an emergency service vehicle operator, specifically an ambulance vehicle operator he is at the front line of the emergency services ability to respond to 000 callers. As Rick is an ambulance vehicle operator he provides first aid medical care to stabilise victims, and transport to a local hospital. To help Rick’s do his job of saving lives he needs to know the situation and as much condense details of the victim injuries as possible.
Conceptual Architectural Analysis
Initial Conceptual Architecture
Initial Conceptual Analysis
Preliminary
The above Conceptual Architecture was produced in concert with the eliciting project requirements and the overall project architecture through the identification of stakeholders, stakeholder narratives and usage narratives.
Subsequent to its development, an Execution Architecture specification and Implementation Architecture view were developed from it. Commensurately, an elaboration was made on the initial Conceptual Architecture. This elaboration was based on finalised narratives and a intent amongst the project team to refine and better model the flow of data within the system. Thus it should be noted that this initial diagram and architecture is the basis for all other architectural analysis performed on the project.
Critique of Architecture
This diagram was quickly elaborated upon. As such, in lieu of a direct analysis of each component, a critique of the architecture insofar as it was expanded or adjusted in the Elaboration is presented below.
- Active Ticket Model - An idea expounded in the diagram view of this architecture is the idea of the Event Ticket. This ticket contains the salient details of an ongoing emergency event (refer to Data Models). It is then filed in the Case Database. In the Elaboration, this architectural concept was expanded upon.
- Miracle Routing System - The problem of how presence of a 'Miracle Routing System' and the requirement to maintain a geographic database were shoehorned together. This was subsequently broken up into identifiable components the Elaboration.
- Actors as Interfaces - A key stakeholder in the system, the Caller, has no direct interface with the system. Ordinarily the Conceptual Architecture would therefore not show this stakeholder. To reinforce the roll of the Caller in the System, the interaction of the Caller and Operator are shown as interfaces in the diagram. This is in no way incorrect: they are a human-human interface (Caller-Operator) and human-machine interface (Operator-system) rather than a typical machine-machine interface.
- Circuitous Flow of Information - The "Update Status" component received a lot of information from disparate data sources - from vehicles and from the vehicle database. The flow of information suggests any entry in the Case Database required, at least, a trip through the Vehicle Database, through processing and into a "Ticket". There is no logical relationship between the entirety of the contents of a "Ticket" and the Vehicle Database.
- No dispatch accept/decline method - No mechanism is provided for the Emergency Officer in-vehicle to provide notes on a given dispatch or to accept or decline a dispatch. Usage narratives clearly envisage a system by which Officers are in constant contact with the Emergency Dispatch Response System and one which gives these Officers the final say on whether or not to accept tickets.
- Need to bifurcate "front" and "back" of vehicle operations - The initial conceptual architecture makes no visible distinction between the system by which a vehicle reports its position (which, by necessity, involves some sort of device in the vehicle [see Deployment View]) and the system by which new vehicles are added to the system, or set as unavailable on account of maintenance. In the Elaboration, the separation of these concepts is clearly delineated.
Elaborated (I) Conceptual Architecture
Elaborated (I) Conceptual Analysis
Preliminary
The 1st Elaboration of the Conceptual Architecture expands significantly upon the work done in the Initial phase. Below again is a critique of the architecture as it stands from this Elaboration. From this Elaboration, as well as the work in producing an Execution and Implementation Architecture, and then from commencing to construct a prototype system, a second Elaboration (here labelled Elaborated (II) Conceptual Architecture) was produced.
Critique of Architecture
- Performance Impacts of Event Ticket and Geolocator - As is visible by the large number of inputs and outputs to these components, and as is identified by Impact Maps, the Event Ticket and Geolocator components may be a performance bottleneck. The above descriptions, however, provide an architectural rationale for this set-up. Accepting this, and not wishing to change this aspect of the architecture, a Design Note is offered: these components will need significant optimisation to meet performance metrics.
- In the alternative, the primary utility (as noted) for passing a large amount of detail through the Geolocator is to ensure all locations are normalised. It may be possible to reduce this normalisation to a contractual specification. In such a circumstance it is unnecessary to pass data through the Geolocator for normalisation purposes.
- Un-tree-like Data Flow - Whilst the architecture does present a loose hierarchy of components, it does not disclose a strict tree-like hierarchy of data flow as from User Presentation components through the system to Persistent Storage components. In turn the system may be more difficult to design and moreover to implement. However, the needs of the system as regards to its distribution and its many external interfaces act to preclude this.
- No User Presentation component for administration tasks - The administrative tasks - namely the Update Geographic Database component provide no user presentation component. Specifying this component will ensure the invocation sequence appears in the Execution Architecture where it is particularly necessary to note its existence. These changes need to be made in a subsequent elaboration.
- Change to Remove Vehicle Behaviour - As indicated by the corresponding Use Case Map, a change the the Remove vehicle component is required. Instead of passing information directly to the Vehicle Database, it should instead pass information to Update Vehicle Status: removing a vehicle is merely a subset of the functionality required to update a vehicle's status.
- Absent User Authentication components - Implicit in the project brief and expressed to varying degrees in Stakeholder and Usage Narratives is the idea (1) that the system is auditable insofar as it can track who causes what action to occur and (2) that certain users of the system will access certain parts of the system and not others. This needs to be modelled with a series of components that handle Access, Authentication and Authorisation (AAA). These changes need to be made in a subsequent elaboration.
Elaborated (II) Conceptual Architecture
Elaborated (II) Conceptual Analysis
Preliminary
This final elaboration of the Conceptual Architecture addresses the shortcomings identified in the analysis sections of the previous two drafts. It reflects the system as architected in the execution and implementation architecture views and was used to commence implementation of a prototype system. A description incorporating the roles and responsibilities of each component is detailed next. Note from the above analysis the presence of non-machine-machine interfaces. These are not described.
Component Descriptions
User Presentation Components
- Operator Console - the main interface between the Dispatch Operator and the system. This will likely exist as a standard GUI form which enables the Operator to record the salient details as relayed by the caller (see Data Map). The component is also a gateway component to a major flow of information relating to ticket creation or cancellation (see Caller use case map, below).
- Active Events Console - the intent of this component is to provide an overview of the current Event Tickets for a given emergency service and/or call centre in real time. It would then be used by Command Centre Operators to coordinate the emergency response in a major event. To this end the component receives, as input, the details of Event Tickets currently active.
- Vehicle Management Console - the component for enabling the Adding or Removal of a vehicle to/from the system or to update a vehicle's status. The term 'Remove Vehicle' is to be changed in a subsequent iteration (see Critique, below)
- Activity Report Console - a broad range of reporting tasks are stipulated in the project brief. They are identified again as necessary in the narratives for government and for emergency service agencies' IT workers. They need to be collated into a single, intuitive presentation. That presentation interface is the Activity Report Console.
- Vehicle Console - an identified deficiency of the initial conceptual architecture is the ability to accept or decline Dispatches. In addition to this, primary research and narratives reveal that a vehicle may itself be made unavailable by its crew for a period of time. This component resides in the emergency vehicle itself and facilitates user access to these functions in addition to reporting to the crew of the vehicle the details of the Dispatch.
External Interfaces
- Geolocation Provider - the provisioning of material for the Geographic Database is a common requirement amongst many business tools. A number of companies, including Sensis and Google, provide Geolocation services for Australian addresses. This information must be batched into the Geographic Database at reasonable intervals. The Update Geographic Database component handles the conversion from the Interface to the Database.
- Reverse Phone Directory - uncovered by research and required by narratives (which require the fastest possible location of the caller) is the conversion of phone numbers into addresses. A Reverse Phone Directory is not publicly available but is in use in current emergency response systems.
- Miracle Routing System - this interface is specified by the project brief. In order to meet the realtime requirements of the Emergency Dispatch Response System, this miracle routing system would need to be located in close physical proximity to the Router component.
- Wireless Communication Network - this may be a cellular, packet UHF radio, WiFi, WiMax etc network (or multiple networks depending on availability throughout the country). The specification of this network is beyond the scope of this Architecture document. Instead a generic interfacing system is visible even at the Conceptual level to permit maximum compatibility with whatever network is used with this system.
- GPS Receiver - fundamental to the system knowing where a vehicle is located is a vehicle knowing where it itself is located. The Global Positioning System does this. The GPS reading is provided to the in-vehicle part of this Emergency Dispatch Response System and in turn transmitted across the abovementioned Wireless Communication Network and eventually, into the Vehicle Database.
Persistent Storage Components
- Event Ticket - identified as an 'active' component in the Initial Analysis, and assigned the 'realtime' stereotype in the Elaborated Diagram in addition to the 'persistent storage' stereotype, the Event Ticket is at the core of the system. The Event Ticket component is responsible for:
- Intermediate storage of the details of a call (prior to ultimate storage in the Case Log Database)
- Storage of the route found for the vehicles (prior to being destroyed)
- Calling the Transmit Dispatch component to cause a dispatch or other information to be sent to a vehicle
- Receiving any updates to a vehicle's status relevant to the Event Ticket from the Receive Vehicle Status component
- Storing itself in the Case Log Database when closed or cancelled
Design Note: Event Ticket would itself exist as a class of multiple instances
- Case Log Database - stores Event Tickets once closed. Queried by the Case Reporting Component to produce reports on call centre activity.
- Geographic Database - stores geolocation information. Essentially this is a relational table that connects street names and numbers with GPS (or latitude/longitude) coordinates. See Data Map.
- Vehicle Database - stores vehicle static details - name, service, registration etc (see Data Map). Also stores the last recorded position for the vehicles as updated by the Update Vehicle Position component.
- Authentication Database - stores user authentication information and user rights assignments. This allows the system to grant or deny access to certain parts of the system.
Realtime and other Components
- Modify Dispatch - invoked from the Operator Console, causes a change message to be sent to a given Event Ticket. The Event Ticket would itself be responsible for having the cancellation transmitted to any vehicle, setting its status to closed and filing itself in the Case Log Database
- Create/Update Event Ticket - also invoked from the Operator Console begins the process of creating an Event Ticket. The inputs to the component are as entered by the Dispatch Operator. This information is then passed on to subsequent components that build upon this information.
- Find Caller - attempt to geolocate the caller. This requires passing the phone number or some manually entered location name to the Geolocator component. It in turn must use the Reverse Phone Directory interface or the Geographic Database to find the coordinate location of the caller.
- Find Vehicle - given the location of the caller is known, the most appropriate vehicle can be found. The Geolocator must be invoked to pull vehicle information from the Vehicle Database. The chosen vehicle can then be returned.
- Route Vehicle - provides a route between two locations. This is by means of invoking the Router component which itself is the Emergency Dispatch Response System interface to the external 'Miracle Routing System'
- Geolocator - the Geolocator is a core function of the system. It must normalise locations (addresses, phone numbers etc) into a known coordinate system (which coordinate system is a design decision, but likely latitude/longitude). By architectural intent, all reading of locations are passed through the Geolocator. This accommodates any modifications that need to be made to raw stored locations. However it may prove a bottleneck (see Analysis, below)
- Router - an internal interface between the external 'Miracle Routing System' and the Route Vehicle component. Allows the accommodation of any changes to the routing data format produced by the Miracle system to be transparent to the rest of the system.
- Access, Authentication, Authorisation - handles the access, authentication and authorisation of functionality of the system. Provides, as required and given the user's credentials, a response to the client interfaces as to whether the user is allowed to perform or invoke a certain task.
- Transmit Dispatch - cause the contents of the Event Ticket provided to be transmitted across the Wireless Communications Network to the corresponding in-vehicle Receive Dispatch component. Again this component exists to provide constant interfacing with the rest of the system despite what implications arise from the specifics of the chosen wireless network.
- Receive Vehicle Position - receives updates vehicle coordinate information. Passes this on to Update Vehicle Position for updating the Geographic Database. Provides a constant interface with the rest of the system despite what implications arise from the specifics of the chosen wireless network.
- Receive Vehicle Status - receives updates to an Event Ticket as transmitted by a vehicle. Thus this component passes on that which is received to an Event Ticket. Provides a constant interface with the rest of the system despite what implications arise from the specifics of the chosen wireless network.
- Update Vehicle Position - given the provided position from the vehicle, this component will invoke the Geolocator for any intermediate processing then cause the position of the given vehicle to be updated in the Vehicle Database.
- [in vehicle] Track Vehicle Position - takes a reading from the in-vehicle GPS receiver and causes this to be transmitted across the Wireless Communication Network to the Receive Vehicle Position component.
- [in vehicle] Receive Dispatch - receives a Ticket from across the Wireless Communication Network and displays its details on the in-Vehicle Console.
- [in vehicle] Update Vehicle Status - transmits any status updates provided through the Vehicle Console to the Event Ticket across the Wireless Communication Network.
- [in vehicle] Dispatch Acknowledgement - converts the acknowledgement or refusal of a dispatch into an update which can be communicated to the corresponding Event Ticket.
- Update Geographic Database - a maintenance component. Performs any conversions between the geolocation data provided by the external Geolocation Provider an the format in which it is stored in the Geographic Database.
- Vehicle Console Manager - handle the Vehicle Management Console interface by making the necessary changes to the vehicle database - adding and removing vehicles, changing vehicles' status etc.
- Vehicle Reporting - pull the specified information from the Vehicle Database and generate a report in the specified format or of the specified type.
- Case Reporting - pull the specified information from the Case Log Database and generate a report in the specified format or of the specified type.
Use Case Maps
Use Case Maps were then used to model the behaviour of this conceptual model.
Event: Create Event Ticket
In case of emergency dial...
This map shows the primary means of interaction with the system - the creation of a New Event Ticket in response to a call. The sequence is as follows:
- The Dispatch Operator, on receiving a call moves to Create Event Ticket to create a new Event Ticket.
- The system upon the entering the salient details by the Operator and as provided by the Caller, moves to find the location of the caller in the Find Caller component.
- Find Caller requires the Geolocator and provides either the phone number or a textual location of the caller's location
- The Geolocator causes a search of the Reverse Telephone Directory OR Geographic Database to find the location of the caller. It normalises the location and returns the coordinates
- The system then locates an appropriate vehicle to dispatch using the Find Vehicle component
- Find Vehicle requires the Geolocator and provides the location of the caller from which the Geolocator can find the appropriate vehicle.
- Geolocator queries the Vehicle Database for the appropriate vehicle
- Geolocator queries the Geographic Database as required to normalise the selected vehicle position
- Geolocator can then return the chosen vehicle
- The system then chooses an appropriate route for the vehicle to follow using the Route Vehicle component
- Route Vehicle requires the Router component which normalises the routing information in turn provided by the external 'Miracle Routing System' in the design-specified route structure/format
- All the information now attained is used to build an Event Ticket that represents the ongoing event.
- The Event Ticket then in sequence
- Posts itself to the Active Event Console
- Creates itself in the Case Log Database
- Transmits itself to the in-Vehicle Console by means of the Transmit Dispatch component
- Transmit Dispatch marshals the Event Ticket for transmission in the format required for the external 'Wireless Communication Network'
- The in-vehicle Receive Dispatch reconstructs the Event Ticket from the communication network and posts the details to the in-Vehicle Console upon which time the system waits for the acknowledgement of the Emergency Officer
- The Emergency Officer by interacting with the Vehicle Console indicates an acknowledgement of the dispatch
- The Acknowledge Dispatch component causes a correct acknowledgement packet to be generated and passed to Update Vehicle Status for transmission across the Wireless Communication Network.
- Update Vehicle Status marshals the acknowledgement
- Receive Vehicle Status reconstructions the acknowledgement from the Communication Network and posts it to the Event Ticket
- The Event Ticket then updates the Active Events Console
- The above process repeats for any ticket updates
- Once the Event Ticket is marked closed or cancelled, it stores itself in the Case Log Database
Event: Acknowledge Dispatch
This map shows the Acknowledgment of a Emergency Officer that they have read the Dispatch and is responding to the call. The sequence is as follows:
- The Dispatch details are transmitted to Emergency Vehicle Console (EVC)
- The EVC Receives the Dispatch and Displays to the Emergency Officer
- The Emergency Officer acknowledges the Dispatch, reads the information, and if they are able to respond they will accept the dispatch
- The Vehicle transmits a packet to signify it status is now responding
- The Emergency Response System (ERS) updates the Vehicles status to responding
Event: Track Vehicle
This map shows how the ERS server tracks an Emergency Vehicle. The sequence is as follows:
- The Emergency Vehicle has a GPS receiver, which it uses to get its coordinates.
- The Emergency Vehicle then sends a Vehicle GPS Packet to the Emergency Response System (ERS) containing is coordinates.
- Once the ERS receives the coordinates of the vehicle it cross-references them using the Geolocator to determine the vehicles location.
Event: Completed Case
This map shows what happens when the Case is completed, the incident has been resolved, and the Emergency Officers are on their way back to the garage. The sequence is as follows:
- The Emergency Office uses the Emergency Vehicle Console (EVC) to confirm that the Case is Completed.
- The EVC transmits a status packet to update its status.
- This in turn tells the Emergency Response System (ERS) to update the vehicle status.
- The ERS also Completes the case and updates the Case log database.
Event: Manage Vehicle
Add vehicle event is the process of entering the details of a new vehicle in to the database registry.
- Command Centre Operator Authenticates and accesses the Vehicle Management Console interface
- Command Centre Operator creates a vehicle event (add, remove, edit)
- Where removing or editing:
- Command Centre Operator searches for the vehicle
- After the vehicle is found, the operator sets the vehicles status attribute
- Enters details to the status change
- Where removing or editing:
- Command Centre Operator enters the details of the vehicle into the interface
- Command Centre Operator confirms and saves the details to the database
Event: Create Case Report
Allows the emergency service to monitor the situation of the emergency services
- Command Centre Operator Authenticates and accesses the Activity Report Console interface
- Command Centre Operator selects create case report from the interface
- Command Centre Operator selects the details required for the report
- The information needed is retrieved from the database
- The information is then formatted in the standard template
- Confirms and saves and report in achieving
Event: Create Vehicle Report
Allows the emergency centre to function more effectively and allow the operators to monitor and effect change
- Command Centre Operator Authenticates and accesses the Activity Report Console interface
- Command Centre Operator selects create vehicle report from the interface
- Command Centre Operator selects the details required for the report
- The information needed is retrieved from the database
- The information is then formatted in the standard template
- Confirms and saves and report in achieving
Impact Maps
Maintainability
Updating Geographical Database
Description
The geographical database needs to be updated every year to reflect the changes to the streets and adjustments to planning and other projects. Geolocator class also needs to be adjusted to reflect the changes in the geographical database in terms of tables and information stored in data types.
Updating Reports
Description
As the changes to system are needed in the form of improvements and refocusing on priorities the reports that help inform management needs to changes as well. The changes can range from data selected to create reports to graphical representation to design of the report it self in terms of information flow. The vehicle database will need to be updated as the information required for the report may need extra information or different types of information.
Scalability
Description
As the operators improve the system and new technologies become available new questions and information maybe needed to assist the emergency services to improve. The opposite can also be true in where information required now may become obsolete.
Data Models
Data models were also used to identify architectural level key data elements.
Activity Report Console - Interface
|
||
|
Activity Report Console offers two types of report - the vehicle and case ticket reports:
Requirements:
|
Operator Console - Interface
|
||
|
Operator Console is an GUI that allows operator to create, cancel and update a ticket. Requirements:
|
Active Event Console - Interface
|
||
|
Active Event console captures all active case ticket and allow the operator follow up the ticket if necessary. Requirements:
|
Vehicle Management Console - Interface
|
||
|
Vehicle Management Console allows an operator to add, update and delete vehicle. Requirements:
|
Vehicle Console - Interface
|
||
|
Vehicle Console is operated inside the vehicle which allowed:
Requirements:
|
Vehicle Database
|
||
|
Vehicle database stores the vehicle data includes:
|
Case Log Database
|
||
|
Case log database stores the case ticket data includes:
|
Critique of Architecture
- Better reflection of domain responsibilities - In this elaboration a number of command clusters and redundant, small components have been removed to more accurately model the domain responsibilities of the system.
- Performance Impacts of Event Ticket and Geolocator - As identified in the first elaboration, and as visible by the large number of inputs and outputs to these components, and as now identified by Impact Maps, below, the Event Ticket and Geolocator components may be a performance bottleneck. The above descriptions, however, provide an architectural rationale for this set-up. Accepting this, and not wishing to change this aspect of the architecture, a Design Note is offered: these components will need significant optimisation to meet performance metrics.
- Note in this elaboration the conceptual architecture more data is stored pre-normalised in the Vehicle and Geolocation Database. This reduces the need to call and perform calculations in the Geolocator that are expensive in terms of computation power and which may slow the system.
- Event Ticket discloses Blackboard Architecture - The Event Ticket component lends itself to implementation of the Blackboard structural design-pattern. The Ticket contains the up-to-date, single-source repository of all information about a currently active dispatch. This prevents time- and CPU-costly database lookups or data cache lookups - all the requisite information is available to other application components from the one location.
- Un-tree-like Data Flow - Whilst the architecture does present a loose hierarchy of components, it does not disclose a strict tree-like hierarchy of data flow as from User Presentation components through the system to Persistent Storage components. This revision makes a number of improvements in the area, with demonstrable separation between the client-side interfaces (Tier-1), server-side interfaces (Tier-2), server-side processing (Tier-3) and data storage (Tier-4). This facilities the extraction of a Model-View-Controller structural design pattern in the Execution Architecture. It also facilities the deployment view and implementation architectures proposed.
- No User Presentation component for administration tasks - The administrative tasks - namely the Update Geographic Database component provide no user presentation component. Specifying this component will ensure the invocation sequence appears in the Execution Architecture where it is particularly necessary to note its existence.
- Bolt-On User Authentication components - Modelling of components that handle Access, Authentication and Authorisation (AAA) has been bolted on to the conceptual architecture. As is visible from the diagram, AAA is handled by the clients themselves. The security implications for this type of AAA must be assessed by an expert - there may be vulnerabilities particularly from man-in-the-middle attacks, or the cached Authentication and Authorisation credentials may be manipulatable on the client software themselves. This is particularly the case where the clients are accessible via the public Internet.
Execution Architecture
Concurrent Subsystems View
Description
The concurrent subsystems view is an overview of how the subsystems are connected and how information and data will travel across the system. The diagram is use to map out the flow of data and information to expose bottle necks and critical components that effect quality attributes of the system.
The following describes each component of the above diagram:
- In-Vehicle Console – the user interface which allows the emergency service vehicle operator to interact with the system. This can be from a simple location beacon by transmitting a GPS location back to the system to an update on the situation to a case ticket.
- Operator UI – the interface for the emergency centre operator that handles incoming calls, creates case tickets and dispatches emergency service vehicles to the emergency’s location.
- Activity Reporting UI – a management interface that generates reports and statistics for the emergency centre senior management team. The information generated is used by the executives of emergency services to monitor, adjust and improve the system.
- Vehicle Management UI – the interface that allows the emergency service management team to schedule maintenance, and view general statistics to the available vehicles for all services.
- Application Service – the main server that handles the business logic of the system, this is also to handles database access.
- Web Service – This is to handle the logic for the activity reporting and vehicle management.
- Databases – the persistent storage of all the data and information for the system.
Static Invocation View
Description and Critique
The execution architecture presents the concurrent activity components based on the conceptual architecture. The component responsibilities include. The above model is static - it represents the system when it running in a steady-state. Some notable facets of the dynamic invocation of the system are modelled below.
Note also the structure of the system, execution can be, generally, traced through three groups of components here-labelled "Presentation", "Controller" and "Data" layers. This in turns facilitates implementation by means of the Model-View-Controller structural (architectural) design pattern.
Each component has responsibilities as follows:
- Operator UI - The operator initialised by first calling to request service from the Event Ticket Manager. The Event Ticket Manager will call back after a certain processes have completed.
- Event Ticket Manager - The component Event Ticket Manager locates destination of the caller by synchronously calling GeoLocator component. Once the GeoLocator response, Event Ticket Manager will get the routing information by calling Router component and then combine all data together calling the Event Ticket component.
- GeoLocator - GeoLocator call Geographic database component and then response.
- Routers - Routers component call to get routing points (Miracle System).
- Event Ticket - Event Ticket component synchronised call to the Vehicle Message Receiver component to ensure the nearest available vehicle assigned the event ticket and dispatched to the emergency vehicle. In conjunction, Event Ticket component call synchronously to the Case Log database component to ensure all information updated.
- Management Activities UI - This UI retrieve report from the Report Generator Component. Upon the report is generated, a call back to UI.
- Report Generator Component - This component calls synchronously to Case Log Database and Vehicle Database components to retrieve data and generate a report.
- In-vehicle Console - This component is initialised in-vehicle for user to update an event ticket through junction of Vehicle Message Transceiver.
- Vehicle Message Transceiver - Vehicle Message Transceiver component is a junction of Event Ticket and the In-Vehicle Console to ensure message updates on both end.
- Vehicle Position - A standardised technology actively asynchronous call to a specific component (e.g. Vehicle Message Transceiver) to determine vehicle current position.
- Vehicle Management UI - Request services by calling the Vehicle Manager component. Services include adding, updating and deleting vehicle.
- Vehicle Manager - This component interacts with Vehicle database component to ensure all details updated.
Dynamic Invocation View
A number of notable and important dynamic facets of the system have been modelled. This primarily affect the creation of components when user interfaces connect, or when new event tickets are created.
New Dispatch Operator, New Event Ticket
The Diagram is showing the Concurrent Subsystem involved with an Operator creating a new Ticket. This happens when an Operator recieves a new call and is required to dispatch vehicles. The Operator UI sends the information in the ticket to the server, via a Socket and a Service which manages the connection to the server. From here the Operator UI handler is able to handle the ticket so that it can be saved and also can send out a notification to Vehicles that are capable of accepting a new Ticket.
New Vehicle online
The concurrent sub-system modeled here is showing a new Vehicle changing its status to Online. This happens after a Vehicle is finished a job and is ready to accept another, or when the vehicle is first coming online after being offline for reasons such as maintenance.
The In-Vehicle Console connects to the server using Sockets and the Server Acceptor Service and sends a message to the Vehicle Message Transceiver to notify it that its status has changed to Online. The Vehicle Message Transceiver updates the Active Vehicle List in the Database with the Vehicles change in status. Also if the Vehicle was currently involved in an Event Ticket, the ticket is also update with the change of state.
(Web-based) Vehicle Management (connect)
Shown here is one of the Concurrent systems which runs over the Internet. The Web Server used is Jetty which is used to run Server Side programming. A User can manage the Vehicle over the Internet using the Web Server and the Processes sitting behind it.
(Web-based) Report Generation (connect)
The Reporting functionality of the System is provided over the Internet. The Diagram is simple and reflects the way the sub-system works. The Activity Reporting UI displays information about Reports that it retrieves from teh Report Display Manager. The UI accesses this Manager through the use of sockets and the Jetty Web Server.
Deployment View
Description
This Deployment View shows the mapping of execution components from the above Initial Execution Architecture to physical locations, devices and hardware. Note that on account of this being an Initial view, there may be inconsistencies as between this view and the Execution Architecture diagram. In addition, to aid in legibility, only some core components that reside in the Application Server are shown (other components are implicitly located there).
The system can bee seen as highly distributed, running in a number of physical locations:
- Vehicle Maintenance Centres
- Emergency Agency Headquarters
- Emergency Call Centres in which emergency calls are a answered
- Emergency Vehicles to which dispatches are sent
- Datacentre(s) where the bulk of the processing and all of the permanent storage occurs.
The communication between these systems is by means of some kind of network. For the connection between the datacentre and call centres, some kind of dedicated ATM or frame-relay based network can be expected with high bandwidth. For the remote reporting and vehicle maintenance centres, the only expected network connection would be via the public Internet. For the communication with vehicles, refer to the Elaborated Conceptual Architecture: the architecture specifically provides for the possibility that unusual or ad-hoc networks may need to be used (such as cellular or UHF packet radio).
The core functionality of the system will run on some kind of application server within the data centre (see Implementation Architecture for expanded detail). Running separately from this are each of the core databases for the system.
Additionally running separately are the routing and geolocation components which have an easily definable interface. The rationale for separating these out from the main application server is simply to provide scalability: these components may be computationally intensive and so physically splitting them allows their processor resources to be managed separately (ie run on a higher speed server and/or exist in a clustered or replicated environment).
Implementation Architecture
Description and Analysis
This Implementation Architecture has been developed in concert with the production of a 2nd elaboration of the Conceptual Architecture, the production of a detailed Execution Architecture and the production of an executable prototype. Analysis to date has focused on the large-level mechanics of the way the system is built. This includes some analysis as to the applicability of structural design-patterns. It does not, however, include a detailed design. Nor does it, as yet, propose a set of contracts for the interface port APIs.
This diagram identifies a number of infrastructure components:
- HTTP Server - The reporting and vehicle management user interfaces are supported in the system by means of a web interface running on the public Internet over the HTTPS protocol. An HTTP server is therefore necessary to provide the protocol and socket interface. In the executable prototype, the Jetty Java-based HTTP Server has been used.
- Freemarker Template Engine - The reporting and vehicle management user interfaces are supported in the system by means of a web interface. The interface between the the application server itself (see Execution Architecture Deployment View) and the Web Server is handled by a templating engine. In the executable prototype the Freemarker templating engine has been used.
- Geolocation Interface - A component that mediates between the Geolocator and the data available from the Geolocation Provider.
- Router Interface - A components that mediates and provides Routing of vehicles utilising the Miracle Routing System. Note the infrastructure component nature of this component reflects its separate identity on a separate server in the Execution Architecture Deployment View. The geolocation and routing components of the architecutre are described in detail in the Conceptual Architectural Analysis. Invoked and used by the Event Ticked via the Dispatch Operator Console, the component uses the Vehicles and Geographic Database to obtain locate the destination, an appropriate vehicle and the applicable route. Having done so, a transmission of the information over a network to the vehicle in question is required.
- Threaded Server - Strictly, this component forms a part of the core codebase/implementation set for the system. It is responsible for handling incoming connections and spawning Dispatchers to handle the communication with the remote user interfaces. However, its generalised and perfunctory functionality brings it closer in nature to the other infrastructure components and thus it is included as one.
- Databases - A container for data access to the actual backing data storage. A native system interface would be defined (Design Note: this may use a standard Object-Relational Mapping (ORM) system) to gain access to the persistent storage of the system.
Four user interfaces are also defined, as per the Conceptual Architecture:
- Operator Console - the main interface between the Dispatch Operator and the system. This will likely exist as a standard GUI form which enables the Operator to record the salient details as relayed by the caller (see Data Map).
- In-Vehicle Console - an identified deficiency of the initial conceptual architecture is the ability to accept or decline Dispatches. In addition to this, primary research and narratives reveal that a vehicle may itself be made unavailable by its crew for a period of time. This component resides in the emergency vehicle itself and facilitates user access to these functions in addition to reporting to the crew of the vehicle the details of the Dispatch.
- Vehicle Management Interface - the component for enabling the Adding or Removal of a vehicle to/from the system or to update a vehicle's status. Note the presence of this component in the Implementation Architecture as behind the web server. This represents its location in the build structure of the system, rather than in the execution sequence. This component will generate, with Freemarker the necessary interface front-end code rendered by a client web browser.
- Report Formatter - a broad range of reporting tasks are stipulated in the project brief. They are identified again as necessary in the narratives for government and for emergency service agencies' IT workers. They need to be collated into a single, intuitive presentation. That presentation interface is produced by the Report Formatter. Note the presence of this component in the Implementation Architecture as behind the web server. This represents its location in the build structure of the system, rather than in the execution sequence. This component will generate, with Freemarker the necessary interface front-end code rendered by a client web browser.
Implementation Architecture represents the use relationships between components. The components generally have to expose an interface to provide access to them remotely via a socket system. However, within the system itself, components operate at an internal level, the interface between which is not a concern for this architectural level. As such there exists the following components:
- Connection Dispatcher - must hold the requisite information about the socket connection and hand off the the Broker to provide access to the core parts of the system.
- Thread Broker - must provide an internal interface between raw sockets and the actual core processing components of the system. With multiple consoles connected to the system, the Broker has the ability to implement thread pooling or any sort of management facilities that enable the system to meet its non-functional requirements.
- Vehicle Manager - the functionality in-vehicle interacts directly with Vehicles. However, it receives status updates through the use of network communication from the Vehicle Console and uses the network to access the Vehicle Database to update its status.
- Event Ticket Manager - handles the creation and updating of Event Tickets. It will force a private interface system to each Event Ticket, which is necessary to prevent corruption to the ticket, particularly from multi-threaded access to this more important of components.
- Report Generator - as the reporting requirements of the system are quite broad, a rich interface for selecting and executing reports will be necessary. In turn, a two way API-call relationship is necessary between this component and the associated display formatter. In turn the reporting system will make use of the Vehicle and Case Log Databases by means of the system's database interface.
Example Sequence: New Ticket Receive
Demonstrating the implementation architecture is the sequence for creating a new ticket.
Operator console:
- Send a new ticket request package with the destination address and a list of vehicles requested
- Wait for response from the server.
- Display result on GUI.
Operator Thread:
- New ticket request package arrives at the operator thread.
- Dispatcher dispatches the package to the Ticket manager.
- Ticket manager save the ticket information to the Ticket DB and assign it with a next available ID
- Ticket manager calls Vehicle manager to find available vehicles to fulfil the request.
- Vehicle manager looks in the Vehicle DB, find available vehicles to fulfil the request and set their 'request' flags in the Vehicle DB and also supply them with the ticket ID (for each vehicle entry, there is a field reserved for this purpose).
- Vehicle manager sleeps for a short period (.
- Wakeup and check the status of all vehicles that it has requested prior to going to sleep for acknowledgements and returns the result to the Ticket manager.
- The Ticket manager updates the ticket in the Ticket DB and returns the result to the client console (operator console).
Architectural Patterns
The implementation architecture has been designed to support a number of architectural (or structural) design patterns. By utilising recognised patterns, the system is more maintainable and it is more demonstrably assessable: the patterns are peer-reviewed and industry accepted and tested.
- Blackboard Pattern - The Ticket contains the up-to-date, single-source repository of all information about a currently active dispatch. This prevents time- and CPU-costly database lookups or data cache lookups - all the requisite information is available to other application components from the one location.
- Model-View-Controller - The implementation structure of the system follows the execution structure of the system: components can be, generally, traced through three groups of identifiable as "User Presentation" (Views), "Processing" (Controllers) and "Data" (Views) layers.
- Broker - The above diagrams include component named, very imaginatively, Broker. Its purpose is to hide the implementation details of multi-threading from the remainder of the system and merely provide the correct thread and dispatcher instance to the system. In that way it abstracts multiple references into a single one via a standard interface.
Reflections
Andrew
David
The point to make from the outset is that this was a large project. It was a project that was large in the size of the team (relatively speaking anyway), large in the time frame to produce the necessary artefacts, large in the scale of those artefacts and large in terms of the problem that was being worked on. So it would then be of little surprise that the management overhead of this project was quite a lot larger than in the past, and the project quite a challenge to pull together.
Milestone 1 - This stage of the project could be considered one giant exercise in putting the cart before the horse. When the project started, didn’t have a lot of time to produce the Milestone 1 artefacts. The situation was hampered further by the fact the necessary information to complete Milestone 1 was contained in lectures that were delivered right up until the week before the milestone was due.
The result of this was a decision that I considered necessary at the time (and still do) that we could, as a group, focus on just one area of architecture – requirements, conceptual, execution, implementation – per week until the milestone fell due. So, five of the six of us would meet on Wednesdays and we’d discuss the area of focus for that week. Then in class on Thursdays we’d all discuss it again, having been given another week’s worth of lecture material all centrally relevant to the milestone. Whilst I think the group were generally accepting of this way of working, there was one, err, unproductive week where the lack of full understanding and the brief level of analysis resulted in conflict and confusion.
The above brings out a point from our group dynamic: one member of the group worked fulltime and thus we were unable to make a meeting time during the week when everyone could attend. This was unfortunate and it made team communication difficult. I wouldn’t want to have to run a group in that way again.
In fact, ideally, for a group of the size we had, one person would effectively just be a manager. Two others would then be group managers who’d effectively head a small sub-group. This group of 3 alone would then need to meet weekly outside of class time. The reason this could never work for a university exercise like this is that we’re all fundamentally equally and are assessed in the same way – that is to say it would be the quite legitimate concern of the ‘manager’ that he/she would be penalised for having little concrete involvement in producing the team artefacts, and those not involved in the management structure would be penalised for poor managerial decision-making in which they have no say. So the university method is necessarily that of Athenian democracy whereby everyone gets a go, gets graded equally, and the group leader is a mere coordinator whose job sits on top of his requirements to be a group member.
Anyway, philosophy aside, despite the less than ideal circumstances in which Milestone 1 was put together, and despite the lack of support materials, it came together in the end without vast drama.
The initial prototype was effectively spun off to the group member who we couldn’t meet with as often. He had the task of producing some sort of prototype that reflected the problem description and the preliminary architecture documents we had thus-far produced (which excluded an implementation architecture – the implementation architecture is primarily a reactive document). He did a very good job. I think it demonstrates that the nucleus of any project really needs to be an individual or close-group, high-contact brainstormed event. The Milestone 1 demonstration worked really well. However it may also have sewn the seeds of the problems faced in Milestone 2.
Milestone 2 - For Milestone 2 I had visions of team roles divided between documentation and development, with a coordinator for each and all. But alas the best laid plans fail. The vagaries of work commitments meant work on this milestone was pretty late in starting. So we ended up with the Athenian democracy again!
The scale of the prototype we needed to produce was quite broad and challenging. It called for the integration of multi-threaded socket communications, a web-based interface system using some sort of templating engine and the integration of a database. We were able to divide up the work into disparate chunks amongst everybody without too much trouble. The problem was the integration – the system was too large to integrate in the amount of time available. Thus, in the end, we largely had a system of distinct chunks that notionally but not actually linked up. That was a personal disappointment to me.
So, I would think that for next time there needs to be a more organic growth to the prototype being produced, rather than the last minute bolt-on job attempted. The fundamental issue though is, given the limits of our communication, to start earlier. I don’t quite know how it is possible to reconcile “start earlier” with “we couldn’t start because we couldn’t all meet to settle on a method of progress” apart from appointing an autocratic leader, who, for the reasons outlined above, wouldn’t be able to successfully do anything anyway.
The documentation for Milestone 2 was probably easier though – a matter of expanding, refining, reflecting the prototype and incorporating the feedback received to produce the final artefact. It was merely a matter of identifying, as a group, what had to be editing or expanded and allocating the right people to do it.
And so there we have it. We completed the project in the end, and reasonably successfully.
Peter
The following will delve into my experiences in Software Architecture this semester in group F1: HELP in the process of developing the Architecture for an Emergency Response System. It will describe what and how I have learnt while participating in the development of the Architecture and Prototypes. It will be broken into the following sections: design, teamwork and major decision points during the project development.
The process of the design of the architecture of the system was fairly painful at times with most of the problems resulting from friction within the team. The design in my opinion developed well over time. We used an iterative approach to the design constantly updating and improving sections that we had previously done. This iterative approach wasn’t planned per se, but was rather needed when we moved to other stages of the project and realized we needed to add things to previous parts. Although I’ve been told that this is generally how this kind of process is done. However this is where a lot of friction began to show. We were divided as a team as to whether to remain on the initial conceptual architecture and get it right, or to move onto the execution architecture and come back to the conceptual to fix it up with changes we may have found while developing the execution architecture. Arguing over this wasted an entire tutorial much to my dismay. What I have learned from this is that it is better to move onto something new when you become stuck in a situation like the one mentioned above. Then when that is done you will have a better understanding of the project as a whole and will be able to come back to the previous problem and solve it more easily.
The design artifacts being produced took me a little time to understand properly. This affected my performance in the group as I was not able to fully contribute to discussions as most of the time it was me trying to understand what all the different boxes meant. However once I had a firm grasp on the topics I was able to contribute better and waste less of the group’s time explaining things to me. I think having the group explain it to me in a more hands on manner helped me to understand the content better than when it was explained in the lecture.
During the design we held meetings every week, however due to commitments not everyone was able to make it to them. This detrimentally affected the project. Without everyone present we were unable to discuss certain parts of the project, especially those concerned with the people that were not present. This made for slower progress on some parts of the project, mostly the Executable Prototype. It also made things more difficult to progress and move onto other areas that required some input from a previous design. The weekly meetings were helpful in the beginning as the work being done was able to be done without the people missing however towards the end of the project and the creation of the executable prototype the meetings became less and less helpful. The meetings towards the end also became less and less productive to a point where nothing could be done without the people missing. This did not work well for us, we should have had meetings at a time when everyone was available, or spread the work load out more so that the executable prototype did not rely mostly on one person.
The people in the team all seemed to be hard workers; they would all put in the effort to get the job done. This made the work easier to dish out to everyone without suffering from complaints about overwork or worse that the work does not get done by the allotted time. We did however have some problems with communication amongst the team. Some people where hard to contact which made the progress slow going at times as mentioned previously. To improve the problems we had we would need to improve our communications methods.
To sum up, the group F1 worked well together. We had some minor problems and struggles which are to be expected in any group work. These problems would most likely be eliminated or at least managed to minimize the impact over time, however the time period we had was too short to fully see this happening.
Khai Lim (Raymond)
Van
This is the reflection of my experience in the subject Software Architecture. In it I detail what I have learn and how, during the execution of the two milestones. In particular, I focus on group work and the Executable Prototype. I mainly focus on what did not work, because you can learn from more them, and how what didn’t work impacted on the project?
During the course of the semester due to my inexperience in-group work I found it hard to communicate with other team member while under a heavy workload. But I realise that communication is essential for group work, communication is probably the key to group work. At the start of semester I wasn’t to good at it, but I’ve being trying to put more effort into it. No matter what the stress or workload levels, I made an effort to listen to the person and response or ask them questions in an assertive and respectful manner. Why go through all this trouble? I found the team dynamics and the assignment in terms of quality really benefited. I found it was worth putting in the hard work now by communicating effectively and it will be easier later on. Because the group will have a good Idea of what is going on, this will help if you need to ask them a question or they need to ask you a question. The wrong task will less likely to be done and the team as a whole will work more effectively and efficiently together.
The other major problem I found was in trying to understand exactly what to do in each milestone especially with the prototype. We as a group ran out of time for the prototype demonstration, we didn’t get to finish everything we wanted to do. This I believe was due to us having to big of a scope for the prototype. As one team member said “We Bit of more then we could chew”. The factors that influence our scope being to big were our own estimating abilities, on what could be done in a certain time frame. Also the fact that this being a newly combined subject we found the assignment sheet weren’t specific enough, so we spend a lot of time trying to figure out exactly what had to be done. This could also be due to the fact that the scope of the subject is so large in that it covers so many different aspect of software.
In the future what I would do differently would be to ask more questions, on what exactly to do. Then when I understood what to do, then plan ahead and allocate more time to learn thing I didn’t know for an assignment. I would try to use my experience from this semester to have a better understanding of what could reasonably done is certain amount of time. With group work I will also use my experience from this subject to continue to communicate and work with my teammates and try to further learn and improve my group working skills.
References
Robert Garran Offices, Triple Zero (000) Australia's Emergency Call Service , Australian Disaster Information Network, last viewed 11 September 2008, [1]
Australian Communications and Media Authority (ACMA), Calling the Emergency Call Service from a Mobile Phone: Frequently Asked Questions, last viewed 11 September 2008, [2]
Australian Communications and Media Authority (ACMA), Emergency Call Services: What is ACMA’s role?, last viewed 11 September 2008, [3]
Australian Communications and Media Authority (ACMA), Emergency Call Services: Frequently Asked Questions, last viewed 11 September 2008, [4]
Australian Communications and Media Authority (ACMA), Emergency Call Service Advisory Committee, last viewed 11 September 2008, [5]
Ambulance Service of New South Wales, Ambulance Operations -> Operations Centres, Last updated 11 Sep 2007, [6]
NSW Fire Brigades, Call Triple Zero (000) to report emergencies, Last updated Monday 20th August 2007, [7]
The NSW Police Force, When do I call Triple Zero (000)?, Page Last updated: 1st Sep 2008, [8]
The State of Queensland Department of Emergency Services, Call '000' to report an emergency, last viewed 11 September 2008, [9]
Telstra, Integrated Public Number Database, last viewed 11 September 2008, [10]
