Fleet Maintenance Management Mike Wardell Accounting … · Mike Wardell Accounting and Computing ... MERISE: MERISE consists of ... SSADM adopts the Waterfall model of systems development,

Mike Wardell 20 Credit Project

Fleet Maintenance Management System for a construction company

Mike Wardell

Accounting and Computing 2001/2002


Summary

The main objective of this project was to design and implement a fleet management database system that

would enable Wright (Hull) Limited to administer their vehicles appropriately.

The database stores vehicle and driver information sufficient enough to meet the users requirements and

produce the relevant warnings.

The interface was required to be as user friendly as possible and be simple to enable many users to use it

without any difficulty. The interface was designed with reference to Nielsen’s guidelines and resulted in the

interface being designed and created successfully.

The system was created using Microsoft Access 2000. The data is to be entered using specially created

forms. The output is also via forms and reports that were requested to be produced. The database was

designed using correct principles and guidelines and the tables were normalised to prevent anomalies.

A user guide was also necessary to assist the user in the use of the system after the completion of the project.

The guide created can be used as a reference for when the user comes into difficulty or doesn’t know how to

perform a particular action, as well as to train the user in how to use the system. On-line help is also

available to the user while using the database by pressing the F1 button.

The project was completed successfully and all the objectives were met.


Acknowledgements

I would like to thank Wright (Hull) Limited and in particularly Steve Antcliff for the continual support and

patience received throughout the duration of the project. Without the assistance received the project would

have been impossible to complete.

I would also like to thank my supervisor, Raymond Kwan, for his time, guidance and understanding

throughout the project.


Contents

1. Introduction 1

1.1 Background 1

1.2 Project Solution 1

1.3 Project Objectives 2

1.4 Project Deliverables 2

1.5 Project Schedule 3

2. Methodology 4

2.1 Consideration and selection of suitable methodology 4

2.2 Outline of Development methodology 4

3. Analysis 6

3.1 Data Flow Diagram 6

3.1.1 Components of a Data Flow Diagram 6

3.2 Entity Life Histories 7

3.3 Functional Analysis 8

3.4 Database Integrity Constraints and Validation Rules 8

3.4.1 General Form of a Constraint 8

3.4.2 Attribute Constraints 9

3.4.3 Relation Constraints 9

3.4.4 Database Constraints 10

4. Design (7 pages) 11

4.1 Entities and Attributes 11

4.2 Normalisation 11

4.2.1 Reasons for normalisation 12

4.2.2 Normal forms 12

4.2.3 Normalisation technique 12

4.3 Entity Relationship Diagram 13

4.4 User Interface Design 14

5. Implementation (13 pages) 17

5.1 Tables 17

5.2 Forms 17

5.3 Queries 23


5.4 Reports 23

5.5 User Help 25

5.6 Security and Maintenance 26

5.7 Deployment 28

6. Testing (1 page) 29

6.1 Introduction 29

6.2 Field Testing 29

6.3 Form Testing 29

6.4 Reports and Query Testing 29

7. Summary and Evaluation (4 to 5 pages) 30

7.1 System Evaluation 30

7.2 Problems encountered 32

7.3 Future Development 32

7.4 Previous Knowledge 33

7.5 Company Feedback 33

Appendix A: Reflection

Appendix B: User Needs

Appendix C: Data Flow Diagrams

Appendix D: Entity Life Histories

Appendix E: System Requirements

Appendix F: Functional Analysis

Appendix G: Data Dictionary

Appendix H: Visual Basic Constraints

Appendix I: Normalisation Table

Appendix J: Screen Shots

Appendix K: SQL Queries

Appendix L: Sample Report Outputs

Appendix M: Integrated User Guide Screen Shots

Appendix N: User Guide

Appendix O: Field Testing

Appendix P: Form Testing

Appendix Q: Test Data

Appendix R: Report Testing

Appendix S: Company Feedback

Appendix T: References


1. Introduction

1.1 Background

The Finance department of T Wright & Son (Hull) Limited is responsible for all the company’s monetary

outgoings as well as the authorisations of payments.

One problem for the department has been the size of the fleet owned by the company, which has grown in

magnitude as the company has expanded. The amount of vehicles now owned is quite large and since the

company has no computerised system it is becoming more difficult to keep track of when payments are due,

thus making cash flow analysis and budgeting decisions almost impossible. On top of this the company is

becoming susceptible to fines for late payments and legal penalties for late renewals of road tax and

insurance as well as M.O.T’s.

Some of the vehicles the company uses are through hire purchase contracts (where vehicles are hired out for

fixed periods of time and payments are made throughout the period. On completion of the period the

ownership of the vehicle passes to the company who hired the vehicle) or through contract hire agreements

(where the company hires out vehicles for fixed periods of time and payments are made throughout the

period for the use of the vehicle. On completion of the period the vehicle returns the vehicle to the hirer).

This brings about further problems, as the company is often imposed limits by the hirer’s. One such

imposition is a limit on the amount of mileage vehicles can do during the period and heavy fines are imposed

if the limit is exceeded.

A system is needed that calculates the average mileage allowed and the average mileage achieved for each

vehicle in such a contract as well as a message warning the user when the limit is exceeded. This warning

would allow the finance department to organise a change of drivers for the vehicles, which could be done so

as to reduce the mileage. The system is also required to store the vehicle details and inform the user when

payments are due.

The full list of database requirements is given, as a list of user needs in Appendix B; this has been produced

with the client and has been made possible through continual correspondence.

1.2 Project Solution

The choice of applications on which to design the database was fairly limited; it was between Quattro Pro 9,

Lotus Approach and Microsoft Access 2000 because these are the only pieces of database software, which

the company has on its system. In the end I have decided to use Microsoft Access 2000 because the company

is trying to remove the other pieces of software in favour of Microsoft products, which will help the

compatibility of documents between departments as well as preventing any problems with format changes,

for instance those associated with transferring documents from Microsoft Word onto Lotus WordPro.


The database produced will enable the company to store information relating to vehicles and drivers. This

information will be used to produce warnings and reports to ensure that late payments are not made and that

agreed mileages are not exceeded. The database will be form based and the input forms will be accessed via

a main form that acts as a menu and adds a user-friendly interface and functionality.

Once the database is completed a user guide will be produced and be included as part of the package.

1.3 Project Objectives

The following list of objectives needs to be completed in order for the final product to be produced to the

required standard:

• Project Design including:

- User needs and system requirements produced

- Entity Relationship and Data Flow diagrams

- Data dictionary

- Table design

- Form layouts

- SQL queries

• Project Development including:

- Creation of warnings and reports

- Production of a user friendly interface

• Project Testing including:

- Test plan and results

- Amendments to the development and design stage where necessary

• Project Evaluation including:

- User evaluation and possible improvement

- Project evaluation including problems

• Final product including:

- Fully working and user friendly database

- User manual to assist in the installation and use of the program

1.4 Project Deliverables

• Project report – This will include the design documents including user needs, system requirements,

ER diagram, constraints, tables, forms and queries. It will also include the research and testing

undertaken in order to produce the database.

• Fleet Management Database – This will allow the company to store all the necessary information

and manage the fleet of vehicles appropriately.


• User Guide – This will be produced to assist the user in using the database. It will aim at helping the

user to use the features created and will be of most use to the less computer literate user.

1.5 Project Schedule

There are four phases: design, development, testing and evaluation, which need completing in order to

produce a fully operational database that fits the user’s requirements.

The project will run from 1/10/01 to 1/5/02, which gives a total of 7 months (30 weeks, 3 days) in which to

allocate to particular phases. The most important and time consuming stage of the project is the design phase

since if it is done well it will make the rest of the project a lot easier to do, but if it is done badly the whole

database will take a lot longer to produce and will probably lack quality.

Most of the work done for the project will take part in the second semester because I have taken on more

modules and thus a heavier workload in the first semester. Therefore the schedule produced gives the early

stage of the project a lot of time so as to take account for the first semester work and exams.

The time available has been allocated as follows:

• Phase 1: Design = 17 weeks – 1/10/01 to 27/1/02

• Phase 2: Development = 7 weeks – 28/1/02 to 17/3/02

• Phase 3: Testing = 3 weeks – 18/3/02 to 7/4/02

• Phase 4: Evaluation = 1 week – 8/4/02 to 14/4/02

The time remaining will be used to solve any problems encountered and to write up the report.


2. Methodology

2.1 Consideration and selection of suitable development methodology

The following are examples of methodologies that could be adopted:

STRADIS (Structured Analysis, Design and Implementation of Information Systems): This methodology is

based on the philosophy of top down functional decomposition and relies on the use of Data Flow Diagrams.

YSM (Yourdon Systems Method): YSM is similar to STRADIS in its use of functional decomposition,

however a middle-out approach is adopted and slightly more emphasis is placed on the importance of data

structures.

MERISE : MERISE consists of three ‘cycles’, the decision cycle, the life cycle and the abstraction cycle.

The abstraction cycle is the key; in this cycle both data and processes are viewed firstly at the conceptual

level, then the logical or organisational level and finally at the physical or operational level.

SSADM (Structured Systems Analysis Design Methodology): SSADM adopts a prescriptive approach to

information systems development in that it specifies in advance the modules, stages and tasks that have to be

carried out, the deliverables to be produced and furthermore the techniques used to produce the deliverables.

SSADM adopts the Waterfall model of systems development, where each phase has to be completed and

signed off before subsequent phases can begin.

I decided to use SSADM because I have some knowledge of what it involves, whereas the others are more

unfamiliar. In addition to this the use of a disciplined ‘engineering approach should improve the quality of

the system.

2.2 Outline of development methodology

This methodology has many advantages and suits my project, as it requires each stage to be completed

before the next is started, for example the analysis needs completing before the design stage and so on.

One particular advantage of SSADM is that it combines techniques into a well-established framework, and

so, as well as providing techniques for the analyst; it provides guidance on how to use them.

In addition to this the methodology improves planning and control and reduced life cycle development

through improved analysis and design, it is also self-documenting.

SSADM revolves around the use of three key techniques:


• Logical Data Modelling: This is the process of identifying, modelling and documenting the data

requirements of a business information system. A Logical Data Model consists of a Logical Data

Structure (LDS - The SSADM terminology for an Entity-Relationship Model).

• Data Flow Modelling: This is the process of identifying, modelling and documenting how data flows

around a business information system. A Data Flow Model consists of a set of integrated Data Flow

Diagrams. DFD’s represent processes (activities which transform data from one form to another),

data stores (holding areas for data), external entities (things which send data into a system or receive

data from a system and finally data flows (routes by which data can flow).

• Entity Event Modelling: This is the process of identifying, modelling and documenting the business

events, which affect each entity and the sequence in which these events occur. An Entity Event

Model consists of a set of Entity Life Histories (one for each entity).

These three concepts can be crosschecked against one another and provide different views of the system.

SSADM does not cover the later stages of the life cycle, but the implementation and maintenance of the

system should be made easier by using the documentation provided in the analysis stage.

The structure of SSADM can be seen in figure 2.1 and this is what will be followed throughout the

development of the system [1].

(Figure 2.1) The Structure of SSADM

In the analysis stage I will draw up data flow diagrams and entity life histories, which will help create a view

of the system and allow a functional analysis to be drawn up. This will enable relational analysis to carried

out, I will create tables containing the required information, to represent the database at the logical level, and

ensure they are in 3rd normal form making the database function properly.

After the analysis stage the design stage will be undertaken, involving the design of the forms and the

necessary reports and queries. The design and analysis stages will help implement the system quicker and to

a higher quality.


3. Analysis

3.1 Data Flow Diagram

A Data Flow Diagram is a diagrammatic representation of the information flows within a system, showing:

• How information enters and leaves the system;

• What changes the information;

• Where information is stored

3.1.1 Components of a data flow diagram

External source/recipient:

An external source/recipient is whatever or whoever donates information to or receives information from the

system. These are represented on a Data Flow Diagram as follows:

Process:

A process transforms or manipulates the data within the system. Each process box contains the name of the

process, an identifier, and a possible location:

• The process name is an imperative statement, i.e. ‘do this’. It describes the processing performed on

the data received by the process.

• Process identifiers are numerical.

• The location might be a physical location, but is more often used to denote the staff responsible for

performing the process.

These are represented on a Data Flow Diagram as follows:


Data Store:

A data store is where information is held for a time within the system. These are represented on a Data Flow

Diagram as follows:

Data Flow:

A data flow represents a package of information flowing between objects on the Data Flow Diagram. These

are represented on a Data Flow Diagram as follows:

The data flow diagrams for the system can be seen in Appendix C.

3.2 Entity Life Histories

Entity Life Histories model the system from the viewpoint of how information is changed. What the Entity

Life Histories show is the full set of changes that can possibly occur to the information within the system,

together with the context of each change.

An Entity Life History is a diagrammatic representation of the life of a single entity, from its creation to its

deletion. The life is expressed as the permitted sequence of events that can cause the entity to change. An

event may be thought of as whatever brings a process into action to change entities.

The elements of the notation used in the diagram are as follows:

• Sequence: the boxes read from left to right.

• Selection: the boxes with small circles in the top right corners are alternatives for one another.


• Iteration: the boxes with the asterisk in the top right corner represent an iteration, which can occur

zero to many times.

The Entity Life History Diagrams for the system are in Appendix D.

3.3 Functional Analysis

A functional analysis builds a model of what the system does, or should be doing at the conceptual level. The

emphasis is placed on the processes, functions and the operations that the data must support. Producing a

functional analysis will help identify what controls are needed in the application.

The functional analysis has been identified using the user needs and data flow diagrams as well as additional

details provided by the user.

In addition to the functional analysis a set of system requirements, which are orientated towards the

implementation of the functions (and can be traced back to the user needs), have been created.

The system requirements and the functional analysis are in Appendices E and F.

3.4 Database Integrity Constraints and Validation rules

Validation Rules

Validation rules are often very simple checks, for example that a product code is on the format ‘PNNN-

NNN’, or that a mark is between 1 and 100 [8].

In Access the validation rule property can be set to specify requirements for data entered into a record, field

or control. The Access definition reveals that validation can be defined at more than one level, at the level of

a single data item (field), a single record, or at the level of a control. So there are several places where

Access validation rules can be defined.

Integrity Constraints

These are validation rules that are defined at the data level, rather than at the application level. These prevent

data, which violates the constraints from being entered into the database, no matter how the data entry is

attempted.

In general we classify integrity constraints according to whether they are defined at the level of: fields,

relations or database [8].

3.4.1 General Form of a constraint

A constraint specification language should allow specification of:


1. The conditions that all correct states are required to satisfy;

2. The events which trigger consistency checking;

3. The actions to be taken when the constraint is violated.

3.4.2 Attribute constraints

These constraints specify the domain from which the attribute takes its values.

The conditions that all correct states are required to satisfy are given in the data dictionary in Appendix G.

The information includes the data types of the attribute, the format the attribute must be in (or size of the

attribute) and any individual validation rules that the attribute must conform to.

The consistency checking is triggered when a field on a form is filled in or updated. When a constraint is

violated an error message will appear, or invalid input is prevented (such as entering characters into number

fields).

3.4.3 Relation constraints

These constraints apply to a single relation.

The constraints that have been created to ensure that certain data is required to be entered before a record is

saved are dealt with in the data dictionary in Appendix G.

The rest of the constraints will be implemented using Visual Basic for Applications (VBA) and will be run

when the relevant fields are exited.

Driver Table constraints

1. The expiry date of a license must be greater than the date the driver passed their test (Expiry_date >

Pass_date)

Note: A driver’s license can be checked even though they have not passed (may have a provisional license)

and a driver may be banned even though they have not passed their driving test (they may have been driving

without a license previously).

Vehicle Table constraints

2. A vehicle cannot be due for an MOT and a goods vehicle test. For instance a car would have an MOT, but

not a goods vehicle test (MOT_date OR Goods_vehicle_test_date).

3. A vehicle cannot be due for a service prior to the company obtaining it, and therefore the service due

mileage cannot be less than the initial mileage (Service_mileage >= Initial_mileage).


Vehicle History Table constraints

4. A driver cannot stop using a vehicle before he has started to use it (End_date >= Start_date).

Contract Hire Table constraints

5. A contract cannot end before it has begun (End_date > Start date)

The relations are required to satisfy the constraints above and if this is not the case then an error message

will be output. The consistency checking is triggered when the relevant fields are exited.

The codes for these constraints are in Appendix H.

3.4.4 Database constraints

These constraints compare the values in one relation to values in another and therefore are likely to need

extra disk accesses, which affects performance on update.

The events that trigger the consistency checking for these constraints are the adding or updating of records

and when a constraint is violated an error message appears prompting for valid data.

These types of constraints are not to be implemented in this database because none have been identified that

will improve the working of the system.


4. Design

4.1 Entities and Attributes

The functions required from the application include recording details of drivers, vehicles, hire purchase

agreements and contract hire agreements as well as viewing, printing and amending this information. This

leads to the identification of four entities; drivers, vehicles, contract hire vehicles and hire purchase vehicles.

A number of additional entities may also become apparent during the normalisation stage that follows.

The data that is required to be stored is shown below and is taken from the user needs (See Appendix B):

• Driver – Name, License Type, License Start Date, License Expiry Date, Penalty Points, License Check

Date, Ban Expiry Date, Disabilities, Training Date, Course Name, Training Details, Training Notes,

Offence Date, Offence Details, Punishment, Offence Notes.

• Vehicle – Registration No, Make, Model, Engine Size, Fuel Type, Emissions Level, MOT Due Date,

Service Due Date, Service Due Mileage, Tax Expiry Date, Insurance Due Date, GV Test Date, Insurance

Payer, Initial Mileage, MOT Date, MOT Mileage, Service Date, Service Info, Service Mileage, Fuel

Date, Amount, Fuel Mileage, Tyre Rep Date, Tyre Rep Mileage, Tyre Rep Reason, Repair Date, Parts

Repaired, Repair Reasons, Accident Date, Accident Details, Accident Blame, Insurance Paid, Driver,

Date Driving From, Date Driving To.

• Hire Purchase Vehicles – Registration No, Contract Start Date, Payment Date.

• Contract Hire Vehicles – Registration No, Contract Start Date, Contract End Date, Initial Mileage,

Mileage Allowed, Payment Date.

4.2 Normalisation

4.2.1 Reasons For Normalisation

Normalisation is the process of splitting up tables into a larger number of narrower tables in order to design a

database that is free from anomalies such as those relating to updating, deleting and inserting.

There are also many other benefits of normalisation including:

i) Faster sorting and index creation because tables are narrower;

