bbus driver training & risk database matt jagger bsc … insurance department. it then ... bbus...

The candidate confirms that the work submitted is their own and the appropriate credit has

been given where reference has been made to the work of others.

I understand that failure to attribute material which is obtained from another source may

be considered as plagiarism.

(Signature of student) _______________________________

BBUS Driver Training & Risk

Database

Matt Jagger

BSc (Hons) Information Systems

2007/2008

BBUS Driver Training & Risk Database Matthew Jagger

i

Summary

This project discusses the potential benefits of a database application for Balfour Beatty

Utility Solutions (BBUS). BBUS are a provider of Gas, Water, Electricity and Sewage Utility services.

It follows the development of a solution for the company, drawing upon the background

research and the analysis of different methods, all hoping to improve their business efficiency within

the Insurance department. It then follows through the implementation from a set of designs made

and then tests the system to make sure it meets its requirements. The final section goes through a

thorough evaluation of the success of the system and the project as a whole.


ii

Acknowledgements

I really need to thank BBUS for all their support throughout this project. I really appreciate

the time provided by members of IT and Insurance, particularly Dave Washbourne who has guided

me through the processes numerous times. His knowledge of the existing solution was paramount in

getting the most out of the solution.

My thanks also go to Haiko, my supervisor, for keeping calm with me, and guiding me in the

right direction at all times. He was always there when I needed an answer to something and made

the goals very clear.

Finally, I really appreciate all the help and time that my friends and family have given me,

and in putting up with me being so stressed when the end was in sight. Thanks especially go to my

Dad, for helping me keep a professional attitude towards my work and particularly, my girlfriend

Adrienne, for keeping me on track and helping me focus when I thought this was never going to be

finished.


iii

Contents

1. Introduction 1

1.1 The Business 1

1.2 Business Issues 1

1.3 Problem Definition 2

1.4 Aim 3

1.5 Objectives, Minimum Requirements and Deliverables 4

1.6 Project Schedule 6

2. Background Research 7

2.1 Technologies 7

2.2 Interviewing 9

2.3 Methodologies 10

2.4 Relevance to Degree 10

3. Design 12

3.1 Preparation of the Solution 12

3.2 Existing Solutions 13

3.3 Database Design 13

3.4 Security 16

3.5 Presentation 17

3.6 Normalisation 17

3.7 Data Integrity 18

4. Implementation 19

4.1 Platform 19

4.2 Implemented Items 20

4.3 Importing Existing Data from Excel 21

4.4 Implementation Issues 23

5. Testing 24

5.1 Developer Testing 24

5.2 Quality Assurance Testing 24

5.3 User Acceptance Testing 25

6. Evaluation 26


iv

6.1 Methodology Evaluation 26

6.2 Design and Requirements Evaluation 27

6.3 Project Evaluation 28

6.4 Future Enhancements 28

6.5 Conclusion 29

7. Bibliography 30

8. Appendix 31

8.1 Reflecting upon the Project Experience 31

8.2 Business Requirement Definitions (created with End Users) 34

8.3 Personal Evaluations – Ian Hewitt 36

Dave Washbourne 36

8.4 Email Transcripts (Requirements gathering and understating of the department

processes) 38

8.5 The Existing Solution 47

8.6 SQL Database Layout 48

8.7 User Guide 49


1

1 Introduction

1.1 The Business

Balfour Beatty Utility Solutions (BBUS) is a £650M p.a. Operating Company, part of the

Balfour Beatty Construction Group whose 2006/2007 turnover is in excess of £7.5Bn.

BBUS provide services to the Gas, Water, Electricity and Sewage Utility companies such as

National Grid Transco, Yorkshire Water, United Utilities and South West Water. Their Operations

cover the whole of the United Kingdom and are serviced by a number of Regional Offices, Yards and

Depots.

Services form three categories

• Reactive – such as water pipe bursts

• Planned Reactive – such as water or gas meter installation

• Planned – such as the construction of major electricity transmission or gas pipelines

The people who deliver these services are grouped into Gangs, Site Managers, Project

Leaders, Construction Managers and Regional or Contract Managers together with the supporting

teams such as Logistics, Plant, Quality Control, Health and Safety.

BBUS has a workforce in excess of 7000 people and operates a vehicle fleet of over 5000

vehicles ranging from Vans, Transit Vans, Lorries, HGV’s and Specialist Vehicles such as ‘Jet-Vac’s.

The Insurance premium for BBUS is approximately £3M p.a. which is a significant amount.

The premium, compared with similar organisations, is perceived to be low due to the extensive

training, support and education given to the fleet drivers.

1.2 Business Issues

BBUS are looking to introduce a database that helps them identify driver risk, take proactive

action and monitor driver behaviour.

This will have a number of direct benefits

• Keep the premiums low or even reduce them

• Reduce time lost through accident processing, driver training


2

• Improve the company brand image by making sure BBUS drivers are careful and courteous;

all vehicles carry the company information and can be easily reported to the Customer

Service hotline

• Reduce training costs by focusing on those individuals that need training rather than giving

everyone a reduced level of training

• Reduce Repair costs since, like domestic policies, there is an excess that BBUS must pay for

every collision

1.3 Problem Definition

At the moment the information is stored in a massive Excel spreadsheet. A number of issues

are evident

• The spreadsheet has doubled in size since BBUS merged with another company

• The file can only be maintained by one person at a time

• The file can only be maintained / viewed by PC’s connected to the local network

Although there are potential solutions to these issues BBUS feel that the development of a

database will be more appropriate.

During my holiday work with them it was discussed as a potential project for my third year

and I have gained the backing of a number of key stakeholders in BBUS

• Head of Support Services

• Head of Insurance

• Application Support and Development Manager

After an initial scoping meeting it became clear that, by linking together other systems a

significant improvement can be obtained compared with the Excel version.

The other applications used are

• Oracle e-business suite used to maintain HR information

• Snowdrop Training Management

• Driving Licence database

• Oracle Plant database


3

• Customer Service ‘How’s my driving’ database

Once these other systems began to be considered, thoughts within the Insurance team

moved towards a new ‘Formula’ for calculating Risk and identifying who needs to attend a course.

Whilst they have no idea what the formula needs to be the Stakeholders expect me to provide a

single view of all this information about each driver. Using the opinions and experience of the

Stakeholders together with an iterative process of calculation and evaluation I expect to be able to

define a new mechanism for Risk Classification.

The BBUS IT department is relatively small and doesn’t really use methodologies such as

Prince2 to manage its projects however it does follow an ITIL based process to approve development

work. Although I am going to do all the work myself I will need to follow the following process

• Work Request – get the Head of IT to approve the project

• Business Requirements Definition – Change Advisory Board will review functionality scope

and benefits statement

• Functional Specification – comprehensive design and release to development

• Development – following BBUS IT Standards

• User Acceptance Testing – unit, end-to-end and user testing

• Software Release Ready – release documentation and hand over to Release Management

1.4 Aim

• To produce a solution to the existing Microsoft Excel spreadsheet, that for the Insurance

Department, will

o help them identify driver risk,

o take proactive action, and

o monitor driver behaviour.

It is felt that the move to a database / Intranet platform will, not only meet the immediate

requirements of providing a replacement for the Excel spreadsheet but it will also link together

other exiting databases to provide a complete view on driver skills and behaviours. Peace of mind

will be brought to the company, knowing that the data is being maintained by the IT department.


4

1.5 Objectives, Minimum Requirements and Deliverables

Objectives

• A database system must be created. The company currently develops most its applications

using Enterprise Manager (for SQL) and .net. With this software already in place, and the

company having no wish to purchase new developing software, the database will be

constructed in the same manner.

• I also would like to implement the intranet platform which will enable driver trainers to edit

