Last month, Tony Grimes, of Broker Direct plc and lately a student at IAP Education Partner Lincoln University, gave us some background on his cover note generating software. Here he describes his approach to it.
The project having been commissioned, the next step was to approach the University to gain approval for it. Chris Coulson agreed to supervise the project and met me regularly to discuss its development.
The benefits of this system were to be:
- There would be no requirement to issue multiple Cover Note books, one per product. The system would print relevant Cover Notes appropriate to the Broker Direct Product.
- The efficiency of Audit procedures would vastly improve, as every cover note issued by all brokers could be audited by automated reports periodically.
- Broker would not be able to ‘backdate’ cover notes.
- Cover notes blanks cannot ‘run out’, leaving brokers unable to issue. The broker can call for authorisation every 25 issues to ‘refill’ their ‘books’.
The system would consist of two main parts:
- The Broker Application
- The Insurance Company Application
The basic features of the application were envisaged as being:
- User friendly, simple Graphical User Interface (GUI) for the input of cover note information.
- Print Cover Note functionality.
- Storage capability for cover note data.
- A method of transferring the cover note data to the Insurance Company.
The Insurance Company application would be installed at Broker Direct’s office in Bolton. The basic features of the application were envisaged as being:
- Capability to mimic broker application, so that cover notes could be issued at Broker Direct.
- Functionality to allow cover note data sent by brokers to be received and assimilated into one storage facility.
Terry Stanley (the Broker Direct director who had commissioned the project) was keen to see the proposed system save printing costs but not at the expense of reduced security. In fact, he was keen to tighten it. Terry and I discussed the security issues surrounding the system informally before any serious development work had taken place and were both convinced that we could implement a system that was more secure than the existing practice without any compromise.
Data transport also required careful consideration. All cover note data had to be transported, one way or the other, to Broker Direct for auditing and storage. With a user base of 1200 brokers, this process had to be as simple as possible while still retaining a high level of security.
The system had to cope with multiple insurers at the initial dispatch and be capable of simple updating to reflect new contracts with insurance companies.
Broker Direct commissioned the Cover Note Book system as a working project to be implemented by January 2004.
The next stage of development was to carry out research into existing user expertise and available technology. For user analysis, I visited several insurance brokers and talked informally about their skills with PCs, email and using software. It became apparent that the average user was beginner to intermediate, which meant that the data transport mechanism in particular had to be simple.
I surveyed 50 brokers on their PC specifications, Internet and email access. 98% of offices had an accessible PC and 90% of offices had at least one PC with email access. Email was the preferred transport mechanism for the data, so this was good news.
The specification was drawn up based on the IEEE Guide to Software Requirements Specifications according to IEEE Standard 830-1984. It consisted mainly of data types and their relationships.
I was then faced a crucial decision: how should the system be structured? Would it be more practical to develop two systems, one for the collated data to reside at Broker Direct and another to distribute to the 1200 brokers? Or would it be better to develop one system that integrated all the required functionality for both environments without affecting the complexity for the user?
The master system that was to reside at Broker Direct would require most of the functionality of the broker’s satellite system, with an additional reporting facility and slightly different functionality to issue a cover note.
It therefore seemed logical to develop one system that would send the user down different functional paths depending on whether the user was a broker or a Broker Direct staff member. This meant that I was only designing one, relatively complex, system as opposed to two less complex systems. I definitely did not want the user to be allowed to choose the path. I therefore decided that I would dictate it by having a Welcome screen that included two ‘Enter’ buttons, one of which would be removed from the display depending on the version.
I had to decide upon a development environment. Broker Direct had a spare license for VB6 and, although I would have preferred to gain VB.Net experience, it seemed to be more than capable of the job.
I built a prototype using MS Access 2000 in about four weeks and was so pleased with it that I considered developing it further into a Beta version, as MS Access allows the developer to remove most of the toolbars that distinguish the application as an Access database. The main problem with this was the conflict with Access versions extant on the client PCs. I was using Access 2000 and distributing with the Access runtime, available through MS Office Premium. This worked well so long as the client machine did not have a different version of Access. If the client had MS Access 97 installed, the runtime associates all .mdb files with the Access 2000 runtime, thus disabling all Access 97 databases. So it wouldn’t be possible to distribute the Access version of the system.
I reverted to VB6 and used my prototype MS Access as the data storage mechanism. As long as the appropriate dll files are distributed to the client, MS Access can be used by VB to access data without using any of the Access functionality.
Next month, Tony will complete his description of his implementation.
[Interesting project or development? Let us know at eo@iap.org.uk!]