ii) More clustered indexes are allowed because there are more tables;

iii) Narrower and more compact indexes;

iv) Fewer indexes per table, helping INSERT, DELETE, and UPDATE performance;

v) Fewer Nulls and less redundant data, increasing database compactness.


4.2.2 Normal Forms

First Normal Form (1NF)

Any relation with atomic values in each of the relation ‘cells’ is in 1NF. Therefore 1NF rules out multi-

valued attributes.

Second Normal Form (2NF)

For a relation to be in 2NF it must be in 1NF and there must not be any trivial dependencies.

(A� …An -> B such that the left hand side is a subset of a key, unless B itself is a member of some key.)

Third Normal Form (3NF)

A relation, R, is in 3NF if and only if:

Whenever there is a non-trivial dependency, A� …An -> B for R, it is the case that either {A� ,…An} is a

superkey for R, or B is a member of some key.

When the relations are in 3NF then anomalies do not exist. Therefore if the tables are created so that they are

in 3NF, the anomalies will be avoided and the tables will be normalised thus improving performance.

4.2.3 Normalisation Technique

To ensure relations are normalized we can follow four steps of normalisation suggested by [1] as follows:

1. Represent the data in un-normalised form and pick a key.

2. Represent the data in First Normal Form by removing any repeating groups of data items to separate

relations. Pick keys for relations identified. (Repeating groups of data items are those items that can

have more than one value for each value of the primary key).

3. Represent the data in Second Normal Form by removing any data items that only depend on part of

the key to separate relations. Pick keys for relations identified.

4. Represent the data in third normal form by removing any data items not directly dependent on the

key to separate relations. Pick keys for relations identified.

The normalisation table resulting from this process is in Appendix I.


4.3 Entity Relationship Diagram

The identification of the Entities has enabled an entity relationship diagram to be produced. The relationships

created follow database rules namely, the referential and integrity rules.

The Entity Integrity Rule states that no part of a primary key can be null. This is applied in Access by setting

the required property in the primary key property settings to yes when constructing the tables.

The Referential Integrity Rule states that if a table, R2, includes a foreign key, Fk, matching the primary key,

Pk, of some base table, R1, then every value of Fk in R2 must either be:

a) Equal to the value of Pk in some row of R1 or

b) Wholly null.

This is applied in Access by setting the following relationship options:

1) Enforce Referential Integrity: This function prevents the user from inputting a value into the

foreign key field of the related table that does not exist as a primary key in the original table.

2) Cascading Deletes: This function acts when a record is deleted; it deletes all the related

records.

3) Cascading Updates: This function acts when a record is updated; it updates all the related

records, such as those with foreign keys equal to the primary key of the record that was updated.

The system will implement all these options within each relationship.


(Figure 4.1) Entity Relationship Diagram – Taken from Microsoft Access 2000

Note: The names of the tables and attributes may differ from those used earlier, this is because the names

used earlier were longer and more descriptive to help in the design process whilst the table names have been

made shorter to enable SQL queries to be shorter in terms of words and easier to follow.

4.4 User Interface Design

The main function of the system is to allow the user to input details and obtain certain data when required.

To ensure this is made as easy as possible the systems interface needs to be designed appropriately.

Nielsen’s (1993) guidelines can be followed to ensure an appropriately designed user interface:

1. Simple and natural dialogue: Reduce text to a minimum; match the users task; present what is

needed, and no more. For graphic design parts cluster like items and prioritise the important using

bold face colour and capitals. Don’t over use colour, use it to differentiate not quantify. Don’t over

provide or under provide options.

2. Speak the users language: Use vocabulary the user will understand. Metaphors can help provide a

general mapping between a users conceptual model of the interface and the way computer systems

displays information.

3. Minimise user memory load: Base interaction on a small number of rules that appear everywhere,

provide explicit guidance for textual inputs (e.g., the input format of a date).

4. Consistency: Keep it the same if it does the same thing. Maintain appearance, position, format and

function. Keep interfaces consistent between as well as within applications because this helps users

to learn and remember how to use applications.

5. Feedback: Keep the user informed about what is going on. Provide a warning before irreversible

operations are performed.

6. Clearly marked exits: Every dialogue should have an escape route.

7. Shortcuts: Particularly beneficial to expert users.

8. Good error messages: Use clear language and precision, assist in recovery from the error and do not

intimidate – try to avoid words such as illegal and fatal.

9. Prevent Errors: Many error scenarios are predictable and can be programmed out –e.g. spelling

errors in anticipated words can be avoided via menu selection.

10. Help: Users don’t use help systems. When they do, they are in serious difficulty. On line help is

always available. Balloon help can be used to provide small amount of information.

In addition to these guidelines Shneiderman’s eight golden rules of interface design have also been looked

into for extra assistance in the interface design [10].


On top of these guidelines there are a number of additional aspects that need to be taken into account.

The user will want the display to be aesthetically pleasing. Therefore colour needs to be used wisely and it

may be best to avoid red-green combinations as well as brown-red combinations due to colour blindness,

which occurs in some individuals. In addition to this colour pairings such as red and blue should be avoided,

since they are at the opposite ends of the colour spectrum and this makes it difficult for the user to absorb the

information. The contrast of colours also needs attention, because a colour scheme with too little contrast

such as yellow on white will be difficult to read. The colour blue should also be avoided because a lot of

people find it difficult to perceive the colour blue [9].

A number of techniques can be used to get the users attention, although they must be used carefully so as not

to clutter up the display. For instance the intensity level, size and colour of text can be altered.

Menus should be used where possible since they have the advantage that users do not have to remember the

items they want, they only need to recognise them. In addition the user will want to minimise the number of

interactions necessary to perform a task, so the menu needs to be created that reduces the amount of

traversing required to get from one option to another.

After taking Nielsens and Shneiderman’s guidelines into account as well as the other general concepts, the

following will be implemented.

The colour scheme that will be used for the menus will coincide with the company’s badge, which

incorporates yellow, red, white and black. These colours when used together do not compromise any of the

guidelines discussed, and the brighter colours will be used carefully so as not to overwhelm the interface.

The text colour will be black because it is easy to read and stands out on the background. The overall

background colour will be white to ensure all the labels and controls stand out. The forms will be quite plain,

white with black text so as not to overload the user’s memory with information.

The same controls will be used on different forms to ensure consistency, and where possible the placing will

be the same, where not possible they will be placed in the same logical order. Labels will be used next to

controls to help recognition, the users will then be able to learn what the controls do and then once learnt

they can be recognised form the picture embedded onto the control button.

The feedback obtained from the system will be visual, after a button is clicked the action is performed, other

than that there is no feedback necessary.

The operations within each form, will be ordered logically, so the first operation will be add record, followed

by delete, then print and finally close form. This is because a user will have opened the form to add a record

or delete one, next a record may be printed and the last operation will always be to close the form.


Validation rules are implemented within the system and where possible custom validation text has been used

to cut out as much as possible of the default Access help, which is most of the time not all that helpful. These

messages will basically state what has been done wrong or what needs to be done in simple terms i.e. Please

input the make of the vehicle.

To reduce short-term memory load window-motion will be removed or reduced on multiple page forms and

the interface will be simple.

The text used on the forms will be kept to a minimum only displaying necessary information such as the

name of the controls and names of the operations. White space will be used between groups of controls on

menus and forms to ensure they are distinguishable from one another and the number of images will be small

so that the process of loading the page is not slowed down to unacceptable levels.

Where possible metaphors will be used on the controls, for instance a trashcan will be used to represent the

delete operation and an open door will be to represent the exiting of applications.

To minimise user memory load the format of dates will be set to dd/mm/yyyy, to reduce the user requirement

to remember things, on top of this drop down lists will be used where possible, such as for the fuel type,

license type, the insurance payer and when viewing records, this will also help prevents errors. Choosing the

appropriate data type for each field to ensure that no text is input into numerical fields will also prevent

errors.

Exit buttons will be provided on each form and be clearly marked so the user can always get out of the

application.

The application will have a main menu where most operations can be reached quickly, as well as having a

sub menu that contains the reports that can be printed. This will ensure that the user will not need to many

interactions to perform any of the tasks. When a new record is added the focus of the cursor will be set to the

first field on the form to save the user having to use the mouse to select the field and then move to the

keyboard to start inputting the details.


5. Implementation

5.1 Tables

The data dictionary for the tables can be seen in Appendix G. It shows the names of the tables, and for each

table shows field names, data types, format/sizes and any validation rules.

The tables were created in Microsoft Access 2000’s design view, and dummy data was entered throughout

the implementation stage to check the functionality of the tables.

5.2 Forms

The forms were created straight from the tables again in design view. A lot of the tables are closely related,

for instance there are vehicle, MOT, Insurance, Accident, Repair, Fuel, Tyre and History tables, which are

linked, therefore these have been combined together onto one tabbed form. The tabbed forms that have been

created will make it easier for the user to view any details in any order, all it takes is a click of the mouse on

the appropriate tab rather than having to close the active form and opening a new one.

All four forms have been created using tabs for consistency as well as to create easier access to data.

The coding behind the buttons is in Visual Basic for Applications and can be viewed by looking at the ‘event

procedure’ in the properties box.

The tab order of the fields on the forms has been set up to follow the logical order of input and to avoid any

unnecessary surprises.

The rules defined in the previous chapter regarding design of the user interface have been followed as much

as possible.

Main Menu

This is the screen that appears when the database is open, and allows the user access to each of the functions

by clicking on the appropriate button. The buttons have been ordered so that like operations are together,

with the add forms down the left and the amend forms down the right. The check warnings button is used as

a quick check on payment expiry dates such as MOT due dates, it runs through all the warnings that the user

requested. This saves time, as the user does not have to view each individual report to find the same

information. The user can then view and print any reports where details were output on the warnings. The

warnings are run via a macro that runs each of the relevant queries in turn. The reports are located by

clicking on the reports menu button. User help is accessed via the F1 button on the keyboard.


(Figure 5.1) Main Menu

Add Driver Details

This form is used to add driver details, driver training details and driver offence details. The form has been

designed to allow easy access to all the driver related details. The unique identifier for the table behind this

form is omitted since it is automatically updated and bears no relevance to the driver (the same applies to all

primary keys that have no relevance). The licence is selected from a drop down list, which are used where

possible to reduce the users memory load. The form is opened by a macro, as are all add forms.

(Figure 5.2) Add Driver Details Form


View/Amend Driver Details

This form is the same as the add driver details form, this is because it makes it easier to fix bugs when only

one form will need altering. The only difference between the forms is that this form opens in edit mode

instead of add mode. The driver is selected from a combo box on an additional form as shown in figure 5.3.

(Figure 5.3) Find Driver Form

Add Vehicle Details

This form is used to add vehicle details including the basic details and historical details. The form opens on

the vehicle tab, which allows the user to add basic details such as registration number, make and model. The

user can then add other details by clicking on the appropriate tab from the top of the form. The top of the

form displays the registration number of the vehicle at all time to ensure the user always knows which

vehicle they are currently dealing with. The forms tabs make it easier to locate details quickly without the

needs to go through various menus. It also ensures that the registration number of the vehicle doesn’t need

selecting when other details are added as it is automatically selected via the vehicle form when it is opened.

(Figure 5.4) Add Vehicle Form


View/Amend Vehicle Details

This form is the same as the add vehicle form but opens in edit mode. The vehicle is selected from a

combo box, which lists all the vehicles stored in the database. The selection form is shown in figure

5.5, and allows quick access to the required vehicles details.

(Figure 5.5) Find Vehicle Form

Add CH Vehicles

This form is used to record vehicles which are part of contract hire agreements, the registration number of

the vehicle is selected from a list and then the details can be input, including the payment dates that are input

on a separate form found by clicking on the payment dates tab.

(Figure 5.6) Add Contract Hire Vehicle Form

View/Amend CH Vehicles

This form is the same as the add contract vehicle form except that it is opened in edit mode. Again the

vehicle to be viewed or amended is found through a find vehicle form shown in figure 5.7.


(Figure 5.7) Find Contract Hire Vehicle Form

Add HP Vehicles

This form is used to record vehicles which are part of hire purchase agreements, the registration number of

the vehicle is selected from a list and then the details can be input, including the payment dates that are input

on a separate form found by clicking on the payment dates tab.

(Figure 5.8) Add Hire Purchase Vehicle Form

View/Amend HP Vehicles

This form is the same as the add hire purchase vehicle form except that it is opened in edit mode. Again the

vehicle to be viewed or amended is found through a find vehicle form.

(Figure 5.9) Find Hire Purchase Vehicle Form


Report Menu

This menu is located by clicking on the report menu button on the main menu and allows the users to view and print each of the reports, by first on the appropriate reports button. The back to main menu button allows the user a quick way to get back to the main menu.

(Figure 5.10) Report Menu

State Transition Network Diagram

The state transition network below shows the relation between the main forms only to ensure that the

complexity is minimised. Producing a hierarchical STN would increase the complexity.

(Figure 5.11) System State Transition Network Diagram


Screen shots for the forms under each of the tabs can be found in Appendix J.

5.3 Queries

The queries that have been necessary to produce the appropriate warnings have been identified from the user

needs; the queries are listed below:

• Tax Query – Produces a list of vehicles, which have tax due in 2 weeks, 1 week or less than a week.

• MOT Query – Produces a list of vehicles, which have their MOT due in 4 weeks, 3 weeks, 2 weeks,

1 week or less than a week.

• Goods Vehicle Test Query – Produces a list of vehicles, which have their goods vehicle test in 4

weeks, 3 weeks, 2 weeks, 1 week or less than a week. .

• Insurance Query – Produces a list of vehicles whose insurance is due in 4 weeks, 3 weeks, 2 weeks,1

week or less than week.

• Service Query – Produces a list of vehicles that have a service due in 2 weeks, 1 week or less than a

week.

• Service Mileage Query – Produces a list of vehicles that are 1000, 500 or less than 500 miles away

from a service.

• Hire Purchase Payment Query – Produces a list of vehicles that have payments due with regards hire

purchase agreements on the current day.

