SVWebsite

Recently Spatial Vision's Application Services Division have been busy developing ICE (Integrated Catch & Effort) system for Fisheries Victoria. A large part of the ICE application revolves around operators entering data from paper forms which record the fish caught by each commercial fisher on a trip. This enables Fisheries Victoria to monitor fish stocks. Getting the data entry part of the application right was absolutely essential. Even small insufficiencies would add up, leading to hours wasted and endless frustration.

To ensure that the data entry part of the application was just right, we decided to do some on site development. Doing software development at the customers site, involves bringing a partially complete version of the software and walking the customer through it. The software can then be tweaked and changed. New builds are immediately shown to the customer for feedback. This approach results in software that is tailored to the customer – better meeting their needs and suiting their work practices. In addition it reduces risk by exposing the software early and allowing the customer to make sure their requirements are met.

Before our trip on site, we first had to create an initial version of the data entry module. The software needed to be complete enough to be used by the customer, yet still allow for any suggested changes.

Getting the right balance between complete features, polish and flexibility is hard. On one hand there is no point arriving with a 100% complete piece of software, and just telling the customer “Here, it's done, this is what it looks like” – the whole idea is to allow feedback and modification while the software is still being developed.

On the other hand it would be a waste of time going on site, unless the software is stable enough of to be put in front of the client, and it contains enough features to be useful. We managed this tradeoff by concentrating on implementing a few key features, which would allow some of the more critical workflows to be tested. In some cases a feature was mocked up, or a even left, out, pending discussion with the customer.

The team chosen to go on site was Kelly Wason; our QA manager, Hiroki Gota; our technical lead, and I; the development manager. On the day we loaded our laptops into a car, and headed out to the Fisheries Victoria office, at Queencliff. Once there we quickly setup and introduced ourself to the data entry team. Time was spent with each staff member, walking them through the software and having them to use it to enter a few forms. Seeing the first data being entered into the new system was an exciting moment for everybody.

We had brought a full development environment with us, so we were able to easily modify the software. This meant some of their suggestions could be quickly implemented. For example we found out right away that they really missed a feature from their current software: “copy from above cell”. After ten minutes of coding we were able to show them a working implementation and see the difference it made to their data entry times. In other cases where a feature was to complex for on site development, we were able to mock it up, showing them how it would work once completed.

By the end of the day we had made many improvements to the software.

We also had a long list of features and modifications to follow up on in the office. Overall the data entry team was very pleased with the software and excited to be able to try it out. Being able to influence its development and ensure it was tailored to their needs also meant a lot to them. By doing development on site, we were able to reduce some of the key risks to the project. The data entry team were happy with the software and we now knew it would work for them.

Luke Sleeman
These comments are my opinion and do not necessarily represent Spatial Vision's opinions.

This e-mail address is being protected from spambots. You need JavaScript enabled to view it