Talk:Team Wunuontoo: ERDS

From SoftwarePractice.org

Just to note I've been working mostly off the previous Team 8 layout, as well as the Software Engineering SRS. I do plan to add content at some point, I swear!

James [10-08, 7pm]

Added meeting minutes and team charter to the plan page

Boris 01:24, 18 August 2008 (GMT)

Added a section for linking log books into the plan page. Also we definatly need to work on the scope definition, as we have conflicts between the scope and some of the usage narratives, as well as scope statements without narratives.

Boris 06:03, 21 August 2008 (GMT)

Paramedic Chip - Narrative 2 Noticed it implies that ERDS tracks the resources and capabilities of each unit, and whether they are able to respond to calls. This would mean that the vehicle db (Which we are missing on the conceptual arch!) needs to communicate to the current case db, and on a case by case basis generate a list of vehicles possible to respond. The list would then need to be forwarded to the route finder.

I think that would be impractical as it would require additional sensor equipment and information to be sent dynamically (i.e. for supplies).

However perhaps this is a good solution:

1. Add a vehicle list (db)
2. Add a component between the vehicle positions & vehicle list, that is also linked to current case, acts as a filter
3. The filter outputs a possible list to the magic system
4. The magic system still outputs a valid list back to the current case, and still inputs position.
5. There needs to be a link between the vehicle list and the current case db for status exchange.

Boris 05:10, 23 August 2008 (GMT)

1. Change anything with DB in the name to "Storage"
2. Edited the above diagram, will create the proper version of it tonight.

Boris 05:46, 28 August 2008 (GMT)

Food for Thought

1. scope --> limits of the system, what services, geographic areas
2. interface --> consider with 000 & services , e.g. fleet management
3. Redirection or priorities?
4. Stress test the systems? Limitations, performance wise, what circumstance
5. Consider criticality, database updates during use

How do We Capture Local Knowledge

One of the major questions asked by Tom was "How do we capture local knowledge", i.e. specifics that locals would know about the area and the road system, but that wouldn't be captured by simple Co-ordinates or maps. This is particularly relevant in more rural areas. As callers, operators and crews will all operate with a particular local knowledge, they will either have to ensure they talk only in terms of specifics (i.e. without reference to other things), or that only locals talk with each other.

One method would be to compartmentalise the system, i.e. have cells of control similar to that for mobile coverage. This way the operators can focus on knowing their area well, as well as the crews, as well as reducing the load on any one system. It would however require some method of overall linking and control between systems, as well as problems for handoff's etc.

Another method would be to assume that the point-to-point mapper gives the most efficient route in terms of street names etc., like google maps or whereis.com. However this still might not have a great local knowledge, but at least operators and crews would be able to speak the same "language".

Stress testing the system

There are a few interesting use cases that I would like to write, or add to current use cases. These are to show what will happen in cases when the maximum capacity is reached. These might be good to link into the quality narratives.

APEC or WYD -> Large crowds, huge amounts of foot units and lots of areas that aren't accessible to the normal vehicle units.

This would mean either that foot units need to be tracked normally or an alternative management system developed.

New Years Eve -> Like APEC and WYD; Large crowds and huge amount of foot units gathering in different areas. Unfortunately alcohol is also involve in event such as this one, and violence usually occurs if not properly monitored. The Police, Ambulance and Fire Department will have to be ready at all times in case any incident happens.

Sporting Events -> Over the years we witness a rise of violent activities in sporting events, especially in sporting events such as Rugby and Soccer. It mainly occurs when passionate fans of a sporting event is watching their team playing against an old rival. Although sporting arenas have their security contractors trying to keep the peace among the fans; Police, Ambulance and sometimes Fire Emergency departments will have to be on stand by in case anything happens.

Friday Nights -> Particulary when there are large amounts of police action required, assigning priority to incidents will be hard and stressful. Also there will be a large amount of action required by the Ambulance services. However this means that operators who aren't local will be have to take calls, and thus the local knowledge element appears again.

Criticality

Obviously reliability is important, with the worst possible action being a lost call. However when there is continously updating of the database both for emergencies and the fleet/unit management system, this is a danger that must be considered.

Scope

• Do we need to account for foot units, horse units, helicopters, boats?

Food for thought

I've posted here a new concept diagram. I'm posting this here to help with the meeting tomorrow. I don't intend for it to replace our current diagram, rather help refine it.