• Contract Hire Payment Query – Produces a list of vehicles that have payments due with regards

contract purchase agreements on the current day.

• Last Hire Purchase Payment Query – Produces a list of vehicles that have their last payments due

with regards hire purchase agreements on the current day.

• Last Contract Hire Payment Query – Produces a list of vehicles that have their last payments due

with regards contract purchase agreements on the current day.

• Contract Hire Expiry Query – Produces a list of vehicles whose contract expires on the current day.

• Contract Hire Mileage Query – Produces a list of vehicles that are under contract hire agreements

and have an average mileage over the allowed average mileage.

• Banned Query – Produces a list of drivers whose driving ban expires on the current day.

The SQL code is in Appendix K.

5.4 Reports

The reports that have been necessary have been identified from the user needs; these reports are listed below:


• Tax Report – Displays all the vehicles output in the tax query with the days till their tax is due.

• MOT Report – Displays all the vehicles output in the MOT query with the days till the MOT is due.

• Goods Vehicle Test Report – Displays all the vehicles output in the goods vehicle test query along

with the number of days till the goods vehicle test.

• Insurance Report – Displays all the vehicles output in the insurance query along with the insurance

payer, the current driver and the number of days till the insurance is up for renewal.

• Service Report – Displays all the vehicles output in the service query with the days till the service is

due.

• Service Mileage – Displays all the vehicles output in the service mileage query along with the

number of miles till the service is due.

• Hire Purchase Payment Report – Displays all the vehicles output in the hire purchase payment query

along with the date of the last payment.

• Contract Hire Payment Report – Displays all the vehicles output in the contract hire payment query

along with the date of the last payment.

• Contract Hire Mileage Report – Displays a list of the contract hire vehicles along with the average

mileage allowed by the contracts and the actual average mileage.

• Fuel Consumption Report – Displays a list of the vehicles with their fuel consumption per litre.

• Accident Report – Displays a list of the drivers that have had accidents along with the number of

accidents they have had.

• Tyre Replacement Report – Displays a list of drivers that have had tyres replaced along with the

number of times they have had tyres replaced.

The SQL code is in Appendix K along with the code for the queries. Sample outputs from these reports are

available in Appendix L.

5.5 User Help

Windows help

This help system uses topics that are linked together to form a web that enables a user to travel from one

related topic to another with relative ease.

Each topic can be linked to a form or control to provide instant access to the topic when the user presses F1

while the control or form is in focus.

Help systems can consist of simple linked text topics, or they may contain graphics or multimedia to help

educate the user, in addition the following features are also available:

• Help topics shortcut menu: when a user right-clicks on a Help window a shortcut menu appears.

• Full-text search engine: the user can search for all the text in each topic.


To create a Windows help system you first need to create a contents file and then create topics in a word

processing application. The next step involves defining keywords, followed by adding topics to a browse

sequence (the order in which the topics are designed to be viewed).

After these tasks have completed Help Workshop is used to create a new project file. The Help Workshop is

then used to customise your help project and enables you to put together al the topics into a comprehensible

help package [7].

HTML Help

Microsoft HTML Help Workshop is an executable program designed to help create help systems using

source files based on HTML. With HTML Help Workshop, you can create help systems for distribution with

a software program or as stand-alone systems on the web.

HTML Help Workshop allows you to organize the different files that make up the content of your help

system into a single project (.hhp) file, and to author HTML files with a text editor. It also allows you to

create and edit contents (.hhc) and index (.hhk) files, add graphics (.gif, .jpeg, .png) files, and insert the

HTML Help ActiveX control (the primary navigation tool in HTML Help) into HTML files.

HTML Help Workshop includes the HTML Help compiler allowing you to compile, view, and test any

changes made to the help files.

Choice of help system

Both systems are similar and provide the same functions, the only difference being that the html help uses

HTML files rather than text files. It is more difficult to link an html help file to an application than it is to

link to a windows help file. I chose to implement a windows help system since the difference in appearance

is negligible so it would be wiser to choose the slightly easier option.

The process of creating the windows help involved:

• Creating Topics in Microsoft Word and saving in rich text format

• Creating Topic Titles

• Creating Topic Ids

• Defining Topic Keywords that are used to search with the index button

• Creating a browse sequence

• Specifying a topics window

• Adding graphics to Topics

• Using Help Workshop to create and compile a project file

• Creating a contents file

• Integrating the help file with the application using the Help context ID property.


A number of screen shots for the Windows help system that has been created are in Appendix M.

A user guide has also been created in Microsoft Word for distribution with the database system this can be

seen in Appendix N. This guide has almost identical information to that found in the on-line help, although

the on-line help is more specific to the situation he user is in i.e. the information provided in the help relates

to the form the user is viewing.

5.6 Security and Maintenance

There are three different types of passwords that can be implemented in Access, with each one providing a

different type of defence from unauthorised users [7].

Database Passwords

If a database password is set then all users must enter that password before they are allowed to open

the database. Adding a database password is an easy way to prevent unwanted users from opening

the database; however, once a database is open, no other security measures are provided unless

user-level security has been defined as well. If you have user-level security defined for your

database, you can prevent users from setting a database password.

Security Account Passwords

The second kind of password is called a "security account password" and is only used when user-

level security has been defined for a workgroup. A security account password is created to make

sure that no other user can log on using that user name.

Users can create or change their own user account passwords; however, only an administrator

account can clear a password if a user forgets the password.

Visual Basic for applications (VBA) Passwords

The third kind of password is called a Visual Basic for Applications (VBA) password. This password is used

to protect VBA code in modules and modules behind forms and reports. This password prevents

unauthorized users from editing, cutting, pasting, copying, exporting, and deleting VBA code.


MDE Databases

Another way to ensure the security of the applications code, forms, and reports is to distribute the database as

an .MDE file. When saving a database as an .MDE file, Access compiles all codes and modules, removes all

editable source, and compacts the database. The new .MDE contains no source code but continues to work

because it contains a compiled copy of all the code. In addition to not being able to view source code, end

users cannot do any of the following to an .MDE database [7]:

• View, modify or create forms, reports or modules in design view.

• Add, delete or change references to object libraries or databases.

• Change the database’s VBA project name using the Options dialog box.

• Import or export forms, reports, or modules.

The problem with a .MDE file is that it cannot be converted into a normal database file, therefore if problems

are found or the database needs upgrading then the original copy would have to be altered and then

converted to a .MDE file for use, which may mean losing the data stored within the original .MDE database.

Security Choices

The security level for the fleet management database does not need to be very high; only the accounts

department will use it. The only bits of sensitive information relates to the drivers personal information.

There is no reason why any unauthorised user would want to gain access to the database, as there is not much

they can do to cause problems. The paper documents relating to vehicles are to be used in parallel with the

database.

There is also no problem if two users view the database with the same password, so it is sufficient to create a

database password, which only the relevant staff know, i.e. the accounts manager and any of his staff that he

appoints to use the database. The password prompt screen is as follows:

(Figure 5.11) Password Screen

To prevent users from mistakenly modifying or deleting objects the interface elements that allow changes to

objects will be hidden from the user, for instance making it impossible for the user to gain access to the

database window. Instead the application will open with a start-up form, which only allows them to use the


forms and reports created. On top of this a VB password will be implemented as an additional safeguard

against the altering of the code, this password will only be given to the accounts manager.

This will prevent the user from accidentally changing the code without having the restrictions and hassle

imposed by an .MDE file. The user can open the database in design mode by holding down shift while

opening the database (but will still have to input the passwords), this allows the flexibility of being able to

alter the database in any way as well as providing the protection from any of the users altering the code. This

will allow the user to alter the database without losing any data, as is the case with an .MDE database.

These measures should provide enough security as is really necessary; it protects from unauthorised users

and prevents any of the coding from being accidentally changed.

Backups

The system is to be backed up every evening after the end of the working day. The simplest way to achieve

this is to add the database to a zip file and copy it to floppy disk. The disk can then be taken home with the

user to ensure that the backup and the original are kept apart. A copy of the database is to be stored at the

users home at all time; this will be achieved by having 2 disks with which to backup the database.

This method of backup is the most appropriate for Wright (Hull) Limited because it does not require them to

purchase additional hardware, such as CD writer or a zip drive, and it is simple to do.

General Maintenance

The database is to be run each morning by a member of staff in the accounts department. The payment dates

will be checked using the check warnings function to see if anything needs immediate attention.

The continuous update of the system is to be done by a member of staff in the accounts department, it is to be

done at the beginning of the week when the fuel cards come in from the drivers and after each due date is to

be updated, for instance when a warning appears about renewing insurance then the insurance will be

renewed then the records will be updated on the database. In addition to this when a vehicle has an accident

the accounts department are told, since they are responsible for payments and at this point the details will be

fed straight in to the database.

The database can also be run at any time by any of the members of the accounts department to check details.

5.7 Deployment

The database is to be handed to the company on a compact disk, which can be installed straight on to their

system. In addition to this the user will be provided with a paper copy of the user guide.


6. Testing

6.1 Introduction

To ensure that the database has no data entry errors the test plan below will be undertaken. This plan is in

three stages, the first stage deals with checking the individual fields on the forms to ensure that they accept

the correct data and prevent invalid or improper data being entered where possible.

The second stage deals with ensuring that the full forms work, and that the data input for a particular form is

valid before the form can be saved.

Then valid data will be input to test the reports in the third stage to ensure that the correct data is output.

6.2 Field Testing

The field-testing involves testing each field within the forms to ensure that only valid data can be entered.

The fields with no validation rules, integrity constraints or any unallowable data will not be tested. For

instance text fields will not be tested since the only validation they include is the number of characters

allowed, but it is not vital that the limit is not exceeded.

Each entry of data should be taken in isolation in this section.

The field-testing data along with the results are in Appendix N.

6.3 Form Testing (or Relation Testing)

This section deals with the validation rules constraining fields within forms, for instance a license cannot

expire before it has been started. Each of the relation constraints will be tested individually; to do this it is

only necessary for the individual fields in question to be tested.

The form testing data along with the testing results are in Appendix O.

6.4 Reports and Query Testing

The reports and more generally the queries underlying them will be tested next. This is to be done by adding

a number of records to the database (starting with an empty database). The data will have particular

characteristics that ensure some results are output for each report. After the data has been input each

report/query will be run and the results checked against what was expected.

The input data is in Appendix P and the expected and actual results from the tests are in the Appendix Q.


7. Summary and Evaluation

7.1 System Evaluation

After the analysis section a set of functional requirements were created. In order to evaluate how the system

performs functionally these requirements need to be analysed to see if they were met. Below is a brief list of

the types of functions the user wanted the system to provide; the full functional requirements can be found in

the Appendix F.

• Driver Functions: The system allows the user to add and remove drivers, record training and offence

details as well as view, update and print driver related details.

• Vehicle Functions: The system allows the user to add and remove vehicles, record vehicle details

such as fuel purchases, as well as view, update and print vehicle related details.

• Lease Vehicle Functions: The system allows the user to add and delete lease vehicles, record lease

payments as well as view and update these details.

• Report Functions: The system provides all the reports required including fuel consumption reports

and lease payment reports and allows these reports to be printed.

• Warning Functions: The system provides the warnings required and allows then all to be run

sequentially with one click of a button.

All the requirements have been fulfilled within the final application; the user can perform all the tasks

required.

An important part of the system is the user interface, which has been designed using Nielsen’s guidelines and

Shneiderman’s rules, the interface can thus be evaluated by comparing against a set of these guidelines. I

have decided to evaluate the system in terms of Nielsen’s guidelines as outlined below:

11. Simple and natural dialogue: The text used has been the minimum possible, the functions have

been described with as little text as possible, abbreviations understandable to accounts staff has been

used where possible, such as CH for contract hire. The functions provided have matched what the

user requires no more and no less. Colour has been used carefully with the menus only using three

colours but still standing out appropriately. The buttons provided that perform the functions were

made quite large so that they are clearly visible, which would be an advantage for a less computer

competent user.

12. Speak the users language: Icons have been provided for the functions to assist the users, a trashcan

has been used for the delete functions and an exit door for exit applications, these metaphors will

help the users understanding.


13. Minimise user memory load: The forms have been created to be plain with black writing and space

between the controls, so as not to distract the user and to minimise the users memory load. In

addition to that date formats have been provided to show the user what format the date’s need

entering ensuring they only have to type the numbers. Where possible drop down lists have been

used such as for the types of fuel and license types.

14. Consistency: All the forms have been created the same with the identical colour, same layout of

functions and all with tabs at the top. The menus have also been created to the same format. The

layout of the controls is the same on each form.

15. Feedback: The feedback provided to the user is the text that appears on the screen as the form is

filled in showing the user what was input. In addition to this a warning appears when records are to

be deleted asking the user if they are sure they want to delete the record, there is a similar warning

when the user quits the application.

16. Clearly marked exits: The exits from each form and menu are clearly visible at the bottom of the

form marked with text and an open door icon.

17. Shortcuts: No shortcuts have been provided because all the functions are easily and quickly found

without much interaction. The shortcuts that access provides are available to the user and they

should suffice for any user of the system.

18. Good error messages: The error messages provided have been designed to fit each error, the errors

that could occur are those to do with invalid input, the error message that appears has been created to

be as user friendly as possible and describes what the user has done wrong and what should be done

to correct the problem.

19. Prevent Errors: Menu selections have been used where possible to prevent spelling errors and the

format and type of each field has been provided to prevent errors as much as possible.

20. Help: Help has been provided in two ways. The first method is a paper copy of the user guide,

provided because many individuals prefer to read from paper than from a screen. The second help

provided is a on-line help which can be accessed at any time within the application by pressing the

F1 key, the help that pops up relates to the form or screen that the user is currently viewing. In

addition to this control tip help has been implemented, this enables text to be displayed when the

cursor hovers over controls. This text simply states what the control does, such as ‘open form’.

The system stands up well against Nielsen’s guidelines therefore the system provided has been designed well

and achieved what was required, it is user friendly and is easy to use and perform the functions required.

This system is an improvement on the paper-based that was previously used. Data loss should be minimised

and information can be retrieved easily.

There are a couple of problems with the system, including the fact that the fuel consumption is calculated for

each vehicle and not for each driver, which in hindsight may have been a useful addition. Another problem is

that when help is requested on the main menu the on-line help goes straight to the introduction, instead of the


main menu help, this is because the main menu is the first screen accessed by the user and they may want

general assistance when they first use the system. The obvious problem being when they want help on the

main menu they have to press the F1 key followed by looking in the contents for the appropriate page.

In conclusion, the system meets the user requirements and the interface has been designed well making the

functions as easy to perform as possible.

7.2 Problems encountered

There were a number of problems encountered during the production of the system. One of the most costly

problems was to do with the creation of the tabbed forms. On completion of the forms it was found that the

sub forms found under each tab were not linked and the link child field and link master field property setting

wouldn’t take values. In addition when data was entered using the form it couldn’t be view using the form it

could only be seen by looking at the table. This was solved by going back to basics and starting the form

from scratch to get the functionality working before the appearance.

A lot of time was also wasted creating and customising a main switchboard. In reality only one switchboard

could be used, since every subsequent switchboard took the same format as the first, with the same number

of buttons and same bitmaps on the buttons. Since the system required a main menu and a sub menu this was

not acceptable so I settled in creating menus out of forms.

The SQL queries that needed to be created were a lot more complex than first anticipated and involved

joining a large number of tables and on occasions needed two queries to solve the problem.

The validation rules behind forms needed continuing amendment as some of them were not working due to

incorrect syntax or because they were non-existent.

7.3 Future Development

The system could be easily expanded in the future to account for new regulations or links to appropriate

Internet sites could be added, for instance the web sites of insurance companies or vehicle hiring companies

when payment is accepted through in that manner, or even just to see information relating to the companies

Wrights (Hull) Limited deal with.

Including employee details to help with payroll could also expand the system. To achieve this additional

features could be added to the driver details form to converting it to an employee details form.

There are a number of other ways in which the system could be developed, which will only become apparent

when the system has been in use for a long period of time.


7.4 Previous Knowledge

The initial meeting with the user allowed me to create only a brief list of what was required, but allowed me

to go away examine the information and return to the user with questions relating to these requirements.

Knowledge that I have gained from the other half of my degree programme, Accounting, has assisted me

greatly in this project by allowing me to know what was required from large parts of the system without

