For the past six weeks I’ve been working at SEED software, working one day a week in a team of four to develop an asset coverage map. Using the Scrum development methodology, we’ve just finished our second sprint and started our third. Here’s where we’re at:
What the image above shows is the parts of the Middlesbrough area that can and can’t be reached by fire station assets within 15 minutes. Green areas are accessible within the government-specified time, and red areas are not. Don’t panic though: the above image is generated using limited test data. More areas should become green when we get our hands on a real snapshot of fire brigade data.
The process of generating this map image is rather complex; we’re building on two years worth of previous work. The base project that we started with was a routing system that selects the fire brigade assets closest to an incident and suggests to a command and control centre officer that they should be routed to the incident. It does this by using an A* algorithm on each asset to find the quickest route to the incident, and then it compares the travel times to see which asset is closest.
The most useful part of the routing system for us was its ability to load an entire database over a network into RAM. This allowed us to write a form of Dijkstra’s algorithm that, given an asset location, searches through a linked list of route nodes until the travel time of the asset has exceeded 15 minutes. This gives us a list of every reachable route node, the locations of which we can then render onto a map.
There’s a lot more to it. Rendering the map is a complicated process that involves a grid system, colour weighting, and a bit of Minesweeper tech; and I haven’t even mentioned that we’ll be sending the data over a network and rendering the map on a website with the use of OpenLayers.
Disregarding technical stuff, the project requires a great deal of oversight and management. As I mentioned previously we’ve been following the Scrum development methodology, and so far it’s working brilliantly. Using Microsoft Team Foundation Server we can keep track of our progress from wherever we are, but we’ve also dedicated our whiteboard to the task:
It always surprises me how much I enjoy the project management aspect when working in teams. Getting an overview from each team member and being able to see the big picture is very satisfying. It also aids the decision making process, especially in the event of the customer changing the project requirements. Something that happens very frequently in our line of work.
Yesterday we presented the results of our second sprint to our customers in the form of a demo. The customers were able to play with the rendered map in the OpenLayers interface on a simple webpage, and they were extremely pleased with what they saw. So much, in fact, that they felt it would be ready to demo to the Cleveland Fire Brigade service after Christmas, once we’ve spruced it up for such a purpose.
None of this would have been possible without the fantastic team I’ve been working with. Knowing that we all put our best effort in each and every day is immensely gratifying, and that knowledge keeps me going despite the challenges that lay ahead of us. So cheers guys. 😉