the database in a simple manner, often from the road side. This will be built into the

company’s current Intranet site.

• As a final task, creating the Business Objects environment will bring great value to the users

of the system. With Business Objects already occupying in a large number of other

departments as well, the standard can be carried across to the trainers allowing them to

effectively create their own reports on drivers, trends of accidents etc.

Minimum Requirements

The system should be able to hold all the details of drivers, and monitor different factors to

help reduce high risk drivers going unnoticed. It will be expected to contain in excess of 5000 entries.

This should include being able to record incident activity and training records. From here it

will be able to identify the risk of each driver.

It is essential that user guide documentation is also produced, to make sure that final

product is used as effectively as possible.

Deliverables

1. A fully functional database to hold:

• Driver details

• Incident Data

• Training Records

2. User Guide documentation.

1.6 Project Schedule


5

The schedule shown on is the 1st

version of the plan. The ‘build’ time has been given 40 days to

complete – this is due to first semester exams, including revision time, and so gives me more time

than I should actually need.


6


7

2 Background Research

2.1 Technologies

Database Management Systems (DBMS)

A DBMS provides a secure storage unit for data that guarantees data integrity, relational

integrity (the relations, or tables are related properly and new data goes where it's supposed to),

functional restrictions by role, fast data retrieval.

The DBMS also provides security features that protect against unauthorised users trying to

gain access to confidential database information; and prevent data loss in case of a system crash.

Depending on the settings, users are allowed access to either all, or specific database sub-schemas,

through the use of passwords. For example, while a database may contain detailed customer

information, certain users may only be allowed access to customer names and addresses, while

others may be able to view payment specifications. Access and change logs can be programmed to

add even more security to a database, recording the date, time and details of any user making any

alteration to the database. Furthermore, the DBMS is also responsible for the database’s integrity,

ensuring that no two users are able to update the same record at the same time, as well as

preventing duplicate entries, such as two employees being given the same employee number.

A well designed database will only slightly increase in size data volume increase, compared

to a spreadsheet with exactly the same information. This is the same for time taken to produce

reports. The efficiency of the relational structure and a dedicated data engine give databases the

advantage. The problems of being too big and too slow can be further exaggerated when networked

users access a spreadsheet, meaning only a single user can edit the data at a time.

SQL Management Studio 2005

Microsoft SQL Server Management Studio, new in Microsoft SQL Server 2005, is an

integrated environment for accessing, configuring, managing, administering, and developing all

components of SQL Server. SQL Server Management Studio combines a broad group of graphical

tools with a number of rich script editors to provide access to SQL Server to developers and

administrators of all skill levels.


8

SQL Server Management Studio combines the features of Enterprise Manager, Query

Analyzer, and Analysis Manager, included in previous releases of SQL Server, into a single

environment. In addition, SQL Server Management Studio works with all components of SQL Server

such as Reporting Services, Integration Services, SQL Server Compact Edition, and Notification

Services. Developers get a familiar experience, and database administrators get a single

comprehensive utility that combines easy-to-use graphical tools with rich scripting capabilities.

MY SQL

MY SQL is a very popular open source, relational DBMS from MySQL AB, that runs under

various versions of Unix, Windows and Mac. It is Widely used for Web applications and embedded

applications, and is available for free from MySQL AB. More than 100 million copies of the software

have been downloaded worldwide. (Schneider 2005)

MySQL is used in a wide range of applications, including data warehousing, e-commerce,

Web databases, logging applications and distributed applications. It is also increasingly embedded in

third-party software and other technologies. According to MySQL AB, their flagship product has over

six million active MySQL installations worldwide. Customers include Cisco, Dun & Bradstreet, Google,

NASA, Lufthansa, Hyperion, and Suzuki. (TechWeb 2008)

The fact that the software is free under license, poses a strong case for the use of this

application for my project. If the development were not for an end user, I would inevitable use this

instead of the rival Microsoft product. There appears to be a lot more documentation about it on the

internet, which would help me a lot more come development time (due to the nature of it being

open source). A lot of the help on the Internet for the Microsoft products requires registration.

Microsoft .NET Framework

The Microsoft .NET Framework is a software component included with the Microsoft

Windows OS. It provides a large section of pre-coded solutions to common software development

requirements, and manages the execution of programs written specifically for the framework.

Microsoft (No 2310) states that the pre-coded solutions that form the framework's Base

Class Library cover a large range of programming needs in areas including: user interface, data

access, database connectivity, cryptography, and web application development. The class library is

meant to be used in a combination with the developers own code to produce applications.

Visual Studio


9

Visual Studio is a suite of programming languages and development tools from Microsoft. It

is Microsoft's flagship language product that includes Visual Basic, Visual C++, Visual FoxPro, Visual

J++ and Visual InterDev.

Business Objects

Business Objects is a French enterprise software company, specialising in business

intelligence. BBUS use Business Objects in a wide variety of departments and it enables users to

create detailed and complex reports from various databases of information.

The flagship product is BusinessObjecs XI, with components that provide performance

management, planning, reporting, query and analysis, and enterprise information management. It

also offers consulting and education services to help customers deploy their business intelligence

projects. (Sutherland 2007)

Using this as an extension to a DBMS, would enable reporting to be produced by end users

in a much simpler fashion. The Business Objects software runs straight through a web browser, and

doesn’t even require the client’s machine to have access to the Insurance and & Risk software itself,

meaning it is even more portable. Reports can be made anywhere in the world, and authentication is

by username and password.

2.2 Interviewing

With BBUS being such a large business, and a lot of money at stake if the project goes

wrong, I feel that the analysis stage should be even more thorough than normal. With external

people to impress, and the chance of a job there in the future, I need to fully understand what is

required.

• “Interviewing is one of the most widely used fact-finding methods. Success with this method

involves careful planning, proper conduct of the interviews themselves and, finally, accurate

recording of the interview findings.“

• Planning – “clear objectives need to be set to identify what needs to be achieved at the end

of the interviewing process”

• Conduct – “The interviewer must establish a control framework for the interview. This will

include the use of summarising to check the points being made and appropriate verbal and

non-verbal signals to assist the flow of the interview.”


10

Recording – “...the interviewer will need to make notes to record the findings. It may also be useful

to draw diagrams to illustrate the processes being discussed. Some interviewers like to use a tape

recorder...”

(Bocij P, et al (2003)

With this in mind, I spent a lot of time preparing the things I was going to ask the head of

support Services, Brent Mitchell. A transcript of this can be found in the report appendix.

2.3 Methodologies

Numerous methodologies exist to suit the different requirements of the people requiring

them. More rigid varieties, (i.e. the Waterfall) allow little flexibility in changes and can mean goals

are not met. Once designs and requirements have been chosen, it is often that the project can

“snowball” out of control, with the project continuing down its “failing course of action”.

By introducing several “iterations” of a piece of development, users can evaluate and make

changes to models or work. Flaws can be caught early on, with later iterations revolving around build

and deployment. Methods like the Rational Unified Process enable the end product to meet the

needs more accurately, however involves better planning and more end user interaction at earlier

stages.

An Extreme Programming project builds upon iterations by making quick prototypes of

ideas, ensuring early feedback is received. Releases are created, each with their own iterations. The

iterations are driven from user stories, making sure unneeded functionality does not exist. Extreme

Programming also follows “Test Driven Development”, which revolves around acceptance tests

being created with the end user. An iteration cannot be deployed, until all tests are passed. This also

means the testing phase at the end will be slightly reduced.

I am going to follow the Extreme Programming methodology for a variety of reason. Firstly,

by breaking up the programming into smaller chunks, it will help me stay focused on the larger

picture, without getting “bogged down” in too much coding at once. Also, it means that there will be

a lot of end user involvement in my project, which will help in the sense that I am not fully aware of

how the Insurance department works. The fact that my product will actually be used by the

company when finished, also warrants the need for constant user involvement.

2.5 Relevance to Degree


11

This project required the knowledge from several different Information Systems modules,

with the main ones being the database and information systems module.

Database design, modelling and implementation drew upon the work I did in DB11 and DB21

(Database Principles and Practice). Lectures in normalisation data locking, and integrity were all

fundamental reasons for moving from the Excel solution and my knowledge from these lectures

helped in solution.

The analysis, requirements gathering was based on the work done in IS33 (People Centred

Information Systems Development) which gave valuable lessons on MIS failure, and the lessons they

learnt from these. It also strongly showed how to fit job descriptions to information systems,

something which would ensure the relevance of my software to its role.

The UML aspects of SE20 really added benefit into representing my design ideas. I was able

to communicate really well, through the use of the Activity Diagram’s and the Implementation

diagram exactly how the system would work and what I was trying to achieve.

Where the DB21 and DB11 aspects aided in my SQL work, there was still a gap in knowledge

for the application development. The practical work of SE24 focused on Java within Eclipse, and so

was of little use to me here.


12

3 Design

3.1 Preparation of the Solution

I began by getting in touch it with the Application and Support Development Manager, Ian

Hewitt, who ran me through a brief overview of the company. This was necessary to effectively show

how my project would fit into the rest of the business.

At another appointment, we then went through and discussed exactly what needed

creating. There were a lot of parts that were mentioned, including the Intranet side, and Business

Objects Universe as part of the final product. After taking all these details to my Supervisor, we

agreed that the database was to be the main requirement and the rest as enhancements.

From here I was told to go away and learn the basics of using Enterprise Manager and .net.

Having not used these applications at University, it was to be a challenge to learn competently in

such a short space of time.

Before designing began however, I performed some extensive requirements analysis, so that

I knew exactly what was needed from my system. This involved speaking to current developers, to

understand how to tackle this, and members of staff within the Support Services department to get

as much information from them as possible.

In a slight change to my initial background reading, BBUS updated their development

software. They no longer used “Enterprise Manager” for database design, but SQL Management

Studio 2005, and had moved from VB6 to Visual Studio 2005 for the rest of their development.

Where times on my Gannt Chant were not affected by much, it was worth pointing out that I was

using different software.

Iterations in a project refer to the technique of developing and delivering incremental

components of business functionality. Often associated with agile software development; an

iteration results in one or more bite-sized but complete packages of a project work performing a

business function. Multiple iterations then come together to create a fully integrated product.

That was the plan I was to follow with the BBUS system. Since I had to learn the packages

from the start, it made sense to develop sections at a time. Development will take place in the

following way:


13

1. Design of Database table structure

2. Table Designs in SQL Management Studio 2005 (Receive Feedback for changes)

3. Form/Navigation Design (Receive Feedback for changes)

4. Creation of base forms in Visual Studio 2005 (Receive Feedback for changes)

5. Implementation of Data Set into Employee Form for basic Database Functions

6. Carry over the Data Set implementation into other forms (Receive Feedback for

changes)

7. Implement “automated” risk assessments (Receive Feedback for changes)

8. Implement forms into Web Applications for portability

(Points 7 & 8 are not minimum requirements, but part of the implementation plan).

3.2 Existing Solutions

For any project to be really successful, I believe that looking at existing solutions is really

helpful. It isn’t a means of copying, but learning on past mistakes can really help the development of

your own project. In terms of similar BBUS systems, there were none, not even in any of the

different Op Co’s. I did try speaking to the Insurance Department of RBS (Royal Bank of Scotland)

through a friend that worked there, but as expected, for obvious security reasons they couldn’t give

me any insight into how they worked. This meant that my main source of information to go forward

was from the Excel spreadsheet currently in use (found in the Appendix).

3.3 Database Design

This outlines the organisation and the elements of the proposed system, and is intended to

show why and how decisions were made, and subsequently turned into a deliverable. It details with

reasoning:

• tools for development

• the design of the database itself,

• its interaction with and design of the GUI,

It is worth nothing my information sources for the project. I had several contacts within the

Insurance department of BBUS, who gave me access to the systems they currently use for claims

handling, and guided me with what they expected the system to achieve.

Chris Hughes – Head of Insurance


14

Dave Washbourne –Driver Trainer

Nicola Barrowclough – Insurance Claims Handler

Dave was my main point of contact throughout, and was particularly useful at helping me

define which fields would be need to be mandatory in the database, and also in exactly how they

work with the current system. Shots of the current system can be found in the appendix

The diagram below shows the initial view of how the database would operate.

Driver

As you would expect, the system is built around a driver (employee). Every employee of

BBUS who has a company car will be stored here. Their personal contact details will be stored here

along with their contact details.

Employee ID was my initial choice for a Primary Key to uniquely identify each drive, however

I was told that there can be some inconsistencies in these, mainly due to the numerous merge’s and

takeover’s of smaller companies that the BBUS often choose to do. It was then decided Payroll ID

was considered the PK for this tables as it is the highest level unique identifier and standard among


15

all BBUS Op Co’s. This way the system could be used in a different Balfour Beatty company with

minimal changes needing to be made.

Driver Statistics

To aid in the prediction of an “automatic” risk rating, separate from a driver detail were the

drivers statistics. This would contain a series of values that add to the risk of a driver. All fields will be

filled in manually at the beginning of a drivers’ lifecycle. Other fields like Annual mileage and

endorsement points get updated on a monthly basis. This ensures that an accurate risk rating of

drivers is maintained. Age will be updated automatically to the present date, drawing from the DOB

field in the Driver table.

Risks

The risks table is primarily used as a look up. Each risk that BBUS define as important to

warrant a risk rating change will be stored here. Each risk will have a numeric value associated to it

and from here, will tally up the value of all the driver statistics.

Incident

The main purpose of this system is to record the driver incidents. Obviously not all drivers

will have any incident records, but the sheer size of the current Excel spreadsheet shows how the

new database system will improve efficiency and accuracy of the data. After a driver has reported an

incident to the BBUS Helpline that information will get sent to an Insurance Claims handler, who will

then add the incident data to the system. That exchange of information may end of being removed,

and as security and record locking become implanted correctly, could then be input by the helpline

themselves.

Insurance Reference was chosen to be a PK in this table. The main reason for this is that it is

also used by the BBUS Helpline as their own reference as well. So communication between these

two groups will be aided by this.

Training

After recording an incident in the system, it would then be up to a Driver trainer, such as

Dave Washbourne, to decide whether training does indeed need to be carried out. It could be a case

of the incident was the third parties fault, or just that no training is deemed necessary. Here, the

driver trainer may log a training record, state where and what the training is. Comments will be


16

added to this record after the training has commenced, stating the results of the training, and if any

follow up needs to be carried out.

3.4 Security

In a real life system such as this, security is paramount. BBUS need to maintain that

unauthorised access by members of staff, or by the public, does not happen. The obvious starting

block for this is to implement a log-on process. Username and password authentication will need to

be used at two stages:

• Database Layer – this should only ever be maintained by members of the development team

in IT. If the insurance department need to make/suggest any changes or enhancements to

the system, these need to be requested via IT. Standard users won’t be able to access the

database layer for a number of reasons:

o They do not have any form of SQL Managemenet Software installed on their

machines, and do not have permissions to install any additional software

themselves.

o If they were successful at logging on to a machine that did have this, their own log

on’s would still have inadequate rights to connect to any form of database.

• Application Layer – this is where the DBA (Database Administrator) will come on. The

insurance department are looking to employ a part/full-time DBA to manage the system.

This will mean they keep all records up to date and ensure all data is accurately filled in. It


17

could be argued, that after implementing successful validation techniques, that this role is

unnecessary, however the department have chosen to go down this path anyway.

All BBUS users work on Windows XP client machines operating over numerous Windows

2003 servers. In terms of protection for the database layer, the IT department already have SQL

access permissions to databases. They will only then need a log in to the database itself, which just

provides an extra level of access. Nobody else within the company has any form of SQL permissions

to connect to the database directly.

When installed on Windows Server 2003, SQL Server 2005 can exploit the operating system's

password policies for SQL Server logins. This translates into more secure passwords and fewer

opportunities for brute-force attacks to occur on the database server. SQL Server 2005 supports

both password complexity rules (ensuring minimum length, enforcing combinations of alphabetical

and numeric characters, and so on) and password expiration policies (ensuring that old passwords

must be changed). This falls in line with the current BBUS user password standards as well.

3.5 Presentation

As one of the 21 Balfour Beatty plc operating companies, Balfour Beatty Utility Solutions has

more than 5,200 employees. Across all these different departments, any such business would strive

to have a uniformed colour, size and style of presentation.

I had a brief conversation, which was followed up with an e-mail, stating that all BBUS flyers,

signs, and IT systems all had to conform to BBUS regulations. These were the following:

• Same colour schemes

• Use only of recognised BBUS fonts (some bespoke, some chosen)

• Mention of company information, like Registered office, in the system

Layout of the User Guide for the system will also be tightly designed. BBUS already have a

current user guide template for any IT systems, and the appropriate information will be added to

this and handed in with the project.

3.6 Normalisation

Illogically or inconsistently stored data can cause a number of problems. In a relational

database, a logical and efficient design is just as critical. A poorly designed database may provide

erroneous information, may be difficult to use, or may even fail to work properly.


18

Normalisation is a series of steps followed to obtain a database design that allows for

efficient access and storage of data in a relational database. These steps reduce data redundancy

and the chances of data becoming inconsistent. The schema of the system followed that in the

Design section, seen as it was Normalised to second normal form. There is no repeated data in the

system.

3.7 Data Integrity

Applications have usually multiple tiers, such as a user interface, business model, and the

data itself. It isn’t uncommon practice for the application level for data validation, since in most

cases, it is a single application that interacts with one particular database. However, if that one field

became corrupt, because of a bug in the application, or if multiple applications accessed the same

data, then problems could arise.

Setting a different data type can only restrict so much, but it is possible to add additional

validation to ensure that if falls into your business logic. Constraints; and they should always be

used. A constraint is nothing but a rule that all data have to comply, enforced at the database level.

For example, with something as simple as the gender field, by adding the constraint

below, whenever a user tries to insert or alter the gender field with any character other than 'f' or

'm', the database will throw an error, which you can catch with the constraint name.

ALTER TABLE [dbo].[users] ADD

CONSTRAINT [CK_users_gender] CHECK ([gender] = 'f' or [gender] = 'm')

GO

Later on in the life of the system, these could be enforced for all kinds of data types. Fields

like the annual mileage, endorsement points, driving ban details, and all the different reference

numbers could all be tightly constrained, to ensure that they are all the same length and format.

At present, I was told to keep the verification quite loose, mainly to data types, as there are

more than a few inconsistencies in the current system. I was concerned that this meant the database

would just follow down the same path as the spreadsheet, and so showed to Dave how this could

happen. (See appendix emails) In my opinion, it is important to keep the integrity strict, and then

learn to keep by those strict guidelines. Working in the opposite way, starting with poor data

integrity and then changing things will only add to people getting dissatisfaction with the system

when it changes.


19

4 Implementation

4.1 Platform

The insurance and risk database will be implemented in the same way as all the other BBUS

systems and running on a Windows 2003 Server. Their IT systems are stored on numerous IT

Development servers, and so within here, a system folder will need to be created, with only

permissions to that folder given to the user that need it. BBUS have agreed to create an “Insurance

Database” group, to enable only people in this group the ability to access they system.

The client machines will not need to have any additional software installed. Any user

wanting to use the system will need to be given access to that shared application. BBUS simply

provide a shortcut to the users’ desktop’s to give them access. Provided they have permissions to

access the system, the application will then run across the network on their machine.

The server already has SQL 2005 installed, and so can be moved across onto that with ease.

The implementation diagram below shows how the database will integrate with the existing

architecture.

The beauty of the following solution is that really no extra software needs to be installed on

the client machines. Microsoft Windows XP, which is the only Operating System in use on client

machines, already comes with .NET Framework installed. Seen as the application has already been


20

designed to run under a Microsoft Windows environment, it could then run on any company

machine.

Driver trainers will also have the ability to update their training records as soon as they

happen. When they are by the road, they often have 3G cards, with a remote connection facility to

connect to work. Seen as more than one person can now access the system at once, it is likely that

they will not now have to wait to return to site before updating their calls.

4.2 Implemented Items

SQL Database

The raw database itself does everything I initially planned for it. All the tables were

implemented correctly (as in Appendix 8.6), with data types and integrity suited to the requests of

the Insurance Department recommendations. Given more time, I noticed that SQL Management

Studio 2005 had the ability to run and create custom reports itself. It did not appear to be very user

friendly, but it may have been possible to create some custom report templates, for the kind of

reports that would be run on a more frequent basis.

Log on Screen

The log on screen was implemented quite easily. It isn’t however included in the final build,

as at the last minute I had some problems with the compilation and didn’t have time to work out

why. Its intention was simple, draw upon the table or username and password from the SQL schema,

and verify it against what the user inputs at their end.

Main Menu

As you can see from this, the main menu was quite

easy to implement. All that really needed deciding was the

layout and the way the forms would interact with each other.

As you can see the navigation buttons are grouped into the

different areas that the user may want to go into.

Standard users cannot get into the Database

maintenance section, as is envisaged that only the DBA

(Database Administrator) should be able to do this.

Employee, Incident and Training Pages


21

These pages are fairly straight forward in their layout and as you can see from the user guide

(in Appendix 8.7), they all follow the same scheme. Each page is headed by the navigation button,

and each record begins with its unique identifier, the employee ID in most cases. They can then add

new incidents to the drivers records, and if requested by the driver trainer, can add suitable training

to reduce that drivers risk rating.

Once the training has been completed that risk rating can then be reduced accordingly. It

would be an idea for further development, to enable the user to state that training has been

completed, and there be an automated way for the system to reduce the rating. For now though,

these reductions are performed manually by driver trainers.

Risk Values

The idea behind this section was to enable the DBA to manage the different risks and

incidents in the system. Driver statistics are gathered from the numeric values in this table, however

at some point in the future, it is likely that the value of these risks may change.

User Guide

The user guide was my final implemented minimum deliverable. It wasn’t so much a step by

step guide, but a description of how the system works. The people using the system have worked on

various databases before, and in itself, is very easy to use. So I just wanted to make sure that the end

users knew “how” it works, and the idea that its more efficient and can be updated by numerous

people at once.

I used the standard BBUS template for this to make sure it fits with the rest of the company

forms.

4.3 Importing Existing Data from Excel

I researched several different ways of getting the existing data into the new system.

ADO.NET provides consistent access to data sources such as Microsoft SQL Server, as well as data

sources exposed through OLE DB and XML. Data-sharing consumer applications can use ADO.NET to

connect to these data sources and retrieve, manipulate, and update data (Malik 2005). By adding an

Excel data provider to this, such as the JET OLE DB, will effectively export the records. Adding a

connection string like below:

Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Book1.xls;Extended Properties="Excel

8.0;HDR=NO;"


22

It would be necessary to make the HDR value to YES, rather than NO. This is because the

structure of data is all being used in the new system, and so the heading values will still remain

applicable. However, the following disadvantages arise when using ADO.NET:

• Managed-Only Access: Cannot utilise the ADO.NET architecture from anything but managed

code. Therefore, to take advantage of the advanced SQL Server Data Provider and any other

features such as Data Sets, XML internal data storage, and so forth, your code must be

running under the CLR (Common Language Runtime - The runtime engine in Microsoft's

.NET platform).

• Data Providers: You are tied down to a few data providers. If you need to access any data

that requires a driver that cannot be used through either an OLEDB provider or the SQL

Server Data Provider, then you

Along with SQL 2005, Microsoft released Integration Services, which replaces Data

Transformation Services (DTS). It is a tool for extracting, transforming, and loading data. Common

uses include:

• loading data into the database

• changing data into to or out from your relational database structures

• loading your data warehouse data

• taking data out of your database and moving it to other databases or types of storage.

The process of the data import was as fairly simple. I needed to designate the sheet from the

Excel file that I want to import, along with the columns from the sheet that I want to use.

After defining my Excel source, it was necessary to define my SQL Server destination. Before

doing that, I need to indicate the Data Flow Path from the Excel file to the SQL Server destination;

this would allow me to use the structure of the data defined in the Excel Source to model my SQL

Server table that I will import the data into.

Under the Mappings section, it was then possible to define the relationship between the

Input Columns (the Excel data) and the Destination Columns (SQL Server table).


23

This method proved a lot more “user friendly” in specifying the data to import. Using

ADO.NET was a lot more command line driven and involved much more programming. This method

was all GUI based, yet provided just as much functionality.

4.4 Implementation Issues

• Whilst the company had upgraded software to newer versions, I was actually the first

member of the company to be using this software fully. This presented a number of

technical stumbling blocks, where I found that in areas I had problems; they themselves

were unable to help me with.

• In setting up the SQL Dataset, implementation was delayed by over a week while I struggled

to get Visual Studio and SQL Management Studio to communicate with each other. Whilst

the solution eventually ended being moving the directory from a network folder to a local

disk, this was an unknown issue to the developers of the company.

• Even though I got the risk rating part of the system to work, I didn’t have time to finish off

one of the enhancements I wanted to build. As you can see from appendix part 8.2, there

was going to be a welcome message on the main menu, stating the number of high risk

ratings that were present in the system. This way, on a daily basis, users could see if they

were reducing the amount of cases, or letting them slip and rise. Unfortunately, this didn’t

get finished and is missing the SQL Query to create this.


24

5 Testing

As I progressed through my implementation, it became apparent that I was running out of

time. My initial plan was to follow a full BBUS testing process, which should have been roughly 3

weeks in length. In reality, this was never going to happen, and I realised this quite early on.

I then decided it would be more appropriate to perform testing as more of an ongoing

process, rather than a stand-alone section in my project’s life cycle. This resulted in testing parts of

my system in parallel with its implementation – checking iterations and sections as they were

developed, before moving onto the next.

This became a problem as the project grew, as I then found I wasn’t testing the solution in

the overall sense, and just the individual units. The following headings are how I would have ideally

tested my system, and are to the standards that BBUS following in their software development

process.

5.1 Developer Testing

Testing is initially undertaken by the developer responsible for each enhancement / fault fix.

When the developer is happy that the work is complete the Business Requirements document /

Incident log is passed across to the UAT team and reassigned in the work tracking system to a status

of UAT. This eventually became a very automated process, often with me testing units of the system

without consciously meaning to. Each test had a preferable outcome and had a pass or fail state and

moving on to the next unit never happened unless I was happy with the solution.

5.2 Quality Assurance Testing

Based on the documents passed over, the UAT tester must compile a test-plan in advance of

any testing. A test environment is created by either configuring an established Test/Dev

environment or by ‘virtualising’ an existing production server into a test environment.

Testing is initially done by the UAT team without reference to the originator of the

Enhancement / Incident. The plan is then followed and feedback comments are compiled. If the

result is a fail the work is passed back to the developer with the test plan results and a discussion. If

the result is a pass User Acceptance Testing commences.


25

Due to my lack of time, I was unable to attempt this form of testing and moved straight to

user acceptance testing. This was necessary as I felt it more important to get good user feedback,

even just for the closure of my project, rather than adding the UAT team into it. Quality assurance is

something which is undoubtedly important in business solutions, but due to time constraints, I felt it

the least important.

5.3 User Acceptance Testing

The UAT team will contact the originator of the enhancement /incident and arrange a re-test

– this time with the user present. However, most users are unfamiliar with testing techniques

therefore the UAT testers generally lead the testing process. My test plan was used well this, as I sat

down and presented to Dave Washbourne and Chris Hughes. Chris is the head of the Insurance

department. We created a series of functional tests which entered data into the system and meant

we could then recover and add incident and training data to. Up until this point, Chris had no idea

the inner workings of the system, and so represented a real end user.

If the test passes the work moves to a status of Software Release Ready where formal

release planning takes place. If the test fails it will be for one of two reasons:

1. Failed functional test – fails to meet the specified requirements and is returned to the

developer.

2. Failed to meet business needs – specification is wrong. An immediate discussion takes place

with the Application Support and Development Manager.

a. A minor variance will be dealt with immediately but may impact overall

development schedules in a minor way.

b. A major variance will require creation of an additional Business Requirements

document. Either way the work returns back to the developer.

Luckily, there were no failed business needs. The minimum requirements set for my project

matched the businesses requirements, and the produced solution stored


26

6 Evaluation

The aim of the evaluation section is to reflect upon the success or failings of the solution, the

approach, and the project in its entirety. The question that really needs to be answered is that of

“has the product achieved its goal”?

As mentioned previously, working alongside BBUS in the development of this project had

numerous advantages; feedback and evaluation were one of these. This meant I could not only use

my own thoughts as a critique, but the use of the real end users would really benefit this.

6.1 Methodology Evaluation

From the beginning, working with BBUS was a good idea. It meant I did not have to

“imagine” things as much, and added the benefit of providing a solution that would actually be used.

This did pose a lot of problems to my work, such as BBUS failing to recognise my need to work on my

project first, and their eventual needs second. It became apparent nearer the end of the project life,

that they had little regard for my actual report writing and would have happily had me developing a

lot more.

In their eyes, they were only trying to get the best solution possible, but in mine, I had to

eventually segregate myself from going to site, as I would often be bombarded by staff who wanted

updates.

I still feel that the route taken, to work with a real-end user, provided more gains than

losses. Communication skills improved and I was able to know exactly what was needed. I do think

however, that the main stumbling block in the methodology was that I became tied down with

learning new software. If it would have been possible to use the software I had been taught with at

University, a good 4 weeks could have been removed from the project schedule, leaving time for a

more advanced and technically better product.

Looking back, what really helped me was having the amount of contact with staff that I had.

I allocated myself to be there at least once a week, and the rest of the time was through e-mail

contact at home.


27

6.2 Design and Requirements Evaluation

The requirements analysis was definitely a success. I was able to communicate well with the

team, and I am confident that the requirements produced reflect exactly what the Insurance

department expected.

The current process of adding incidents to the Excel spreadsheet was nothing short of poor.

Only one user could access the system at a time, bearing in mind that there are Insurance Claims

handlers, Driver trainers, and key managers that all look at the database.

The process of adding a new driver, incident, or training is one that now has some structure

to it. No longer will there be missing fields for a driver, and if a driver has more than one incident,

their personal details will not be needlessly replicated. By having such a structure in place, the

people actually using the system will benefit from having a better understating of the actual

processing going on. They will understand that a driver doesn’t necessarily need training, and there

is also now space for some detail on the driver training. This wasn’t present in the existing solution,

and it meant a user must know the content of that training, now they don’t.

By being able to assign risk ratings to the system, users can more effectively manage their

drivers now. Looking at a flat spreadsheet, there is no way of ordering the coloured sections of

people (showing high and low risk). By having a risk rating per driver, future enhancements will

enable people to search for, or draw reports on drivers above a certain risk rating.

Looking back at my minimum requirements for this task, they have certainly been met. The

base database structure is in place, and works as it should. This provides a good quality foundation

for further development work on it, which in time, will increase its productivity and value even

further.

Personal evaluations have been included in the Appendix, from various members of the

company.

The user guide is basic, but is intentional to not be an exhaustive document, and more of a

functionality document. It was apparent that by using the Excel spreadsheet, that people weren’t

fully aware of the proper processes within the department, and by outlining this in the document

provides numerous benefits to the company.


28

6.3 Project Evaluation

Project management was not defined as a minimum requirement, but was a field I hoped to

better myself in. There was a strict deadline to be met, and it was a success in that sense. Time

management was still an issue, and by letting the implementation run over by so much, left me

feeling that inadequate time was spent on testing, evaluation and the full report write up. I think

that my goals may have been slightly ambitious; in the time I allocated for learning the software, and

maybe should have just left the implementation where it was, and moved onto the testing when my

timetable said I should.

6.4 Future Enhancements

• The ability to show the full driver details per record and not just the employee ID.

• Ability to search for a driver based on risk rating. This would prove a very valuable tool for

the department, enabling them to target on the drivers that needed attention the most.

Given more time, this would have been part of the final solution.

• Intranet based driver details maintenance. The application will be further developed to

have a web-front end. This will enable drivers to be able to edit the system directly from a

browser, eliminating the need to remotely connect in.

• Creation of a Business Objects Universe to allow the end-user to create their own reports.

Business Objects is used as a standard reporting tool within the company, and its role within

this system would be to provide accurate and clear information to managers to help aiding

high-level decisions.

• The adaption of the system for PDA’s was discussed. It is likely that BBUS will follow down

this route, as they have done on their Supply Chain side of the business. By creating a cut

down version of the GUI, drivers would eliminate the need to have a laptop with them every

time they were training drivers, and could update the records much quicker using a PDA.

• As part of my last meeting with Brent Mitchell (Head of Support Services), we discussed that

in the future, it may well be worth combining this system, with the one on the Hotline (that

originally receives the call’s from drivers about incidents). At present the hotline also take

other calls related to construction issues and customer queries, and so this would be a large

task. It would however, eliminate the need for passing the data from the helpline to the

insurance team, reducing the chance of errors.


29

6.5 Conclusion

Admittedly, progress was slower than expected. Due to the project being with an external

company, more planning had to be used to organise times to go to the site. I had to arrange

provisional visits, which would then be confirmed at a later date. I was naive in thinking this would

be no harder than a normal project to accomplish. On the other hand, the fact that end product will

actually be used day-to-day is very rewarding. The project should be considered a success, as it

meets all its minimum requirements, and has started to build upon its enhancements. These building

blocks should give the system the opportunity to improve for the future.


30

7 Bibliography

Bocij P, Chaffey D, Greasley A, Hickie S, (2003) Business Information Systems.

Huber, M, W., Information Systems – creating Business Value. 2008

Oliver, P, R, M. & Kantaris, N., Using Visual Basic. 2001; 153-191

Malik, A, S., An Introduction to ADO.NET, Pro ADO.Net 2.0. 2005

Microsoft., No 2310. Developing Microsoft ASP.net Web Applications using Visual Studio.net

Moore, K., Database ADO.NET Overview. Retrieved March 13, 2008, from developer.com:

Schneider, R, D., MySQL Database Design and Tuning. 2005

Sutherland, J.,(September 2007), Business Objects for Corporate Information Systems, Retreived 18th

December 2007, from JeffSutherland.com: http://jeffsutherland.com/papers/boa_pap.html

Taylor, A, G,. SQL for Dummies. 2003

Thearon, W., Beginning Visual Basic 2005. 2006

(2008, January 8). Database Design and Normalisation. Retrieved April 12, 2008, from DatabaseDev:

http://www.databasedev.co.uk/database_normalization_process.html

.NET Framework Developer's Guide. Retrieved March 10, 2008, from Microsoft MSDN Library:

http://msdn2.microsoft.com/en-us/library/h43ks021(VS.71).aspx

(2005) Databases vs Spreadsheets. Retreived 12 February 2008, from Databasic Information

Services: http://www.databasic.com.au/databases_vs_spreadsheets.htm

MySQL. Retreived 11 March 2008, from TechWeb:

Networkhttp://www.techweb.com/encyclopedia/defineterm.jhtml?term=MySQL

8.1 Reflecting upon the Project Experience

The overall aim of this project was to identify the benefits for, and develop a solution to

BBUS’ current Excel spreadsheet. This was to be a direct replacement to their existing solution,

however is currently being used in parallel, until the staff feel 100% happy with everything about it.

The initial requirements and analysis stage proved harder than I anticipated. If I was to have

my own way, I would have had a good look at an existing solution that performed the similar kind of

idea; this would have really pushed my confidence along. Nevertheless, I was happy with the way

the project was looking.

The design stage was relatively straight forward. By working with a real-life company, and

with the final users on site, I was able to sit down with them and work out exactly what they wanted.

A major advantage to working with an end user is that it was easier to evaluate prototypes.

Database and form designs were discussed with members of the Insurance department on a regular

basis (mainly Dave Washbourne). I took it upon myself to explain as clearly as I could, how my ERD

diagram was going to translate into the finished product, and they approved all the form designs

before anything was implemented. I was able to ensure they were happy with everything before

moving on.

Implementation was a totally different story. At first, I thought that learning to use new

software would be an advantage. Having a clean slate, learning from scratch, working with

developers for help and advice seemed all like positive points to this method. My opinion though,

eventually changed on this as I began to fall more and more behind in my implementation. I totally

under-estimated the time it would take to get acquainted with and skilled in using the software. On

the face of the software, Microsoft SQL 2005 Management Studio, and Visual Studio 2005 looked

like relatively easy software packages to learn. After all, I understood the basics of DBMS’s from

lectures, and knew in my head what I wanted to achieve.

In reality though, I was wrong. The standard Windows presentation of tools was where my

familiarity ended, and for a while, I had two pieces of separate software doing nothing together. I

had the database designed and running, and the GUI set out and ready to BBUS design standards. It

took me over 2 months to grasp how the two pieces of software would “merge” together. As

mentioned earlier, this lack of progress was not just down to me own knowledge, but the lack of

help and guidance I was to receive from BBUS IT developers as well. None of them had upgraded to

any of the 2005 packages, and where as you may think there would be numerous similarities, they

ended up not being able to help me at all. My saving grace was numerous websites and forums.

This left me with about 7 days to perform some testing of the system. Regrettably it was

rushed and not as well prepared as I had hoped. After working with Pav on the testing I did realise

that it is often more overlooked than I originally thought. In my prior experience at A Level and

University, testing was never very high on my agenda, and with not meeting implementation

deadlines, it always seemed rushed. However, at BBUS and probably most companies, testing takes

longer than any other section in a system’s life cycle. This could be a conscious effort to reduce the

high percentage of MIS failures that occur in today’s society. A real valuable lesson from this would

be the inclusion of much thorough test plans and the allocation of a lot more time for this.

Evaluation was quite easy to perform. I am a very critical person, both a good and bad

quality, and I don’t think I would ever be fully satisfied with a piece of software. It does mean

though, that I am able to realise improvements and adjustments that can be made, which was

shown earlier. My system met its requirements as set out, but had a long way to go until it was

everything that BBUS could hope for.

I truly believe that my most valuable lessons at Leeds University have been the various

project tasks. Whereas lectures have had their value, nothing has prepared me more for the real-

world than developing a solution to a problem. Whether this is solo, like in this project, or in a team

like SE24 or PD31, I have gained so many skills to help me perform better in the future.

My main achievements from this project have been:

• To adapt and improve my knowledge of SQL for use in SQL Management Studio

2005 and Visual Studio 2005, some of the biggest application development programs

in the world.

• Developed and maintained a professional working ethic and approach.

• Created a professional looking software package that BBUS can now use to improve

their business processing.

My communication skills have improved, I feel I am better again at getting my points and

ideas across, and the planning my work seemed more accurate also. I like to think that my

disadvantages in some of the software development in the project were overcome by my clear and

concise vision, and professional conduct when dealing with any member of staff at BBUS. I feel I

acted like a full member of their employment, and am happy that they have asked me to join them

over the Summer of 2008, to continue on the improvements and extensions that I have suggested.

I regret the challenges I faced when implementing the solution, and looking back, would

have either allocated a lot more time to development, or, if not have been working for a company

with set software, developed a solution in a PostreSQL and created my front ends in Eclipse from

which I was familiar in 2007. This would have given me a lot more time for coding as no “learning”

time would have been necessary. As pointed out though, this was not an option for BBUS.

These projects have always created problems, issues with working together, and had lots of

drawbacks that you think you will perform better for the next time you start something similar. You

never perform quite as well as you anticipate most likely always have things you will do differently.

These are the most valuable things you could take away with you. I look forward to improving again

in the future and using these skills.

8.2 BUSINESS REQUIREMENT DEFINITION

Raised By Christopher Hughes Date 01/05/2007

Email [email protected] Request No. 171162

Telephone 0114 232 9700 Application Driver Training Database

Completed by Matt Jagger (external) Date 04/10/2007

Summary DRIVER TRAINING DATABASE - Analysis & prioritisation of training requirements

Requirement

There is a process in place to assess the risk level of all drivers within BBUS so that:

• Appropriate training can be arranged

• The probability of them being involved in an incident is reduced.

This information is currently captured on a spreadsheet by Dave Washbourne. The risk is assessed by having a scoring system

in which each contributing factor is assigned a risk rating. This is then categorised into Red, Amber & Green depending on

the cumulative score.

**If there is a requirement for driver training then this counts as a negative score and so reduces the risk.**

It is proposed that a Web Application is created which will be accessed via the intranet. This will allow the Helpline (part of

the Support Services Department) to capture this information in a database when it is reported to them.

The reports will be run via Business Objects. A Business Objects universe will be created so that reports can be created by an

assigned person. The IT Service Desk can then set up user access to these.

The training team will be able to view a report of high risk drivers, arrange appropriate training and record this in the

database once completed.

The drivers’ managers should have the ability to view the existing incidents and the risk report information only for

employees which they manage.

There will be an assigned administrator for the database who will have access to all data. The administrator will be the only

person who can add new users and update existing users within the database. They will also be able to maintain the Risk

Data Ratings and add new criteria to the list.

New drivers and existing driver updates will be imported from the Driving License database and/or Oracle.

• The current risk rating criteria is contained in the file ‘Risk Rating data for driver database.xls’

• The spreadsheet currently used to capture the information is the file ‘RTA Priority list.xls’

The following driver details are not currently on the spreadsheet but will also require capturing:

• Age

• Payroll No (as a unique identifier for the driver)

• Annual mileage (for car drivers this can be taken from the vehicle details, others may have more than one driver)

The following ‘Use Case’ diagram shows the overall requirements for the process.

8.3 Personal Evaluations

16th

April 2008

The system that Matt has produced really improves upon our existing way of working. We

have been using the RTA Spreadsheet for over 4 years now, and as it has grown, it has become

increasing laborious and time consuming to use. We already knew of Matt from his summer work

that he did for us in 2007, and so after being approached by Ian Hewitt (IT) and told Matt would be

working with us, we were more than happy.

Matt’s personal approach to the work has been reflective of the professional work that the

IT department produce. He has been successful in arranging and managing meetings, and spent lots

of time with us listing our requirements. It would seem that he eventually had a better

understanding of how our department works than some of my colleagues did!

He then kept in touch with us whilst designing the screens and the backbone of the system.

This was particularly useful, because I have a very basic knowledge of IT, and he managed to explain

quite well how everything was going to work before hand.

The hardest part of this work has definitely been in the creation of the system itself. I know

full well that the system does not meet what Matt’s predictions were, even though it does do what

its original plan was. Its basic features work, and with more time spent, we will have a system that

performs to everybody’s expectations. It’s a learning curve that happens in all businesses and

something that will be sorted for the future no doubt!

We look forward to stealing Matt away from University when this is finished to carry on

working work us and getting the most from this system.

Cheers matey

Dave Washbourne

20th

April 2008

Matt has worked very well for BBUS on this project integrating into our small team of

developers. Initially I was concerned about the extra burden of working with Matt as any new

developer always creates more work that they deliver in the initial phases. With Matt he has sat with

the team, taken on the culture and ways of working and has largely done most of the work himself.

It has been a pleasure coaching Matt throughout the development and see how he has interacted

with our business users. The application Matthew has developed has passed our Quality assurance

test, UAT and has been critically reviewed by one of our developers; rather than release this

application we have agreed with Matthew that he will return very shortly to see the completion of

the release and be on hand for any operational issues experienced.

At all times Matthew has conducted himself in a confident and professional manner and I

am sure he will be a credit to any organisation in the future.

Ian Hewitt

8.4 E-Mail Transcripts

From: Washbourne, Dave

Sent: 13 March 2008 09:37

To: Jagger, Matthew

Subject: RE: F/N ??

Hi Matt,

When you say Reds; do you mean those who are outstanding for a training session or those who

have been graded Red by a trainer?

If you are referring to those cases waiting to be programmed in for training I would suggest that this

is a good idea but should also incorporate the ambers.

How long before we can have a look?

D

From: Jagger, Matthew

To: Washbourne, Dave

Subject: RE: F/N ??

Thanks for the emails dave. As part of the main menu, after logging in, I am going to try set up a

notice area, ie it will tell you how many Red’s there are in the system Would this be useful, or is

there any other piece of information that may be better here?

Ta

Matt


To: Jagger, Matthew

Subject: RE: F/N ??

Hi Mate,

The short answer is both; we evaluate the severity of the incidents as they come in and award a

(coloured line at present) RAG to determine the order of priority to be called in for training. Once a

training session has been completed, this original RAG coding is irrelevant and so we currently white

out the entry; it is a simple way of being able to look through the spreadsheet and see what has

been actioned and what is left to be booked in. After a training session, the driver’s report is graded

RAG based on the trainers observations and recommendations as to any further action.

D


Sent: 07 March 2008 10:30


Subject: RE: F/N ??

Nearly there with the database design. Just one other thing. Risk ratings…

You said you assign a RAG risk rating after training has been carried out (after an incident).

But do you set up initial risk ratings currently, ie from the data the driver previously has on their

license, mileage, age points etc.

In the final system do you want there to be these two separate risk values? One as a prediction and

one for after training, or would the risk value after training replace the initial estimate?

Matt


To: Jagger, Matthew

Cc: Hughes, Chris

Subject: RE: F/N ??

Hi Matt,

RAG = Red Amber or Green. These “risk ratings” are awarded to a driver post training/assessment

according to the degree, if any of follow up action required.

EVERY incident involving a BBUS driver is logged and a decision is made on prioritizing the need for

intervention. The green coloured lines are non urgent, amber medium priority and red high priority.

Any in Dark blue are drivers with multiple histories denoting highest level of priority. There are also

some coloured turquoise; these have some form of anomaly; incorrect data, need further

investigation or are plant issues and in that case they are referred to the plant compliance manager.

The white lines are either completed cases or are incidents where it is deemed that no action is

required. For instance, if a driver reports an isolated case of “unknown damage” it is usually held on

file but not acted upon. However, if the same individual appears to be reporting a number of these

incidents, we would colour the entries and begin an investigation.

You are quite correct about the Ins Ref; the 1st

column on the page is the hotline reference number

and the ins ref is the BBUS insurance/traction number. This allows us to cross reference any cases in

the event of any uncertainty.

As for any entries not being required; I’d say they all are as each line will result in a “scoring” that

will collectively add up to an indication for the need for intervention.

Regards

Dave



Cc: Hughes, Chris

Subject: RE: F/N ??

Hi Dave,

A couple of other points, RAG and the other associated comments, what do they mean?

Also, is it a case that every incident means a driver will undergo some form of training, or for some,

is none needed, and if so, not recorded at all?

The Ins ref (I assume means insurance reference) - is that a BBUS insurance reference or an external

ref?

I’m getting near a good database structure, which will mean I will be able to show you how the

database will fit into place. From there I will need you to help me work out which fields of data

"must" be entered into an incident, and which aren't 100% necessary.

Then when the relations are all in place I'll start work at making a useable front end for it.

Matt


To: Jagger, Matthew

Subject: RE: F/N ??

Hi Matt,

Glad to see you’re working on my project now (not to imply that you aren’t working ….oh never

mind)

The F/N is simply Fault or Non fault.

Don’t hesitate to get in touch if you need any further help mate; I need what you can develop as

soon as..

Regards,

Dave



Subject: F/N ??

Dave, just a quick question,

On the RTA pritority list, what does the field F/N stand for?

Ta

Matt

Hi Matt,

The parts in black should be checked before they become a driver for BBUS. Endorsements and

mileage will be checked before and continuously.

Hope this helps. Let me know if you need anymore info.

Thanks

Nic


To: Barrowclough, Nicola; Hughes, Chris; Washbourne, Dave

Subject: Risk Ratings

Guys, and girl,

Just really trying to get to grips with how you risk drivers. Below is all the criteria ive been given on

risk ratings. Am I right in thinking that the Bold-Black items are ones that can be used when an

employee becomes a “driver” and so aids in the prediction” and the risk in blue are incidents that

will happen once the driver has started driving – and so aid in “editing/evaluation” of the driver risk?

The section:

“1st incident within 12 months

2nd incident within 12 months

3rd incident within 12 months”

Is that their personal driving history before becoming a BBUS driver, or once they are already a

BBUS driver? So is it a prediction rating or a evaluation rating?

Ta

Matt

Age: 17-21

Age: 21-25

Age: 25-30

Age: 30-45

Age: 45-60

Age: 60-65

Age: 65+

>12 months overall experience

12-24 months overall experience

>12 months experience on licence category

1-3 endorsement points


7/8 endorsement points


12+ endorsement points

12 months drink/drugs drive ban within previous 5 years

18 months drink/drugs drive ban within previous 7.5 years

24 months drink/drug drive ban within previous 10 years

Any ban previous 12 months

Annual mileage > 6k

Annual mileage 6-12k



Annual mileage < 30k

1st incident within 12 months

2nd incident within 12 months

3rd incident within 12 months

Unknown damage 1st time

Unknown damage 2nd time

Unknown damage 3rd time

Hit whilst parked 1st time

Hit whilst parked 2nd time

Hit whilst parked 3rd time

BB moving mirror strike n/s on obstruction

BB moving mirror strike o/s on oncoming traffic

BB lane change collision

3rd party lane change collison

3rd party rear shunt

BB rear shunt

Collison with stationary vehicle

Collision with street furniture; not reversing

BB emerge into 3rd party path

3rd party emerge into BB path

Overhead collision

BB into BB

Reversing

Skidded off road

Collision with road debris

BB lost load

Collision with pedestrian

Collision with cyclist

Animal strike

Rolled vehicle

Windscreen damage

BB vehicle in excavation

Any trailer incident

Overtaking incident

Head on BB stopped

Head on both parties moving

Grab: damage with crane

Plant incident on highway

Door opening into 3rd party

Insecure parking

Turning right across 3rd party path

3rd party turning right across BB path

Grab: damage with raised body

Vehicle break in: BB equipment stolen

Any fuel station collision

Vehicle inspection: Illegal tyres

Vehicle inspection: Illegal lighting

Vehicle inspection: Low fuid levels

Validated complaint: Tailgating

Validated complaint: Speeding

Validated complaint: Phone use

Validated complaint: One way street

Validated complaint: Cut 3rd party up

Validated complaint: Parking

BB vehicle rollback

Incident with no previous training

Incident with 1 previous training session

Incident with relevant warning/advice from previous training

Incident whilst on amber rating

Incident with 2 previous training sessions

Tracker: Speeding 1st time

Tracker: Speeding 2nd time

Tracker: Speeding 3rd time

Tracker: Speeding 4th time

Tracker: Speeding 5th time

8.5 The Existing Solution – There are currently over 1500 records in this spreadsheet.

How to . . . . .????

How to use the Insurance

and Risk Database The BBUS Insurance and Risk Database was created to effectively manage the records of all the drivers

within the business who have Company Cars. As the company has grown, and taken on other

businesses, the driver total has increased dramatically, meaning the previous Excel spreadsheet could

not cope anymore.

Setting up the Database>>> You will need to request access to the database via the IT Helpdesk. A Line manager will need to sign

off a request form for you.

Once that has been done, the helpdesk will provide you with the necessary security permissions, and

give you a shortcut to the system on your desktop.

Logging in to the System>>> Once you have loaded up the application, you will still require a log on creating for the database itself.

This will be provided by the Insurance Department DBA (to be appointed). For now, contact Nicola

Barrowclough.

Your details will follow the structure:

Username: <surname>.<first name initial>.<randomly assigned number> eg jaggerm.2008

Password:

How the System works>>> It is important to understand how the new system works. Its not just a spreadsheet of data that was

once before. You will enter at the main menu, and your first point of contact will usually be the Driver

Details page. Here you can add, edit, remove drivers from the system.

In the old system, a new line constituted a new incident, but this meant that a driver would appear

many times for no benefit at all.

In the new system, as in the real world, a driver can have many incidents. This means that once a driver

is in the system, more and more incident can be added to that one driver.

For every driver record, they can have as many incident recorded on the system, and as many training

events as required. This really saves space and efficiency. When you are looking for a particular driver’s

history, you no longer have to trawl through the spreadsheet looking for them.

How to . . . . .????

IT SERVICE DESK – 0870 240 3341

This also addresses the issue of only one person being able to edit the system at one. You can now all

use the system together, providing nobody is attempting to edit the same record at the same time. But

different users can be logged in, all editing different driver details and updating their incident and

training records accordingly.

Each driver now also has their own ‘risk rating’. There is a pre-defined list of incident and problems that

a driver may encounter. These all have their own ‘risk level’ attached, and as a driver stacks up a series

of incidents, their risk rating goes up accordingly. This means that reporting is much easier, and you can

prioritise that worst drivers better, giving you a better idea of when you start to get on top of things.

The Main Menu

As normal user, you can get into

driver maintenance and incident

maintenance. Database

maintenance is restricted to the

DBA.

All the forms have a similar layout,

and are quite straight forward to

use.

• Navigation buttons are

clustered together, to help

you move between

windows

• The calculated risk rating

will update itself as more

incidents are added to the

system

• To add new records, save

edit or print, there is an

options bar at the bottom

bbus driver training & risk database matt jagger bsc … insurance department. it then ... bbus...

Documents