being explicitly told.

The user wanted to store information relating to lease contracts and I knew that there were two types of

agreements available, contract hire and hire purchase, allowing me to account for this in the design and go

back to the user to ensure the company needed to account for both. The information stored for each of these

agreements is different because the same information is not relevant for both.

A hire purchase agreement is where a company leases a vehicle for a period and then at the end of the lease

period (after the last payment) the vehicle becomes part of the company’s assets. Therefore the transfer of

ownership would be at the last payment date and therefore a separate end of contract date would not be

needed, also no restrictions on mileage during the lease are imposed since the vehicle is classed as the

lessee’s assets when the contract begins.

A contract hire agreement is where a company leases a vehicle for a period at the end of which the vehicle

returns to the owner. Therefore the last payment date is unlikely to be the same date as the contract ends

since payments are usually in advance, so the contract end date needed to be stored, and since the vehicle

goes back to the leasing company after the agreement expires mileage limits may be imposed so need to be

accounted for.

In addition to the lease vehicles my knowledge about taxation has helped because when I was told details of

vehicles were required I had to decide which details would be important. I knew that the make and model of

a company’s vehicles has to be given to the Inland Revenue and that the tax that needs paying regarding a

vehicle is affected by its engine size and levels of carbon dioxide emissions (since around 1998), therefore I

knew that these details would be useful to the company.

This knowledge made the job of converting the requests from the user into relevant data and helped me to

understand how a lot of the information was to be used.

7.5 Company Feedback

Wright (Hull) Limited have used the system for a couple of weeks and a letter from them with some

feedback is available in Appendix S.


Appendix A) Reflection This project was the largest I have ever undertaken, so everything I did allowed me to learn more about working alone, under pressure and to a deadline that is a long way in the horizon. I have gained a great deal of experience in time management through completing this project, which

has been done over a full university year and since it is worth quite a large chunk towards my final

grade has involved a lot of work. It has been important that I did not leave the work till the last

minute to ensure that enough time was available to complete the project successfully and to a high

standard.

It was hard to get started with the work, as it is hard to know where to begin when there is so much to do and

seemingly so much time in which to do it. To make sure you get anywhere when you do start you need to sit

down for a long period to make sure you get somewhere the first time you attempt any work. Once you have

got started it is a lot easier to continue because you have made some steps in the right direction and know

what’s needs to be done.

I found it difficult to get going during the first semester because there was always something else to do

which had a closer deadline; this was partly due to the greater workload in that semester.

Once the second semester got underway my project began to take more shape, with a lot less other work to

do it enabled me to really get the project done. A number of areas took me longer than expected though, the

creation of the database took far more hours than I initially thought, every time it looked as though it was

about finished another problem was found and the forms continually needed changing because of problems

with the underlying functionality or appearance. The user guide took a great deal of time to write and

creating the windows help was a great deal more complex than I thought it would be, but when it was

finished I was extremely pleased with the outcome.

Microsoft Access 2000 made it easy to do the simple tasks, but when it came to harder and less popular tasks

it was a lot more difficult to complete them and a lot of time was spent looking through the Access help file

to get assistance, i.e. to create tabbed forms and ensure they were linked and updated correctly.

In order to produce a good database I would advise in spending a lot of time completing the design process,

since it makes the implementation a great deal easier since everything you need is in front of you.

If I were to undertake the same or similar project again I would make sure that I got started straight away

with a brief plan of what I was to do which would allow me to come back and do bits even when only a

small amount of time was available. In addition to this starting before the coursework deadlines come into

play would have been a great advantage and would have taken a lot of pressure away.

The best way to make sure you complete enough work in the time available is to get a list of everything that

needs to be done (this will be amended greatly throughout the project) and to draw up a schedule with

deadlines which you want to keep, if this is followed it should enable you to know where you should be at

any point and make sure you are on target for a successful project.

Overall I am pleased and proud of the project outcome and feel that the time spent on it was worthwhile. The

database will be of great practical use to Wright (Hull) Limited and will enable them to manage their fleet for

a long time into the future.


Appendix B) User Needs

Allocation No. User Needs Users

Related groups of

User Needs

Ref

eren

ce N

umbe

r

Description of the User Need

Mai

n us

er

Sec

onda

ry u

ser

(may

nee

d ac

cess

to th

e in

form

atio

n)

1. First Group Related to driver information

1.1 The system shall store the name of each driver Y Y

1.2 The system shall store any driver disabilities Y Y

1.3 The system shall store the date the driver passed their driving test

Y Y

1.4 The system shall store the date the drivers' driving license expires

Y Y

1.5 The system shall store the type of license owned by the drivers'

Y Y

1.6 The system shall store the date the license was last checked

Y Y

1.7 The system shall store the number of penalty points the drivers' have Y Y

1.8 The system shall store the date a driver's ban expires Y Y

1.9 The system shall store the date of any driving related offences or convictions Y Y

1.10 The system shall store the details of the any vehicle related offences Y Y

1.11 The system shall store any disciplinary action resulting from vehicle offences Y Y

1.12 The system will allow space for additional information relating to offences Y Y

1.13 The system shall store the date of any driver training Y Y

1.14 The system shall store the name of the driver training course undertaken Y Y

1.15 The system shall store details on the driver training course

Y Y

1.16 The system will allow space for additional information relating to driver training Y Y

2. Second Group Related to current vehicle information


2.1 The system shall store the registration number of each of the company's' vehicles Y Y

2.2 The system shall store the make of the vehicles'

Y Y

2.3 The system shall store the model of the vehicles'

Y Y

2.4 The system shall store the size of the vehicles engine Y Y

2.5 The system shall store the type of fuel each vehicle runs on

Y Y

2.6 The system shall store the level of carbon dioxide emissions given from each vehicle Y Y

2.7 The system shall store the date a vehicles M.O.T is due Y Y

2.8 The system shall store the date a vehicles insurance expires

Y Y

2.9 The system shall store the date a vehicles road fund license expires Y Y

2.10 The system shall store the date or mileage at which a vehicle is due a service Y Y

2.11 The system shall store the goods vehicle test dates (where applicable) Y Y

2.12 The system shall store the initial mileage of each vehicle Y Y

2.13 The system shall store the driver of each vehicle

Y Y

2.14 The system shall store the dates that a driver started and stopped using each vehicle Y Y

2.15 The system shall store whether the driver or company pays for the insurance Y Y

3. Third Group Related to vehicle history

3.1 The system shall store the dates that M.O.T's have been carried out Y Y

3.2 The system shall store the mileage at each M.O.T date Y Y

3.3 The system shall store the dates that fuel has been put into the vehicles Y Y

3.4 The system shall store the amount of fuel put into the vehicle

Y Y

3.5 The system shall store the mileage of the vehicle when fuel is put into the vehicle Y Y

3.6 The system shall store the dates that vehicles have been serviced

Y Y

3.7 The system shall store the mileage when vehicles are serviced

Y Y

3.8 The system shall store the dates that vehicles replaced tyres

Y Y


3.9 The system shall store the mileage when tyres are replaced

Y Y

3.10 The system shall store any special reasons why tyres had been replaced Y Y

3.11 The system shall store the date of accidents involving company vehicles Y Y

3.12 The system shall store details of any vehicle accidents Y Y

3.13 The system shall store the individual to blame for the accident (if known) Y Y

3.14 The system shall store the amount paid out by the insurance company Y Y

3.15 The system shall allow additional information to be stored regarding accidents Y Y

3.16 The system shall store the date that a vehicle was repaired

Y Y

3.17 The system shall store the major parts of the vehicle that were replaced Y Y

3.18 The system shall store the reasons that the parts were replaced

Y Y

3.19 The system shall allow additional information to be stored regarding repairs Y Y

3.20 The system shall store the mileage of the vehicle when it was repaired Y Y

4. Fourth Group Related to hired vehicles

4.1 The system shall store which vehicles are part of a hire purchase agreement Y Y

4.2 The system shall store the date that hire purchase agreements start Y Y

4.3 The system shall store the dates of the hire purchase payments

Y Y

4.4 The system shall store which vehicles are part of a contract hire agreement Y Y

4.5 The system shall store the date that contract hire agreements start

Y Y

4.6 The system shall store the date that contract hire agreements end

Y Y

4.7 The system shall store the dates of the contract hire payments

Y Y

4.8 The system shall store the initial mileage of contract hire vehicles

Y Y

4.9 The system shall store the total mileage allowed for each contract hire vehicle Y Y

5. Fifth Group

Reports and Warnings


5.1 The system shall produce a warning when the tax on a vehicle is due in 2 weeks, 1 week or less than a week Y Y

5.2

The system shall produce a warning when the M.O.T on a vehicle is due in 4 weeks, 3 weeks, 2 weeks, 1 week or less than a week

Y Y

5.3

The system shall produce a warning when a vehicles goods vehicle test is in 4 weeks, 3 weeks, 2 weeks, 1 week or less than a week

5.4

The system shall produce a warning when the insurance on a vehicle is due in 4 weeks, 3 weeks, 2 weeks, 1 week or less than a week

Y Y

5.5

The system shall produce a warning when a service is due in 2 weeks, 1 week or less than a week (if service is by date) Y Y

5.6 The system shall produce a warning when a vehicle is 1000, 500 or less than 500 miles away from a service Y Y

5.7 The system shall produce a warning when a hire purchase payment is due Y Y

5.8 The system shall produce a warning when a contract hire payment is due Y Y

5.9

The system shall produce a warning when the last hire purchase payment is due (this should also inform the user that it is the last payment and that the vehicle will become the company's property Y Y

5.10

The system shall produce a warning when the last contract hire payment is due (this should also inform the user that it is the last payment)

Y Y

5.11

The system shall produce a warning indicating when vehicles on contract hire agreements are due to be returned Y Y

5.12

The system shall produce a warning when the average mileage of a vehicle exceeds the average mileage allowed in the contract hire agreement

Y Y

5.13

The system shall produce a report listing the vehicles that are part of a contract hire agreement along with their average mileage and allowable average mileage.

Y Y

5.14 The system shall produce a report listing the vehicles and their overall fuel consumption. Y Y

5.15 The system shall allow the user to see whether an individual has had a large number of accidents Y Y

5.16 The system shall allow the user to see whether an individual has had tyres replaced a large number of times Y Y

5.17 The system shall produce a warning when a driver's ban expires

Y Y

6. Sixth Group

Additional requirements


6.1 The system shall supply a simple interface that is easy to use

Y Y

6.2 The system shall be capable of writing data to disk Y Y

6.3 The system shall be capable of reading in data from a file Y Y

6.4 The user should be able to delete records Y Y

6.5 The user should be able to print details Y Y


Appendix C) Data Flow Diagrams



Appendix D) Entity Life Histories



Appendix E) System Requirements

Function Number: F1

Function Name: Add Driver

Overview: This function shall allow driver details to be input.

Functional Specification:

- This shall allow driver details to be input and stored.

Non - Functional Specification:

- The input shall be user friendly and have a simple interface.

User Needs List: 1.1 – 1.8, 6.1

Function Number: F2

Function Name: Delete Driver

Overview: This function shall allow drivers to be deleted.


- This shall allow the details of the drivers to be deleted from the system.

- All the driver information should be deleted from the system.

User Needs List: 6.4

Function Number: F3

Function Name: Record Driver Offence

Overview: This function shall allow offences to be recorded.


- This shall allow driver offences to be input and stored.

- This shall allow the penalty points and banned date to be updates.


- The method input shall be user friendly and have a simple interface.


Function Number: F4

Function Name: Record Driver Training

Overview: This function shall allow driver-training details to be recorded.


- This shall allow driver-training details to be input and stored.


- The method of input shall be user friendly and have a simple interface.

User Needs List: 1.13 – 1.16, 6.1


Function Number: F5

Function Name: View Driver Details

Overview: This function shall allow driver details to be viewed.


- This shall allow driver details to be viewed.

- The required driver’s details shall be found quickly and easily.

- There shall be the option for any details to be amended upon viewing.

- Any amendments shall replace the previous record and be stored.

- These details shall also be available to print.

User Needs List: 1.1 – 1.16

Function Number: F6

Function Name: Update Driver License Details

Overview: This function shall allow license details to be updated


- The required driver’s details should be found quickly and easily and allow the required details to be

amended.

- The date the license was last checked shall also be available for amendment.


Function Number: F7

Function Name: Add Vehicle

Overview: This function shall allow vehicle details to be recorded.


- This shall allow vehicle details to be input and stored.

- All of the vehicles details should be available to be recorded.




Function Number: F8

Function Name: Record A Vehicle Repair

Overview: This function shall allow repair details to be recorded.


- This shall allow a vehicles repair details to be input and stored.

- The required vehicle should be found quickly and easily.




User Needs List: 3.16 – 3.20, 6.1

Function Number: F9

Function Name: Record An Accident

Overview: This function shall allow accident details to be recorded.


- This shall allow details of a vehicles accident to be input and stored.




User Needs List: 3.11 – 3.15, 6.1

Function Number: F10

Function Name: Record A Tyre Replacement

Overview: This function shall allow tyre replacement details to be recorded.


- This shall allow a vehicle’s tyre replacement details to be input and stored.






Function Name: Record MOT History

Overview: This function shall allow MOT history to be recorded.


- This shall allow a vehicle’s MOT history details to be input and stored.




User Needs List: 3.1, 3.2, and 6.1


Function Name: Record A Fuel Purchase

Overview: This function shall allow fuel purchases to be recorded.


- This shall allow details of a fuel purchase to be input and stored.







Function Name: Record Service Details

Overview: This function shall allow service details to be recorded.


- This shall allow a vehicle’s service details to be input and stored.

- The required vehicle should be found quickly and easily



User Needs List: 3.6, 3.7 and 6.1


Function Name: Delete Vehicle

Overview: This function shall allow vehicles to be deleted.


- This shall allow the details of the vehicles to be deleted from the system.

- All the vehicles information should be deleted from the system.



Function Name: Update Vehicle Dates

Overview: This function shall allow any of the vehicles due or expiry dates to be amended.


- This shall allow the vehicles MOT due date, insurance expiry date, service due date, tax expiry date and

goods vehicle test date to be amended.

- This also allows any other vehicle details to be amended and stored.




Function Name: View Vehicle Records

Overview: This function shall allow the vehicles records to be viewed.


- This shall allow all of a vehicle’s records to be viewed.


- The records should be allowed to be viewed as a group or by particular record which should be found

quickly and easily



- These details shall also be available to print.



Function Name: Record Hire Purchase Vehicle

Overview: This function shall allow a vehicle to be recorded as a hire purchase vehicle.


- This shall allow hire purchase vehicle details to be added and stored.

- This shall allow the hire purchase payment dates to be recorded.





Function Name: Record Contract Hire Vehicle

Overview: This function shall allow a vehicle to be recorded as a contract hire vehicle.


- This shall allow contract hire vehicle details to be added and stored.

- This shall allow the contract hire payment dates to be recorded.





Function Name: View Hire Purchase Records

Overview: This function shall allow hire purchase records to be viewed.


- This shall allow hire purchase details to be viewed.

- The required details should be found quickly and easily.






Function Name: View Contract Hire Records

Overview: This function shall allow contract hire records to be viewed.


- This shall allow contract hire details to be viewed.

- The required details should be found quickly and easily.



User Needs List: 4.4 - 4.9


Function Name: Tax Expiry Warning

Overview: This function shall display a warning when the tax on a vehicle expires in 2 weeks, 1 week or less

than a week.


- This shall compare each vehicle’s tax expiry dates with the current date.

- If tax expiry date = (current date add 14 days), then a warning message will be displayed.

- If tax expiry date <= (current date add 7 days), then a warning message will be displayed.

- Otherwise no warning is required for the vehicle.

- The vehicle registration numbers and details output shall be available to print.


- The method of output should be clear and readable.



Function Name: MOT Due Date Warning

Overview: This function shall display a warning when the MOT on a vehicle is due in 4 weeks, 3 weeks, 2

weeks, 1 week or less than a week.


- This shall compare each vehicle’s MOT due dates with the current date.

- If MOT due date = (current date add 28 days), then a warning message will be displayed.



- If MOT due date <= (current date add 7 days), then a warning message will be displayed.








Function Name: Goods Vehicle Test Date Warning

Overview: This function shall display a warning when a vehicles goods is in 4 weeks, 3 weeks, 2 weeks, 1

week or less than a week.


- This shall compare each vehicle’s goods vehicle test dates with the current date.

- If GV test date = (current date add 28 days), then a warning message will be displayed.



- If GV test date <= (current date add 7 days), then a warning message will be displayed.







Function Name: Insurance Renewal Warning

Overview: This function shall display a warning when the Insurance on a vehicle is due for renewal in 4

weeks, 3 weeks, 2 weeks, 1 week or less than a week.


- This shall compare each vehicle’s MOT due dates with the current date.

- If insurance renewal date = (current date add 28 days), a warning message will be displayed.

- If insurance renewal = (current date add 21 days), a warning message will be displayed.

- If insurance renewal = (current date add 14 days), a warning message will be displayed.

- If insurance renewal <= (current date add 7 days), a warning message will be displayed.








Function Name: Service Due Date Warning

Overview: This function shall display a warning when a vehicles service is due in 2 weeks, 1 week or less

than a week.


- This shall compare each vehicle’s service due dates with the current date.

- If service due date = (current date add 14 days), then a warning message will be displayed.

- If service due date <= (current date add 7 days), then a warning message will be displayed.







Function Name: Service Mileage Warning

Overview: This function shall display a warning when a vehicle is 1000 miles, 500 miles or less then 500

miles away from a service.


- This shall compare each of the vehicles’ mileage (from the last time fuel was put in the vehicle) with the

mileage at which a service is due.

- If mileage = (service mileage less 1000), then a warning message will be displayed.

- If mileage <= (service mileage less 500), then a warning message will be displayed.







Function Name: Hire Purchase Payment Date Warning

Overview: This function shall display a warning when a payment as part of a hire purchase contract is due.


- This shall compare the hire purchase payment dates with the current date.

- If hire purchase payment date = current date, then a warning message will be displayed.

- If hire purchase payment date <> current date, then a warning message will not be displayed.







Function Name: Contract Hire Payment Date Warning

Overview: This function shall display a warning when a payment as part of a contract hire contract is due.


- This shall compare the contract hire payment dates with the current date.

- If contract hire payment date = current date, then a warning message will be displayed.

- If contract hire payment date <> current date, then a warning message will not be displayed.






Function Name: Hire Purchase Last Payment Date Warning

Overview: This function shall display a warning when the last payment of a hire purchase contract is due.


- This shall compare the last hire purchase payment date with the current date.

- If last hire purchase payment date = current date, then display warning message including information

informing the user that the vehicle has become part of the company’s property.

- If last hire purchase payment date <> current date, then no warning is necessary.


- The method of output should be clear and readable



Function Name: Contract Hire Last Payment Date Warning

Overview: This function shall display a warning when the last payment of a contract hire contract is due.


- This shall compare the last contract hire payment date with the current date.

- If last contract hire payment date = current date then display warning message including information

informing that it is the last payment that is due.

- If last contract hire payment date <> current date, then no warning is necessary.






Function Name: Contract Hire Expiry Date

Overview: This function shall display a warning when a contract hire agreement comes to an end.


- This shall compare the contract hire end date with the current date.

- If last contract hire end date = current date then display warning message informing the user that the

contract agreement has expired.

- If contract hire end date <> current date, then no warning is necessary.





Function Name: Contract Hire Mileage Warning

Overview: This function shall display a warning when the average mileage for a contract hire vehicle exceeds

the average mileage allowed.


- The average mileage allowed shall be calculated using the allowed contract hire mileage, the vehicles

initial mileage and the time period between the two.

- The actual average mileage shall be calculated using the initial mileage, the actual mileage and the time

period between the two.

- The average mileage allowed and the actual average mileage will then be compared.

- If actual average mileage > allowed average mileage then a warning shall be displayed.

- If actual average mileage <= allowed average mileage then a warning is not necessary.





Function Name: Contract Hire Mileage Report

Overview: This function shall display the average and allowed average mileage for each contract hire vehicle.


- The average mileage allowed shall be calculated using the allowed contract hire mileage, the vehicles

initial mileage and the time period between the two.

- The actual average mileage shall be calculated using the initial mileage, the actual mileage and the time

period between the two.


- The average mileage allowed and the actual average mileage will output along with the registration

number of the vehicle and its current driver.






Field Name: Vehicle Fuel Consumption Report

Overview: This function shall display a list of all the vehicles along with their overall fuel consumption.


- The fuel consumption shall be calculated using the initial mileage and the last mileage recorded along

with the total amount of fuel put in the vehicle (except the last amount).

- The fuel consumption will output along with the registration number of the vehicle and its current driver.






Field Name: Ban Expiry Warning

Overview: This function shall display warning when a driver’s ban expires.


- This shall compare the ban expiry date with the current date.

- If ban expiry date = current date then display warning message informing the user that the contract

agreement has expired.

- If ban expiry date <> current date, then no warning is necessary.





Field Name: Tyre Report

Overview: This function shall display the number of tyre replacements per driver.


- The number of tyre replacements for each driver shall be calculated.

- The driver shall be output along with this value.







Field Name: Accident Report

Overview: This function shall display the number of accidents per driver.


- The number of accidents each driver has had should be calculated for each vehicle.

- The driver shall be output along with this value.






Function Name: Restore Information

Overview: This function should restore the information stored in the database when the program is run.


- The system should record all the information written to the system.

- Then restore all this information when the program is run.



Function Name: Save Information

Overview: This function should save the information stored in the database when the program is quit.


- The system should record all the information written to the system.



Appendix F) Functional Analysis

The functions given below should all be available to the user, although some of the functions are in

reality combined together to create one function that caters for them all.

Driver Functions

- Add driver

- Remove driver

- Record offence

- Record driver training

- View driver details (offence, driver and training details)

- Update driving licence details and record date licence last checked

- Print driver details

Vehicle Functions

- Add vehicle

- Remove vehicle

- Print vehicle details

- Change MOT due date

- Change Goods vehicle test date

- Change insurance renewal date

- Change tax expiry date

- Change service due date

- Change mileage till next service

- Change vehicle’s insurance payer

- Change a vehicles driver and record date of changeover

- Record MOT details

- Update MOT details

- View MOT details

- Record service details

- Update service records

- View service records

- Record fuel purchases


- Update fuel records

- View fuel purchases

- Record accident details

- Update accident details

- View accident details

- Record tyre renewal

- View tyre renewal records

- Record repair details

- Update repair details

- View repair details

Lease Vehicle Functions

- Record vehicles that are part of a hire purchase agreement

- Record vehicles that are part of a contract hire agreement

- Record hire purchase payment dates

- Record contract hire payment dates

- Update hire purchase agreement details

- Update contract hire agreement details

- View hire purchase agreement details

- View contract hire agreement details

- Delete hire purchase details

- Delete contract hire details

Report functions

- View vehicles fuel consumptions

- Print fuel consumption list

- View contract hire vehicles average mileage against the average mileage allowed

- Print contract hire average and allowed mileages per vehicle

- View a list of drivers along with the number of accidents

- Print accident list

- View a list of drivers along with the number of replacement tyres

- Print tyre list


Warning functions

- Report tax expiry dates

- Print vehicles with tax due

- Report insurance renewal dates (along with driver and payer of insurance

- Print vehicles with insurance due

- Report MOT due dates

- Print vehicles with MOT’s due

- Report goods vehicles test dates

- Print vehicles with goods vehicle tests due

- Report service due dates

- Report service due mileages

- Print vehicles with services due

- Report contract hire payments

- Report hire purchase payments

- Report last contract hire payments

- Report last hire purchase payments

- Report contract hire end date

- Print contract hire payment list (along with end of contract date)

- Print hire purchase payment list (along with last payment date)

- Report driving ban expiry dates

- Report vehicles that have an average mileage greater than that allowed by the contract

agreement


Appendix G) Data Dictionary

Driver Table

Field Data

Type Format/Size Validation Required Indexed Notes

Driver_ID Number Long Integer

Yes Yes (No Duplicates

Uniquely identifies each driver.

Name Text 25 Is Not Null

Yes No Drivers name.

License Text (Lookup)

No No Drop down list of choices.

Pass_date Date d/m/yyyy <= Date() No No Date driver passed driving test.

Expiry_date Date d/m/yyyy No No Date driving license expires.

Points Number Integer >=0 No No Number of penalty point a driver has.

Check_date Date d/m/yyyy <= Date() No No The date the drivers’ license was last checked by staff.

Banned_date Date d/m/yyyy >= Date() No No The date the driver is banned until.

Disability Text 100 No No Brief description on disabilities that may affect driving.

Driver Training Table

Field Data Type

Format/Size Validation Required Indexed Notes

Training_ID Number Long Integer


Uniquely identifies the training.

Driver_ID Number (Lookup)

Long Integer

Yes Yes (Duplicates

OK)

Show which driver undertook the training (looked up from driver table).

Date Date d/m/yyyy <= Date() No No Date the training was taken.

Course Text 30 No No The name of the training course.

Details Text 50 No No Training details. Notes Text 50 No No Any additional

notes the user would like to make about the training.

Driver Offence Table

Field Data Type


Offence_ID Number Long Integer


Uniquely identifies each offence.

Driver_ID Number Long Yes Yes Show which driver


(Lookup) Integer (Duplicates OK)

the offence relates to (looked up from driver table).

Date Date d/m/yyyy <= Date() No No Date the offence occurred.

Offence Text 40 Is Not Null

Yes No The name of the offence.

Punishment Text 30 No No The punishment that the driver received.

Notes Text 50 No No Any additional notes the user would like to make about the offence.

Vehicle Table

Field Data Type


Registration_No Text 10 Is Not Null


The registration number of the vehicle

Make Text 15 Is Not Null

Yes No The make of the vehicle.

Model Text 15 Is Not Null

Yes No The model of the vehicle

Engine Text 10 No No The engine size of the vehicle.

Fuel Text (Lookup)

50 No No The type of fuel the vehicle takes.

Emissions Number Double >=0 No No The amount of carbon dioxide the vehicle emits.

Insurance_date Date d/m/yyyy >= Date() Yes No The date the vehicles insurance is due for renewal.

Tax_date Date d/m/yyyy >= Date() Yes No The date the vehicles road fund license expires.

Service_date Date d/m/yyyy >= Date() No No The date the vehicle is due for a service.

Service_mileage Number Long Integer

>=0 No No The mileage to indicate when the vehicle needs a service.

MOT_date Date d/m/yyyy >= Date() No No The date the vehicle is due for an MOT.

Goods_vehicle_ test_date

Date d/m/yyyy >= Date() No No The date the vehicle is due for a goods vehicle test .

Insurance_payer Text (Lookup)

8 No No Who pays the insurance on the vehicle (company or driver).


Initial_mileage Number Long Integer

>=0 No No The initial mileage of the vehicle.

Accident Table

Field Data Type


Accident_ID Number Long Integer

Yes Yes (No Duplicates)

Uniquely identifies each accident.

Registration_No Text (Lookup)

50 Is Not Null

Yes No The registration of the vehicle involved in the accident.

Date Date d/m/yyyy <= Date() No No The date of the accident.

Details Text 100 No No The accident details Blame Text 25 No No Who was at fault

for the accident. Insurance_ amount

Number Double >=0 No No The amount paid out by the insurance company with respect to the accident.

Notes Text 100 No No Any additional notes the user would like to make about the accident.

Fuel Table

Field Data Type


Fuel_ID Number Long Integer


Uniquely identifies the fuel purchase.


50 Is Not Null

Yes No The registration number of the vehicle that filled up with fuel.

Date Date d/mm/yyyy <= Date() Yes No The date the fuel was purchased.

Amount Number Double >0 And Is Not Null

Yes No The amount of fuel that was purchased.

Mileage Number Long Integer

>=0 No No The mileage the vehicle had done at the time of purchase.

MOT Table

Field Data Type


MOT_ID Number Long Integer


Uniquely identifies each MOT.


50 Is Not Null

Yes No The registration number of the vehicle that had the


MOT. Date Date d/m/yyyy <= Date() Yes No The date the

vehicle had the MOT.


>=0 No No The mileage of the vehicle at the time of MOT.

Repair Table

Field Data Type


Repair_ID Number Long Integer


Uniquely identifies each repair.


50 Is Not Null

Yes No The registration number of the vehicle that had the repair.

Date Date d/m/yyyy <= Date() Yes No The date the vehicle had the repair.

Parts Text 50 No No The parts that the vehicle had repaired or replaced

Reasons Text 50 No No The reasons why the vehicle needed the repair.

Service Table

Field Data Type


Service_ID Number Long Integer


Uniquely identifies each service.


50 Is Not Null

Yes No The registration number of the vehicle that had the service.

Date Date d/m/yyyy <= Date() Yes No The date the vehicle had the service.


>=0 No No The mileage of the vehicle at the time of service.

Information Text 50 No No Any additional information regarding the service.

Tyre Table

Field Data Type


Tyre_ID Number Long Integer


Uniquely identifies each tyre replacement.



50 Is Not Null

Yes No The registration number of the vehicle that had the tyre replaced.

Date Date d/m/yyyy <= Date() No No The date the vehicle had the tyre replaced.


>=0 No No The mileage of the vehicle at the time of replacement.

Reason Text 50 No No The reason why the tyre was replaced.

Vehicle History Table

Field Data Type


History_ID Number Long Integer


Uniquely identifies each driver spell.


50 Is Not Null

Yes No The registration number of the vehicle.

Driver Number (Lookup)

Long Integer

Yes No The name of the driver that had the spell driving the vehicle..

Start_date Date d/m/yyyy <= Date() Yes No The date the driver started driving the vehicle.

End_date Date d/m/yyyy <= Date() No No The date the driver stopped driving the vehicle.

Hire Purchase Table

Field Data Type


Hire_purchase_ ID

Number Long Integer


Uniquely identifies each hire purchase record.


50 Is Not Null


The registration number of the hire purchase vehicle.

Start_date Date d/m/yyyy <= Date() Yes No The date the contract started.

Hire Purchase Payment Table

Field Data Type


Hire_purchase_ payment_ID

Number Long Integer


Uniquely identifies each hire purchase payment.

Hire_purchase_ ID

Number Long Integer

Yes No The id of the hire purchase vehicle.

Payment_date Date d/m/yyyy Yes No The date the hire


purchase payment is due.

Contract Hire Table

Field Data Type


Contract_hire_ ID

Number Long Integer


Uniquely identifies each contract hire record.


50 Is Not Null


The registration number of the contract hire vehicle.

Start_date Date d/m/yyyy <= Date() Yes No The date the contract started.

End_date Date d/m/yyyy >= Date() Yes No The date the contract ends.

Initial_mileage Number Long Integer

>=0 No No The mileage the vehicle had when the contract started.

Mileage_ allowed

Number Long Integer

>=0 No No The amount of miles the vehicle is allowed to do over the period of contract.

Contract Hire Payment Table

Field Data Type


Contract_hire_ payment_ID

Number Long Integer


Uniquely identifies each contract hire payment.

Contract_hire_ ID

Number Long Integer

Yes No The id of the contract hire vehicle.

Payment_date Date d/m/yyyy Yes No The date the contract hire payment is due.

Note: The dates have the input mask: 99/99/0000;0.


Appendix H) Relation Constraints

1. If (Expiry_date <= Pass_date) Then

MsgBox ("A drivers license cannot expire before or on the date the driver passes")

Expiry_date = Null

Expiry_date.SetFocus

End If

2. If ((Goods_vehicle_test_date <> 0) And (MOT_date <> 0)) Then

MsgBox ("A vehicle can not have an MOT and a Goods vehicle test")

Goods_vehicle_test_date = Null

MOT_date = Null

MOT_date.SetFocus

End If

3. If (Service_mileage < Initial_mileage) Then

MsgBox ("The mileage at which a service is due should not be less than the initial mileage of the

vehicle")

Initial_mileage = Null

Service_mileage = Null

Service_mileage.SetFocus

End If

4. If (Form_History.End_date < Form_History.Start_date) Then

MsgBox ("A driver can not stop using a vehicle before he has started using it")

End_date = Null

End_date.SetFocus

End If

5. If (End_date <= Start_date) Then

MsgBox ("The contract cannot end before or on the day it started.")

End_date.SetFocus

End If


Appendix I) Normalisation Table

UNF 1NF 2NF 3NF Entity Driver ID

Name

Licence Type

License Start Date

Licence Expiry Date

Penalty Points

License Check Date

Ban Expiry Date

Disabilities

Driver

Training ID

Driver ID (FK)

Training Date

Course Name

Training Details

Training Notes

Training

Driver ID

Name

Licence Type

License Start Date

Licence Expiry Date

Penalty Points

License Check Date

Ban Expiry Date

Disabilities

Training Date*

Course Name*

Training Details*

Training Notes*

Offence Date*

Offence Details*

Punishment*

Offence Notes*

Driver ID

Name

Licence Type

License Start Date

Licence Expiry Date

Penalty Points

License Check Date

Ban Expiry Date

Disabilities

Training ID

Driver ID

Training Date

Course Name

Training Details

Training Notes

Offence ID

Driver ID

Offence Date

Offence Details

Punishment

Offence Notes

Driver ID

Name

Licence Type

License Start Date

Licence Expiry Date

Penalty Points

License Check Date

Ban Expiry Date

Disabilities

Training ID

Driver ID

Training ID

Training Date

Course Name

Training Details

Training Notes

Offence ID

Driver ID

Offence ID

Offence Date

Offence Details

Punishment

Offence Notes

Offence ID

Driver ID (FK)

Offence Date

Offence Details

Punishment

Offence Notes

Offence


Registration No

Make

Model

Engine Size

Emissions Level

Fuel Type

MOT Due Date

Service Due Date

Service Due Mileage

Tax Expiry Date

Insurance Due Date

GV Test Date

Insurance Payer

Initial Mileage

Vehicle

MOT ID

Registration No (FK)

MOT Date

MOT Mileage

MOT

Service ID


Service Date

Service Info

Service Mileage

Service

Registration No

Make

Model

Engine Size

Emissions Level

Fuel Type

MOT Due Date

Service Due Date

Service Due Mileage

Tax Expiry Date

Insurance Due Date

GV Test Date

Insurance Payer

Initial Mileage

MOT Date*

MOT Mileage*

Service Date*

Service Info*

Service Mileage*

Fuel Date*

Amount*

Fuel Mileage*

Tyre Rep Date*

Tyre Rep Mileage*

Tyre Rep Reason*

Repair Date*

Parts Repaired*

Repair Reasons*

Accident Date*

Accident Details*

Accident Blame*

Insurance Paid*

Driver*

Date Driving From*

Date Driving To*

Registration No

Make

Model

Engine Size

Emissions Level

Fuel Type

MOT Due Date

Service Due Date

Service Due Mileage

Tax Expiry Date

Insurance Due Date

GV Test Date

Insurance Payer

Initial Mileage

MOT ID

Registration No

MOT Date

MOT Mileage

Service ID

Registration No

Service Date

Service Info

Service Mileage

Fuel ID

Registration No

Fuel Date

Amount

Fuel Mileage

Tyre ID

Registration No

Tyre Rep Date

Registration No

Make

Model

Engine Size

Emissions Level

Fuel Type

MOT Due Date

Service Due Date

Service Due Mileage

Tax Expiry Date

Insurance Due Date

GV Test Date

Insurance Payer

Initial Mileage

MOT ID

Registration No

MOT ID

MOT Date

MOT Mileage

Service ID

Registration No

Service ID

Service Date

Service Info

Service Mileage

Fuel ID

Registration No

Fuel ID

Fuel Date

Fuel ID


Fuel Date

Fuel Mileage

Fuel


Tyre ID


Tyre Rep Date

Tyre Rep Mileage

Tyre Rep Reason

Tyre

Repair ID


Repair Date

Parts Repaired

Repair Reasons

Repair

Accident ID


Accident Date

Accident Details

Accident Blame

Insurance Paid

Accident

Tyre Rep Mileage

Tyre Rep Reason

Repair ID

Registration No

Repair Date

Parts Repaired

Repair Reasons

Accident ID

Registration No

Accident Date

Accident Details

Accident Blame

Insurance Paid

History ID

Registration No

Driver

Date Driving From

Date Driving To

Fuel Mileage

Tyre ID

Registration No

Tyre ID

Tyre Rep Date

Tyre Rep Mileage

Tyre Rep Reason

Repair ID

Registration No

Repair ID

Repair Date

Parts Repaired

Repair Reasons

Accident ID

Registration No

Accident ID

Accident Date

Accident Details

Accident Blame

Insurance Paid

History ID

Registration No

History ID

Driver

Date Driving From

Date Driving To

History ID


Driver (FK)

Date Driving From

Date Driving To

History


Hire Purchase ID


Contract Start Date

HP

HP ID

Registration No

Contract Start Date

Payment Date*

Hire Purchase ID

Registration No

Contract Start Date

HP ID

HP Payment ID

Payment Date

Hire Purchase ID

Registration No

Contract Start Date

HP ID

HP Payment ID

HP Payment ID

Payment Date

HP ID

HP Payment ID (FK)

Payment Date HP

Payment

CH ID


Contract Start Date

Contract End Date

Initial Mileage

Mileage Allowed

CH

CH ID

Registration No

Contract Start Date

Contract End Date

Initial Mileage

Mileage Allowed

Payment Date*

CH ID

Registration No

Contract Start Date

Contract End Date

Initial Mileage

Mileage Allowed

CH ID

CH Payment ID

Payment Date

CH ID

Registration No

Contract Start Date

Contract End Date

Initial Mileage

Mileage Allowed

CH ID

CH Payment ID

CH Payment ID

Payment Date

CH ID

CH Payment ID (FK)

Payment Date

CH

Payment

Note: The keys for the relations are underlined and the repeating data items are marked with an asterisk. The

Primary keys are underlined. The foreign keys discovered in stage 4 have FK marked next to them.


Appendix J) Sample screen shots

Training form (accessed via clicking on driver training details tab on the driver form):

Offence form (accessed via clicking on driver offence details tab on the driver form):


Accident form (accessed via clicking on accident details tab on the vehicle form):

Fuel form (accessed via clicking on fuel purchases tab on the vehicle form):


Repair form (accessed via clicking on repair details tab on the vehicle form):

Service form (accessed via clicking on service details tab on the vehicle form):


Tyre form (accessed via clicking on tyre replacements tab on the vehicle form):

MOT form (accessed via clicking on MOT history tab on the vehicle form):


Driver history form (accessed via clicking on driver history tab on the vehicle form):

HP payments form (accessed via clicking on payment dates tab on the HP form):


CH payments form (accessed via clicking on payment dates tab on the CH form):


Appendix K) SQL Queries

Tax Query

SELECT [Vehicle Table].[Registration_No], DateDiff("y",Date(),[Vehicle Table]![Tax_date]) AS [Days

Until Tax Expires]

FROM [Vehicle Table]

WHERE ((((DateDiff("y",Date(),[Vehicle Table]![Tax_date])))<=7 Or ((DateDiff("y",Date(),[Vehicle

Table]![Tax_date])))=14))

ORDER BY DateDiff("y",Date(),[Vehicle Table]![Tax_date]);

MOT Query

SELECT [Vehicle Table].[Registration_No], ((DateDiff("y",Date(),[Vehicle Table]![MOT_date]))) AS

[Days Until MOT Is Due]


WHERE ((((DateDiff("y",Date(),[Vehicle Table]![MOT_date])))<=7 Or ((DateDiff("y",Date(),[Vehicle

Table]![MOT_date])))=14 Or ((DateDiff("y",Date(),[Vehicle Table]![MOT_date])))=21 Or

((DateDiff("y",Date(),[Vehicle Table]![MOT_date])))=28))

ORDER BY ((DateDiff("y",Date(),[Vehicle Table]![MOT_date])));

Goods Vehicle Test Query

SELECT [Vehicle Table].[Registration_No], ((DateDiff("y",Date(),[Vehicle

Table]![Goods_vehicle_test_date]))) AS [Days Until Goods Vehicle Test Date]


WHERE ((((DateDiff("y",Date(),[Vehicle Table]![Goods_vehicle_test_date])))<=7 Or

((DateDiff("y",Date(),[Vehicle Table]![Goods_vehicle_test_date])))=14 Or ((DateDiff("y",Date(),[Vehicle

Table]![Goods_vehicle_test_date])))=21 Or ((DateDiff("y",Date(),[Vehicle

Table]![Goods_vehicle_test_date])))=28))

ORDER BY ((DateDiff("y",Date(),[Vehicle Table]![Goods_vehicle_test_date])));

Insurance Query

SELECT [Insurance Query].Registration_No, [Insurance Query].Insurance_payer, [Insurance Query].[Days

Until Vehicle Insurance Expires], [Driver Table].Name


FROM [Driver Table] INNER JOIN [Insurance Query] ON [Driver Table].Driver_ID = [Insurance

Query].Current_Driver

GROUP BY [Insurance Query].Registration_No, [Insurance Query].Insurance_payer, [Insurance

Query].[Days Until Vehicle Insurance Expires], [Driver Table].Name

ORDER BY [Insurance Query].[Days Until Vehicle Insurance Expires];

Service Query

SELECT [Vehicle Table].Registration_No, ((DateDiff("y",Date(),[Vehicle Table]![Service_date]))) AS

[Days Until Service Is Due]


WHERE ((((DateDiff("y",Date(),[Vehicle Table]![Service_date])))<=7 Or ((DateDiff("y",Date(),[Vehicle

Table]![Service_date])))=14))

ORDER BY ((DateDiff("y",Date(),[Vehicle Table]![Service_date])));

Service Mileage Query

SELECT [Vehicle Table].Registration_No, (Max([Service_Mileage])-Max([Fuel Table].[Mileage])) AS

[Miles Until Service Is Due]

FROM [Vehicle Table] INNER JOIN [Fuel Table] ON [Vehicle Table].Registration_No = [Fuel

Table].Registration_No

WHERE ((([Vehicle Table].Service_mileage) Is Not Null))

GROUP BY [Vehicle Table].Registration_No

HAVING ((((Max([Service_Mileage])-Max([Fuel Table].[Mileage])))=1000 Or ((Max([Service_Mileage])-

Max([Fuel Table].[Mileage])))<=500))

ORDER BY (Max([Service_Mileage])-Max([Fuel Table].[Mileage]));

Hire Purchase Payment Query

SELECT [HP Table].Registration_No, [HP_Payment Table Query].LastOfPayment_date

FROM ([HP Table] INNER JOIN [HP_Payment Table Query] ON [HP Table].Hire_purchase_ID =

[HP_Payment Table Query].Hire_purchase_ID) INNER JOIN [HP_Payment Table] ON [HP

Table].Hire_purchase_ID = [HP_Payment Table].Hire_purchase_ID

WHERE (((DateDiff("y",Date(),[HP_payment Table]![Payment_date]))=0));

(HP Payment Table Query: SELECT DISTINCT [HP_Payment Table].Hire_purchase_ID,

Last([HP_Payment Table].Payment_date) AS LastOfPayment_date

FROM [HP_Payment Table]


GROUP BY [HP_Payment Table].Hire_purchase_ID;)

Contract Hire Payment Query

SELECT [CH Table].[Registration_No], [CH_Payment Table Query].[LastOfPayment_dates]

FROM ([CH Table] INNER JOIN [CH_Payment Table Query] ON [CH

Table].[Contract_hire_ID]=[CH_Payment Table Query].[Contract_hire_ID]) INNER JOIN [CH_Payment

Table] ON [CH Table].[Contract_hire_ID]=[CH_Payment Table].[Contract_hire_ID]

WHERE (((DateDiff("y",Date(),[CH_Payment Table]![Payment_dates]))=0));

(CH_Payment Table Query: SELECT DISTINCT [CH_Payment Table].Contract_hire_ID,

Last([CH_Payment Table].Payment_dates) AS LastOfPayment_dates

FROM [CH_Payment Table]

GROUP BY [CH_Payment Table].Contract_hire_ID;)

Last Hire Purchase Payment Query

SELECT [HP Table].Registration_No

FROM [HP Table] INNER JOIN [HP_Payment Table] ON [HP Table].Hire_purchase_ID = [HP_Payment

Table].Hire_purchase_ID

GROUP BY [HP Table].Registration_No

HAVING (((DateDiff("y",Date(),Last([HP_Payment Table]![Payment_date])))=0));

Last Contract Hire Payment Query

SELECT [CH Table].[Registration_No]

FROM [CH Table] INNER JOIN [CH_Payment Table] ON [CH Table].[Contract_hire_ID]=[CH_Payment

Table].[Contract_hire_ID]

GROUP BY [CH Table].[Registration_No]

HAVING (((DateDiff("y",Date(),Last([CH_Payment Table]![Payment_dates])))=0));

Contract Hire Expiry Query

SELECT [CH Table].[Registration_No]

FROM [CH Table]

WHERE ((([CH Table].[End_date])=Date()))

GROUP BY [CH Table].[Registration_No];


Contract Hire Mileage Query

SELECT [Contract Hire Mileage Query].[Registration_No] AS Registration_Number, [Contract Hire

Mileage Query].[Allowed Weekly Mileage] AS [Allowed Weekly Mileage], [Contract Hire Mileage

Query].[Actual Weekly Mileage] AS [Actual Weekly Mileage]

FROM [Contract Hire Mileage Query]

WHERE ((([Allowed Weekly Mileage])<[Actual Weekly Mileage]));

Banned Query

SELECT [Driver Table].Name

FROM [Driver Table]

WHERE ((([Driver Table].Banned_date)=Date()))

GROUP BY [Driver Table].Name;

Contract Hire Mileage Report

SELECT [CH Table].[Registration_No], Last([Fuel Table].[Mileage]) AS LastOfMileage_before_fuel,

Last([Fuel Table].[Date]) AS LastOfFuel_date1, Max([CH Table].[Initial_mileage]) AS

MaxOfInitial_mileage, Max([CH Table].[Start_date]) AS MaxOfContract_start_date,

((LastOfMileage_before_fuel-

MaxOFInitial_mileage)/(DateDiff("ww",MaxOfContract_start_date,LastOfFuel_date1))) AS [Actual

Weekly Mileage], Max([CH Table].[Mileage_allowed]) AS MaxOfTotal_mileage_allowed, Last([CH

Table].[End_date]) AS LastOfContract_end_date,

((MaxOfTotal_mileage_allowed)/(DateDiff("ww",MaxOfContract_start_date,LastOfContract_end_date)))

AS [Allowed Weekly Mileage]

FROM [Fuel Table] INNER JOIN [CH Table] ON [Fuel Table].[Registration_No]=[CH

Table].[Registration_No]

GROUP BY [CH Table].[Registration_No];

Fuel Consumption Report

SELECT DISTINCT [Vehicle Table].[Registration_No], (Max([Mileage])-

Max([Initial_mileage]))/((Sum([Fuel Table].[Amount])-Last([Fuel Table].[Amount]))) AS

FuelConsumption_MilesPerLitre

FROM [Vehicle Table] INNER JOIN [Fuel Table] ON [Vehicle Table].[Registration_No]=[Fuel

Table].[Registration_No]

GROUP BY [Vehicle Table].[Registration_No]

HAVING ((Sum([Fuel Table].[Amount])-Last([Fuel Table].[Amount]))<> 0);


Accident Report

SELECT DISTINCT [Vehicle_History Table].Driver, Count([Accident Table].Registration_No) AS

Total_Accidents

FROM ([Accident Table] INNER JOIN [Vehicle_History Table] ON [Accident Table].Registration_No =

[Vehicle_History Table].Registration_No) INNER JOIN [Accident-Last] ON [Vehicle_History

Table].Registration_No = [Accident-Last].Registration_No

WHERE ((([Accident Table].Date) Between [Vehicle_History Table]![Start_date] And [Vehicle_History

Table]![End_date])) OR ((([Accident Table].Date) Between [Vehicle_History Table]![Start_date] And

Date()) AND (([Accident-Last].LastOfDriver)=[Vehicle_History Table].[Driver]))

GROUP BY [Vehicle_History Table].Driver;

(Accident-Last: SELECT [Accident Table].Registration_No, Last([Vehicle_History Table].Driver) AS

LastOfDriver

FROM [Accident Table] RIGHT JOIN [Vehicle_History Table] ON [Accident Table].Registration_No =

[Vehicle_History Table].Registration_No

GROUP BY [Accident Table].Registration_No;)

Tyre Replacement Report

SELECT DISTINCT [Vehicle_History Table].Driver, Count([Tyre Table].Registration_No) AS

Total_Replacements

FROM [Tyre-Last] INNER JOIN ([Tyre Table] INNER JOIN [Vehicle_History Table] ON [Tyre

Table].Registration_No = [Vehicle_History Table].Registration_No) ON [Tyre-Last].Registration_No =

[Vehicle_History Table].Registration_No

WHERE ((([Tyre Table].Date) Between [Vehicle_History Table]![Start_date] And [Vehicle_History

Table]![End_date])) OR ((([Tyre Table].Date) Between [Vehicle_History Table]![Start_date] And Date())

AND (([Tyre-Last].LastOfDriver)=[Vehicle_History Table].[Driver]))

GROUP BY [Vehicle_History Table].Driver;

(Tyre-Last: SELECT [Vehicle_History Table].Registration_No, Last([Vehicle_History Table].Driver) AS

LastOfDriver

FROM [Vehicle_History Table] INNER JOIN [Tyre Table] ON [Vehicle_History Table].Registration_No =

[Tyre Table].Registration_No

GROUP BY [Vehicle_History Table].Registration_No;)


Appendix M) Windows help screen shots

Contents List of Headings

Contents List of topics within headings


Index

Introduction to Windows help


Amend driver details Windows help

Check warnings Windows help


Appendix N) Sample User Guide

Wright (Hull) Limited Fleet Management Database System

User Guide


Contents

CHAPTER TOPIC PAGE

1 Introduction 3

2 Installation 3

3 Minimum Requirements 3

4 System Settings 3

5 Getting started 4

6 On-line help 4

7 Record Navigation 4

8 Main Menu 5

9 Add Driver Details 6

10 Amend Driver Details 7

11 Add Vehicle Details 8

12 Amend Driver Details 12

13 Add Hire Purchase Vehicle Details 12

14 Amend Hire Purchase Vehicle Details 13

15 Add Contract Hire Vehicle Details 14

16 Amend Contract Hire Vehicle Details 15

17 Check Warnings 15

18 Report Menu 16


Introduction

This guide is used to help familiarise users with the database system and help operate functions when having

difficulty.

The help can be accesses by pressing the F1 button whilst within the application. This operation will bring

you to a help screen relating to the form that is in focus.

To look through topics individually you can click on the contents tab or you can click on the browse (arrow)

buttons to select the next topic in the list if you would like to view all of the contents in order.

Installation

You can install the database by simply dragging the application and help file of the CD onto the required

location. To enable the database to function properly with its help file, the database and Microsoft help file

along with its contents need to stored in the same location.

After the files have been put into the right location the properties of the file need changing. To do this you

right click on the fleet management (.mdb) file and on the menu brought up click on properties. The read-

only checkbox then needs to be unchecked and the archive checkbox needs checking. If this is not done you

will not be able to add data to the database.

Minimum Requirements

• Microsoft Access 2000

• PC with windows operating system

• Available Hard disk space (about 100mb)

• 8mb RAM

System Settings

In order to ensure the functions operate properly the regional settings on the control panel (located under

settings on the start menu) need to be put onto the English (United Kingdom) setting. This will ensure that

the format of the data will be correct, i.e. the date will be set out as d/m/y, rather than m/d/y as in the US

system.

The screens resolution needs to be set at 800 by 600, to enable the menus and forms to be displayed properly.

To change this setting on your computer you can right-click on an empty area of the desktop and click

properties on the menu that appears. On the screen that is displayed you click on the settings tab and then

move the screen area pointer to 800 by 600 pixels, then click OK and when the message box comes up

asking you if you want to keep the new settings you press yes.

Your display will now have the correct settings to view the database correctly.


Getting Started

To open the Fleet Management Database System you can either click on the Fleet Management Database

System icon on the desktop or open Microsoft Access through start menu → programs → Microsoft Access

and then click on file → open → Fleet Management Database System.mdb.

After opening the database you will be asked for a password as in figure 5.1, you need to enter the password

that was supplied when receiving the application. If the correct password is input you will be brought straight

to the main menu, otherwise an error message will be output see figure 5.2.

(Figure 5.1) Password Screen (Figure 5.2) Invalid Password Screen

On-line help

The on-line help is accessible on any screen by pressing the F1 button on the keyboard.

If the F1 button is pressed on the main menu the help file will open on the introduction page, where all other

help files can be found by either browsing through using the arrow keys or by viewing the contents that is

available at the top of the screen.

The help that pops up on the press of the F1 key depends on what screen and what control has focus,

different help screens are output on different forms.

Record Navigation

Within the forms in the database the buttons below appear, the descriptions will help you to familiarise

yourself with their actions:

Go to first record

Go to previous record

Go to last record


Go to next record

Add new record

Delete record

Print record

Exit Form/Application

The first four buttons are found in the bottom corner of the forms the others are more easily found on the

forms.

Main Menu

This is the screen (figure 8.1) that is first seen after loading the database. The buttons are clearly marked with

text that describes the actions they perform. Just click on the button that relates to the function you want to

perform.

The quit application button closes the application and returns to Windows.


(Figure 8.1) Main Menu

Add Driver Details

This form is used to add driver details. The relevant details are entered into the boxes and the record is saved

on exiting the form. The license pass date, license expiry date, license check date and ban expiry date need

entering in the correct format (dd/mm/yyyy), as do all dates.

(Figure 9.1) Driver Details Form

To add details regarding driver training you click on the driver training details tab at the top of the form and

you will come to the driver training details sub-form as shown in figure 9.2. More than one training record

can be entered per driver, to add an additional training record you can either tab down to the next date box or

click on the Add Training Record button.

(Figure 9.2) Driver Training Details Sub-form

To add details regarding driver offences you click on the driver offence details tab at the top of the form and

you will come to the driver offence details sub-form as shown in figure 9.3. More than one offence record


can be entered per driver, to add an additional offence record you can either tab down to the next date box or

click on the Add Offence Record button.

(Figure 9.3) Driver Offence Details Sub-form

After viewing or entering details into the sub-forms you can get back to the basic driver details form by

clicking on the driver details tab.

To add a new driver record whilst within this form you can click on the Add Driver Record button, which is

accessible from the main form or from either of the sub-forms.

Navigating to the any form and record and pressing the Print Details button allows you to print any required

driver details.

To ensure that you know which driver you are dealing with within the sub-forms the driver’s name will be

printed at the top-left of the form.

Amend Driver Details

Clicking on this button brings you to the driver form in figure 9.1, but via a select driver form as shown in

figure 10.1, the form is then opened with the relevant drivers details. You select the driver you want to view

or amend from the drop down list that is marked – Select Driver.

(Figure 10.1) Find Driver Form


To enable you to view all the drivers details just leave a blank and the form will open with the first drivers

details, the other drivers can be viewed by clicking on the record navigation buttons described earlier (i.e.

next record button).

Add Vehicle Details

This form is used to add vehicle details, past and present. The form opens onto the main vehicle details

section, which allows you to enter the vehicles details as shown in figure 11.1. The fuel type and insurance

payer details are available from a drop down list to make the form filling easier. The details can be entered

into the blank boxes available.

(Figure 11.1) Vehicle Details Form

To add or view accident details you click on the accident details tab to go to the Accident Details Sub-form

shown in figure 11.2. This form is used to store vehicle accidents to ensure a full vehicle record is kept and

to monitor driver behaviour. A number of accident records can be stored for each driver and details can be

added in the same manner as for the driver records.


(Figure 11.2) Accident Details Sub-form

To add or view fuel purchase details you click on the fuel purchases tab to go to the Fuel Purchase Details

Sub-form shown in figure 11.3. This form is used to store the fuel intake of the vehicles to calculate

consumptions. This information should be updated after every purchase of fuel by copying the details on the

fuel cards received from the drivers.

(Figure 11.3) Fuel Purchase Details Sub-form

To add or view repair details you click on the repair details tab to go to the Repair Details Sub-form shown

in figure 11.4. This form is used to record the repair history of the vehicles to ensure a full vehicle record is

kept.


(Figure 11.4) Repair Details Sub-form

To add or view service details you can click on the service details tab to go to the Service Details Sub-form

shown in figure 11.5. This form is used to store the service history of vehicles to ensure a full service history

for each vehicle is recorded.

(Figure 11.5) Service Details Sub-form

To add or view tyre replacement details you click on the tyre replacements tab to go to the Tyre Replacement

Details Sub-form shown in figure 11.6. This form is used to record the tyre replacements each vehicle has in

order to prevent the abuse of the vehicle through bad driving.


(Figure 11.6) Tyre Replacement Details Sub-form

To view or add details to the MOT history of a vehicle you can click on the MOT history tab to go to the

MOT History Details Sub-form shown in figure 11.7. This form is used to store the MOT history of a vehicle

and should be updated after every MOT.

(Figure 11.7) MOT History Details Sub-form

To record the driver of the vehicle, old or new, you click on the driver history tab to go to the Driver History

Details Sub-form shown in figure 11.8. This enables you to keep track of the drivers so the driver of each

vehicle is known as well as the period the drivers were in charge of each vehicle. When a driver starts to use

a vehicle then these details should be updated.


(Figure 11.8) Driver History Details Sub-form

After viewing or entering details into the sub-forms you can get back to the basic vehicle details form by

clicking on the vehicle details tab.

To add a new vehicle record whilst within this form you can click on the Add Vehicle Record button, which

is accessible from the main form or from any of the sub-forms.

Navigating to the any form and record and pressing the Print Details button allows you to print any required

vehicle details.

The registration number of the vehicle that you are dealing with will always be shown at the top left of the

form to ensure that you know which vehicle’s details you are adding or amending.

Amend Vehicle Details

Clicking on this button brings you to the same form as the vehicle form in figure 11.1, but via a select

vehicle form shown in figure 12.1, the form is then opened with the relevant vehicles details. You select the

vehicle you want to view or amend from the drop down list that is marked – Select Registration number.

(Figure 12.1) Find Vehicle Form

To enable you to view all the vehicles details just leave a blank and the form will open with the first vehicles

details, the other vehicles can be viewed by clicking on the record navigation buttons.

Add Hire Purchase Vehicle Details

This form is used to add hire purchase vehicle details. The form opens onto the form shown in figure 13.1.


(Figure 13.1) Hire Purchase Vehicle Details Form

The required vehicle can be selected from the drop down list in the registration number box as

shown in figure 13.2.

(Figure 13.2) Select Registration number of vehicle box

To record the dates the hire purchase payments are due you click on the payment dates tab at the top of the

form. This will bring you to the form shown in figure 13.3. The dates added to this form will be used to warn

when a payment is due; this warning will be displayed when the check warnings (see later) button on the

main menu is pressed.

(Figure 13.3) Hire Purchase Payment Details Form


After viewing or entering details into the sub-form you can get back to the first form by clicking on the hire

purchase vehicles tab.

To add a new hire purchase vehicle record whilst within this form you can click on the Add Vehicle button,

which is accessible from the main form or from the payment dates sub-form.


form to ensure that you know which vehicle’s details you are adding or amending.

Amend Hire Purchase Vehicle Details

Clicking on this button brings you to the same form as the hire purchase form in figure 13.1, but via a select

hire purchase vehicle form as shown in figure 14.1, the form is then opened with the relevant vehicles

details. You select the vehicle you want to view or amend from the drop down list that is marked – Select

Registration number.

(Figure 14.1) Find Hire Purchase Vehicle Form

To enable you to view all the vehicles that are part of a hire purchase agreement just leave a blank and the

form will open the first vehicles details, the other vehicles can be viewed by clicking on the record

navigation buttons.

Add Contract Hire Vehicle Details

This form is used to add contract hire vehicle details. The form opens onto the form shown in figure 15.1.

(Figure 15.1) Contract Hire Vehicle Details Form


The required vehicle can be selected from the drop down list in the registration number box, the same as it

can be for hire purchase vehicles, see figure 13.2.

To record the dates the contract hire payments are due you click on the payment dates tab at the top of the

form. This will bring you to the form shown in figure 15.2. The dates added to this form will be used to warn

when a payment is due.

(Figure 15.2) Contract Hire Vehicle Payment Details Form

To get back to the first form when on the sub-form you click on the hire purchase vehicles tab.

To add a new contract hire vehicle record whilst within this form you can click on the Add Vehicle button,

which is accessible from the main form or from the payment dates sub-form.


form to ensure that you know which vehicle’s details you are adding or amending

Amend Contract Hire Vehicle Details

Clicking on this button brings you to the same form as the contract hire form in figure 15.1, but via a select

contract hire vehicle form as shown in figure 16.1, the form is then opened with the relevant vehicles details.

You select the vehicle you want to view or amend from the drop down list that is marked – Select

Registration number.

(Figure 16.1) Find Contract Hire Vehicle Form


To enable you to view all the vehicles that are part of a contract hire agreement just leave a blank and the

form will open the first vehicles details, the other vehicles can be viewed by clicking on the record

navigation buttons at the bottom left corner of the form.

Check Warnings

This function can be used as to check on payments, due date and mileages. Clicking on this button will start

a number of warnings that were requested to be produced. The warnings are displayed in the following order:

• Tax Warning

• MOT Warning

• Goods Vehicle Test Warning

• Insurance Warning

• Service Warning

• Service Mileage Warning

• Hire Purchase Payment Warning

• Contract Hire Payment Warning.

• Last Hire Purchase Payment Warning

• Last Contract Hire Payment Warning

• Contract Hire Expiry Warning

• Contract Hire Mileage Warning

• Banned Driver Expiry Date Warning

After viewing each warning the OK button needs pressing to view the subsequent warning. An example of

the output from this function can be seen in figure 17.1


(Figure 17.1) Check Warnings Sample Output

This is just a quick method to see what payments e.t.c are due and is not printable. After checking the

warnings any details, which you require to print for further investigation, can be found in the reports menu

Report Menu

This menu holds the reports and warnings and allows you to view and print them when required. To print of

any of the reports you need to click on the reports button to view the report and then click file → print on the

menu at the top of the screen. The menu is shown in figure 18.1.

(Figure 18.1) Report Menu

An example of a reports output is shown in figure 18.2, this report shows the fuel consumption of the

vehicles. The other reports have the same format and are displayed in the same fashion.


(Figure 18.2) Sample Report Output – Fuel Consumption Report


Appendix O) Field testing data and results

Driver Form

Field Validation Data Expected Result Actual Result License Provisional Data accepted. Data accepted. Data accepted. Data accepted. Mr Jones Error message. (Not in List) Error message. Pass_date 23/03/2002* Data accepted. Data accepted. Ab/cd/efgh* Data not accepted. Data not accepted. 13/13/2001* Error message. Error message. 32/01/1980* Error message. Error message. 12/02/2004* Error message.

The pass date cannot be after the current date.

Error message.

Points 0 Data accepted Data accepted 100 Data accepted Data accepted -1 Error message. Error message. Lots Error message Error message Banned_date 24/03/2004** Data accepted. Data accepted. Ab/cd/efgh** Data not accepted. Data not accepted. 13/13/2006** Error message. Error message. 32/01/2003** Error message. Error message. 23/01/2000 Error message.

The driver cannot be banned until a date that has passed.

Error message.

* The same data was entered for the following fields: Check_date, Date (Training) and Date (Offence). The

same results also apply.

** The same data was entered for the following fields: Expiry_date. The same results also apply.

Vehicle Form

Field Validation Data Expected Result Actual Result Fuel Type Unleaded Data accepted. Data accepted. Data accepted. Data accepted. Water Error message. (Not in List) Error message. Emissions 0 Data accepted. Data accepted. 1.23 Data accepted. Data accepted. -1 Error message. Error message. Lots Error message. Error message. 5.5897 Data accepted, but to 2.dp. Data accepted, but to 2.dp. Insurance _date 23/05/2003* Data accepted. Data accepted. Ab/cd/efgh* Data not accepted. Data not accepted. 13/13/2005* Error message. Error message. 32/01/2004* Error message. Error message. 23/01/2000* Error message.

The insurance cannot be due before the current date.

Error message.

Service_mileage 20000 Data accepted. Data accepted.


0 Error message. Error message. -1 Error message. Error message. Seven miles Error message. Error message. 500.59 Data accepted, but to 0.dp. Data accepted, but to 0.dp. Insurance_payer Company Data accepted. Data accepted. Data accepted. Data accepted. Qwerty Error message. Error message. Initial_mileage 10000 Data accepted. Data accepted. 0 Data accepted. Data accepted. -1 Error message. Error message. Ten miles Error message. Error message. 500.59 Data accepted, but to 0.dp. Data accepted, but to 0.dp. Date (Accident) 23/03/2002** Data accepted. Data accepted. Ab/cd/efgh** Data not accepted. Data not accepted. 13/13/2001** Error message. Error message. 32/01/1980** Error message. Error message. 12/02/2004** Error message.

The accident date cannot be after the current date.

Error message.

Insurance_paid 0 Data accepted. Data accepted. 125.50 Data accepted. Data accepted. -1 Error message. Error message. Lots Error message. Error message. 500.1234 Data accepted, but to 2.dp. Data accepted, but to 2.dp. Amount (of Fuel) 45.20 Data accepted. Data accepted. 0 Error message. Error message. -1 Error message. Error message. Lots Error message. Error message. 59.5897 Data accepted, but to 2.dp. Data accepted, but to 2.dp. Mileage_before_ fuel

10000 Data accepted. Data accepted.

0 Data accepted. Data accepted. -1 Error message. Error message. Zero miles Error message. Error message. 50000.59 Data accepted, but to 0.dp. Data accepted, but to 0.dp. Mileage (past service)


0 Data accepted. Data accepted. -1 Error message. Error message. A Hundred miles Error message. Error message. 12000.12 Data accepted, but to 0.dp. Data accepted, but to 0.dp. Mileage (At MOT) 25 Data accepted. Data accepted. 0 Data accepted. Data accepted. -1 Error message. Error message. Ten miles Error message. Error message. 21345.567 Data accepted, but to 0.dp. Data accepted, but to 0.dp. Mileage (Tyre Replacement)


0 Data accepted. Data accepted. -1 Error message. Error message. Very many Error message. Error message. 1500.25 Data accepted, but to 0.dp. Data accepted, but to 0.dp.


* The same data was entered for the following fields: Tax_date, Service_date, MOT_date and

Goods_vehicle_test_date. The same results also apply.

** The same data was entered for the following fields: Date (Fuel), Date (MOT), Date (Repair), Date

(Service), Date (Tyre) Start_date and End_date. The same results also apply.

HP Form

Field Validation Data Expected Result Actual Result Start_date 23/03/2002 Data accepted. Data accepted. Ab/cd/efgh Data not accepted. Data not accepted. 13/13/2001 Error message. Error message. 32/01/1980 Error message. Error message. 12/02/2004 Error message.

The start date cannot be after the current date.

Error message.

Payment_date 23/05/2003 Data accepted. Data accepted. Ab/cd/efgh Data not accepted. Data not accepted. 13/13/2005 Error message. Error message. 32/01/2004 Error message. Error message.

CH Form

Field Validation Data Expected Result Actual Result Start_date 23/03/2002 Data accepted. Data accepted. Ab/cd/efgh Data not accepted. Data not accepted. 13/13/2001 Error message. Error message. 32/01/1980 Error message. Error message. 12/02/2004 Error message.

The start date cannot be after the current date.

Error message.

End_date 23/05/2003 Data accepted. Data accepted. Ab/cd/efgh Data not accepted. Data not accepted. 13/13/2005 Error message. Error message. 32/01/2004 Error message. Error message. 23/01/2000 Error message.

The contract cannot end before the current date.

Error message.

Initial_mileage 10000 Data accepted. Data accepted. 0 Data accepted. Data accepted. -1 Error message. Error message. Ten miles Error message. Error message. 500.59 Data accepted, but to 0.dp. Data accepted, but to 0.dp. Mileage_allowed 3450 Data accepted. Data accepted. 0 Error message. Error message. -1 Error message. Error message. A hectare Error message. Error message. 1500.11 Data accepted, but to 0.dp. Data accepted, but to 0.dp. Payment_date 23/05/2003 Data accepted. Data accepted. Ab/cd/efgh Data not accepted. Data not accepted. 13/13/2005 Error message. Error message. 32/01/2004 Error message. Error message.


Appendix P) Form testing data and results

Constraint 1: Expiry_date > Pass_date (Driver Table)

Pass_date Expiry_date Expected Result Actual Result 08/07/1980 08/07/2004 Accepted Accepted 08/03/2002 08/01/2002 Error Message, Expiry_date

deleted. Error Message, Expiry_date

deleted. 08/01/2002 08/01/2002 Error Message, Expiry_date

deleted. Error Message, Expiry_date

deleted.

Constraint 2: MOT_date OR Goods_vehicle_test_date (Vehicle Table)

MOT_date GV_test_date Expected Result Actual Result 08/03/2004 Accepted Accepted

08/07/2002 Accepted Accepted Accepted Accepted

08/03/2004 08/07/2002 Error Message, both field deleted. Error Message, both fields deleted.

Constraint 3: Service_mileage >= Initial_mileage (Vehicle Table)

Service_mileage Initial_mileage Expected Result Actual Result 10000 0 Accepted Accepted 10000 10000 Accepted Accepted 10000 20000 Error Message Service_mileage

and initial_mileage deleted. Error Message, Service_mileage

and initial_mileage deleted.

Constraint 4: End_date >= Start_date (Vehicle History Table)

Start_date End_date Expected Result Actual Result 08/03/2002 08/03/2004 Accepted Accepted 31/03/2002 31/03/2002 Accepted Accepted 31/03/2002 04/03/2002 Error Message Error Message

Constraint 5: End_date > Start_date (Contract Hire Table)

Start_date End_date Expected Result Actual Result 08/03/2002 08/03/2004 Accepted Accepted 31/03/2002 31/03/2002 Error Message Error Message 31/03/2002 04/03/2002 Error Message Error Message


Appendix Q) Reports and Query testing input data

Driver Data

Driver 1 Driver 2 Driver 3 Driver 4 Driver 5

Basic Info: Name Arnold Firth Barry White Charles Oaks Dave Smith Eric Jones License HGV HGV Standard Restricted Standard Pass_date 12/03/1990 01/01/1999 21/01/1997 02/02/2001 12/07/1984 Expiry_date 12/03/2040 01/01/2049 21/01/2047 02/02/2051 12/07/2034 Points 0 3 0 6 3 Check_date 17/09/2000 15/02/2001 02/03/2002 Banned_date Disability Broken Leg

Driver 6 Driver 7 Driver 8 Driver 9 Driver 10

Basic Info: Name Fred Chappell George Briars Harry Bassett Ian Goddard John Franks License Standard Restricted Restricted Standard HGV Pass_date 30/12/1998 19/12/2000 25/05/1999 08/03/1980 02/03/1987 Expiry_date 30/12/2048 19/12/2050 25/05/2049 08/03/2030 02/03/2037 Points 12 30 0 0 10 Check_date 15/03/2000 03/03/2002 10/03/2001 Banned_date 15/03/2003 31/03/2002 Disability Diabetes

Note: There is no need to input training and offence details because they are not needed to test any of the reports or queries. Vehicle Data Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6 Basic Info: Registration_No A123 456 B123 456 C123 456 D123 456 E123 456 F123 456 Make Renault Ford Honda Nissan Ford Ford Model Clio Mondeo Civic Micra Focus Mondeo Engine 1.0 1.3 1.2 1.0 1.3 1.6 Fuel Unleaded Unleaded Diesel LRP Unleaded LRP Emissions 1.23 2.34 3.45 4.56 5.67 6.78 Insurance_date 02/03/2004 01/04/2002 31/03/2002 15/04/2002 23/04/2002 19/09/2002 Tax_date 03/04/2002 07/07/2002 04/04/2002 05/12/2002 14/04/2002 15/09/2002 Service_date 14/04/2002 07/07/2002 29/10/2002 02/04/2002 Service_mileage 22800 50320 MOT_date 14/04/2002 31/03/2002 12/09/2002 Goods_vehicle_ test_date

12/04/2002 13/07/2002 01/04/2002

Insurance_payer Driver Company Company Company Driver Company Initial_mileage 10000 0 20000 50000 18000 40000

Vehicle 1 Vehicle 2 Vehicle 3 Vehicle 4 Vehicle 5 Vehicle 6


Accident Info: Date 02/02/1999 01/03/2002 11/12/2001 03/02/1999 Details Crash Hit Cow Collision Crash Blame None Cows Drivers Drivers Insurance_ amount

1500.00 0.00 2000.00 219.56

Notes Accident Info2: Date 03/03/2000 02/03/2002 30/09/2001 Details Hit Fence Collision Crash Blame Drivers Drivers Drivers Insurance_ amount

221.19 1000.00 1000.00

Notes Fuel Info: Date 17/03/2002 17/01/2002 31/01/2002 15/03/2002 29/12/2001 Amount 40.00 50.00 20.00 17.00 12.00 Mileage 10000 0 20000 50000 40000 Fuel Info 2: Date 25/03/2002 18/03/2002 02/03/2002 02/03/2002 Amount 40.00 50.00 25.00 35.00 Mileage 10400 1000 20800 40600 Fuel Info 3: Date 05/03/2002 17/03/2002 Amount 15.00 9.00 Mileage 21800 42350 Tyre Info: Date 12/03/1999 29/01/2002 17/02/1999 25/03/2002 18/06/2000 19/02/2002 Mileage 10000 1000 20400 51000 19000 40300 Reason Worn Worn Puncture Safety Kerbing Puncture Tyre Info 2: Date 18/03/2002 21/09/2001 Mileage 2000 20000 Reason Kerbing Puncture Tyre Info 3: Date 07/12/2001 Mileage 21000 Reason Worn Vehicle History Info:

Driver Eric Jones Barry White Arnold Firth Fred Chappell

John Franks Charles Oaks

Start_date 01/01/1999 20/01/2002 01/01/1998 01/01/2002 01/01/1999 17/03/2001 End_date 02/03/2000 20/03/2002 01/01/2001 08/09/2001 17/01/2002 Vehicle History Info 2:

Driver Dave Smith Ian Goddard Harry Bassett

Eric Jones George Briars

Start_date 03/03/2000 21/03/2002 02/01/2001 09/09/2001 18/02/2002 End_date

Note: There is no need to input MOT, repair or service details because they are not needed to test any of the reports or queries.


Contract Hire Vehicle Data Vehicle 1 Vehicle 2 Vehicle 3 Basic Info: Registration_No A123 456 B123 456 C123 456 Start_date 01/03/2002 01/01/2002 31/03/2002 End_date 31/03/2002 01/01/2003 15/03/2003 Initial_mileage 10000 0 21800 Mileage_allowed 200 2000 10000 Payment Info: Payment_date 01/12/2001 12/02/1999 31/03/2002 Payment_date 2 01/02/2002 15/09/2000 30/04/2002 Payment_date 3 01/04/2002 18/06/2001 30/08/2002 Payment_date 4 31/03/2002

Hire Purchase Vehicle Data Vehicle 1 Vehicle 2 Vehicle 3 Basic Info: Registration_No D123 456 E123 456 F123 456 Start_date 01/02/2000 02/03/2002 07/08/2001 Payment Info: Payment_date 10/02/2001 12/04/2002 12/03/2002 Payment_date 2 31/03/2002 15/05/2002 31/03/2002 Payment_date 3 17/06/2002 15/04/2002 Payment_date 4 29/09/2003


Appendix R) Report testing data and results

The expected and actual results are shown below:

Report/Query Expected Result Actual Result Tax Warning A123 456

C123 456 E123 456

3 days 4 days

14 days

A123 456 C123 456 E123 456

3 days 4 days

14 days MOT Warning E123 456

A123 456 0 days

14 days E123 456 A123 456

0 days 14 days

GV Test Warning D123 456 1 day D123 456 1 day Insurance Warning C123 456

B123 456

Company

Company

0 1

Harry Bassett

Ian Goddard

C123 456

B123 456

Company

Company

0 1

Harry Bassett

Ian Goddard

Service Date Warning F123 456 A123 456

2 days 14 days

F123 456 A123 456

2 days 14 days

Service Mileage Warning D123 456 C123 456

320 miles 1000 miles

D123 456 C123 456

320 miles 1000 miles

HP Payment Warning D123 456 F123 456

D123 456 F123 456

Last HP Payment Warning

D123 456 D123 456

CH Payment Warning B123 456 C123 456

B123 456 C123 456

Lat CH Payment Warning B123 456 B123 456 CH End Warning A123 456 A123 456 CH Mileage Warning A123 456

B123 456 40

38.46 100

90.91 A123 456 B123 456

40 38.46

100 90.91

Driver Ban Warning John Franks John Franks Fuel Consumption Report A123 456

B123 456 C123 456 F123 456

10 20 40 50

A123 456 B123 456 C123 456 F123 456

10 20 40 50

CH Mileage Report A123 456 B123 456 C123 456

100 91 0

40 38 204

A123 456 B123 456 C123 456

100 91 0

40 38 204

Accident Report Eric Jones Barry White Dave Smith

Harry Bassett John Franks

2 2 1 1 1

Eric Jones Barry White Dave Smith

Harry Bassett John Franks

2 2 1 1 1

Tyre Replacement Report Eric Jones Barry White Arnold Firth

Fred Chappell John Franks

George Briars

3 2 1 1 1 1

Eric Jones Barry White Arnold Firth

Fred Chappell John Franks

George Briars

3 2 1 1 1 1


Appendix S) Company Feedback Letter

To whom it may concern. When I heard that Mike had been given the final year project assignment that he wanted to be database related. I approached him with a proposition. For some time I have been wrestling with the task of maintaining fleet records whilst attempting to carry out my duties as an accountant. Fleet management was once a relatively simple task but successive rafts of legislation have made it into a specialist field, which can take up a great deal of time. I explained my basic requirements and Mike was able to put together a working prototype. However I soon realised that the application could be expanded to control much more than the basic functions that I had originally envisaged. Mike has made his own suggestions to improve the operation and output of the database and after a great deal of hard work has produced a fully functioning management tool. I can now not only control the basics such as licence and insurance renewal but I have the data to monitor fuel economy and service intervals, insurance claims and repairs. The database interacts with employee records and provides human resource management information such as driving licence data, driver training and I can also track repairs and accidents and individual vehicle fuel economy by driver. In addition Mike has provided aninteractive help function which when combined with the password protection feature enables me to delegate the more mundane and less sensitive tasks to junior staff. All in all Mike has provided me with an invaluable system and taken a great deal of the effort out of the fleet management process. Yours faithfully WRIGHT (HULL) LIMITED

Steve Antcliff Office Manager


Appendix T) References

Text Sources

[1] Ashworth, Caroline & Goodland, Mike, (1990), SSADM a practical approach, McGraw-Hill

[2] Bennett, Simon, McRobb, Steve and Farmer, Ray, (1999), Object Orientated Systems Analysis and

Design using UML, McGraw-Hill

[3] Date, Christopher John, (1986), An Introduction to Database Systems, Fourth Edition, Addison-Wesley

[4] Dix, Alan J, (1998), Human-computer interaction, Second Edition, Prentice Hall

[5] Hawryszkiewycz I.T, (1994), Systems Analysis and Design, Third Edition, Prentice Hall

[6] Nielsen, Jakob, (1993), Usability Engineering, Academic Press

[7] Prague, Cary, Amo, William & Foxall, James, (1997), Access 97 Secrets, IDG Books

[8] Roberts, Stuart, (2001), DB21: Database principles and practice, School of Computing, University of

Leeds

[9] Ruddle, Roy, (2000), Introduction to Human Computer Interaction, School of Computing, University of

Leeds

[10] Shneiderman, Ben, (1998), Designing a user interface, Third Edition, Addison-Wesley

[11] Van Der Lans, Rick, (2000), Introduction to SQL: Mastering the Relational Database Language, Third

Edition, Addison-Wesley

[12] Whitehorn, Mark and Marklyn, Bill, (2001), Inside Relational Databases, Second Edition, Springer

Internet Sources

[13] Wright homes, URL:http://www.wrightgroup.co.uk (20th December 2001)

[14] Microsoft Office, URL:http://www.microsoft.com/office/access (7th April 2002)

Other Sources

[15] Microsoft Access Help (10th April 2002)

Documents

Fleet Maintenance Management Mike Wardell Accounting … · Mike Wardell Accounting and Computing ... MERISE: MERISE consists of ... SSADM adopts the Waterfall model of systems development,