Booking Management System

Third Year Project Report 2016

COMPUTER SCIENCE (BSc)

Author: Jiebin Su
Supervisor: Dr Caroline Jay

1
 Abstract
This report details the research, approach and evaluation of a web application
designed to help with the day to day operations of Broadoak School of
Motoring in Tameside. This application will allow learners to book their own
driving lessons online as well as act as a platform for driving instructors to
manage bookings.

2
 Acknowledgements
I would like to thank my supervisor, Dr Caroline Jay, for her continuous support
and advice throughout the year. Additionally, I would like to thank my driving
instructor, Dave Unwin, for allowing me to gather requirements and offering
valuable input for the application.

Finally, I would like to thank my family and friends in giving me the motivation
and support during this process.

3
Contents

Introduction ......................................................................................................................... 6
1.1 Project Background ........................................................................................... 6
1.2 Aims and Objectives........................................................................................... 6
Background .......................................................................................................................... 8
2.1 Current System .................................................................................................... 8
2.2 Alternative Systems ........................................................................................... 8
2.3 Mobile vs Web Application ............................................................................ 10
Design ................................................................................................................................... 12
3.1 Software Development Approach .............................................................. 12
3.2 Requirements Gathering ............................................................................... 12
3.3 Task Boards ......................................................................................................... 14
3.3 System Architecture ........................................................................................ 15
3.3 Technology Selection ...................................................................................... 17
3.3.1 Codeigniter Framework ......................................................................... 17
3.3.2 jQuery ............................................................................................................. 17
3.3.3 Google Maps APIs ...................................................................................... 18
3.4 Web Application Design ................................................................................. 18
3.5 Database Structure .......................................................................................... 19
Implementation ................................................................................................................ 20
4.1 User Experience ................................................................................................ 20
4.1.1 Star User Interface.................................................................................... 20
4.1.2 Google Material Design ........................................................................... 20
4.2 Data Constraints and Validation ............................................................... 21
4.3 RESTful Web Service ....................................................................................... 22
Results .................................................................................................................................. 23
5.1 Login ....................................................................................................................... 23
5.2 Dashboard ............................................................................................................ 24
5.2.1 Instructor View........................................................................................... 24
5.2.2 Learner View ............................................................................................... 25
5.3 Account .................................................................................................................. 25
5.4 Learners ................................................................................................................ 26
5.5 Bookings................................................................................................................ 27

4
 5.6 Instructor Schedule ......................................................................................... 28
5.7 Navigation ............................................................................................................ 29
Testing .................................................................................................................................. 30
6.1 Functional Testing ........................................................................................... 30
6.2 System Integration Testing .......................................................................... 30
6.3 Ad-Hoc Testing ................................................................................................... 30
6.4 User Acceptance Testing ............................................................................... 31
6.4.1 Black Box Testing ...................................................................................... 31
6.4.2 Usability Testing ........................................................................................ 31
6.5 Compatibility Testing ..................................................................................... 31
Evaluation ........................................................................................................................... 32
7.1 Usability ................................................................................................................ 32
7.1.1 Think Aloud ..................................................................................................... 32
7.1.2 Task Scenarios ............................................................................................ 32
7.1.3 First Click Analysis ................................................................................... 34
7.1.4 Surveys ........................................................................................................... 34
7.1.5 Summary ....................................................................................................... 35
7.1 Reflection ............................................................................................................. 36
7.2 Future Work ........................................................................................................ 36
7.3 Personal Development .................................................................................... 37
Bibliography ...................................................................................................................... 38
Appendix A ......................................................................................................................... 41
Appendix B ......................................................................................................................... 44

5
Introduction

This chapter gives a project overview by introducing the problem and outlining
the reasons for the proposal of the project as well as detail the aims and
objectives of the project are established.

The author has previously worked as a freelancer for Broadoak School of

Motoring and designed and programmed their website in 2012. Broadoak was
also the driving school the author attended thus much of the insight for this
project were derived from personal experience.

1.1 Project Background

The driving school industry is an industry that is stable and still has room for
growth (AnythingResearch, 2016), however the market is seasonal and the
majority of customers are students (Markam Driving School) and within this
market segment there is heavy competition. Therefore, it is imperative to be
able to differentiate the business from competitors.

During the author’s process in learning how to drive at Broadoak, there were
some inconveniences such as attempting to make a booking via phone and the
instructor unable to discuss due to being on a lesson. Some other issues
include incorrect bookings and forgetting the date of the booking.

From the author’s perspective, a system that would reduce the amount of
these issues would greatly improve customer satisfaction hence led to the
inception of this project.

1.2 Aims and Objectives

The main aim of this project is to obtain a solution to improve the paper based
system, currently used by Broadoak (BroadoakSOM), to aid in managing
bookings, rostering and storing learner information. Customer satisfaction and
ease of use for instructors is also an essential factor.

This project has three explicit objectives:

 Producing a web application to be used by instructors of the driving

school, that acts as a management system for their learners and their
schedule.

6
 Producing a web application to be used by learners of the driving school
and act as a booking management system.
 Evaluating the overall effectiveness of the new system and if it will have
a considerable impact on the day-to-day running of the business.

7
Background

This chapter documents the current system used by Broadoak School of

Motoring, research on alternative existing systems and discussion on technical
decisions that are necessary for the development of a new system.

2.1 Current System

Currently, Broadoak SOM uses a paper based system for all forms of data;
including learner’s contact details, lesson bookings, lesson outcomes and
feedback. Lesson bookings are mainly scheduled over the phone and
immediately after a driving lesson if possible.

While the current system is functional and effective for a small sole trader
business model, it should be noted that Broadoak SOM is an expanding
business and has hired a new female instructor to appeal to female learners.
Therefore, the proposal of an online booking system was accepted to ensure
efficient lesson management.

Advantages of an online booking management system that were established

included attracting new customers while managing existing ones; convenience
for learners and instructors by being able make a to booking during any time
and any day as 40% of bookings are made less than a day in advance (Booksy,
2016). Additionally, it reduces wait time for lesson date and time confirmation
by both parties as well as easy and no hassle cancellation.

The identified disadvantages were internet requirement and training

instructors to be able to use the new application. Due to the worry of lack of
understanding in using the new proposed system, it was decided that the user
experience was vital factor in the success of the application.

2.2 Alternative Systems

Before development, it is important to consider possible existing options and
make a decision after researching competing businesses in the same market.
From this research, it has been determined that the immediate competitors
within the same geolocation (Diamond Driving School, All About Driving, Green
School of Motoring, Tameside Driving School and Mitchells Female Driving

8
School) all adopt the traditional system like Broadoak School of Motoring. For
larger driving schools such as Bill Plant and Red Driving School which have
instructors throughout the UK have their own online booking system.

Figure 1 Bill Plant Online Booking (Bill Plant Driving School)

Bill Plant uses the traditional system coupled with a basic email form, where
the learner would enter his details and send a request for a lesson and the
instructor would call back when possible to discuss with the learner the lesson
time and date.

Figure 2 Red Driving School Booking System (Red Driving School)

9
Red Driving School uses a more advanced booking system compared to Bill
Plant, allowing the learner to select a desired available date and time and the
select another instructor allows you to change your current recommended
instructor once.

From studying these existing options, a lot of insight and ideas were generated
and the decision to create a new system was made as it allows the
implementation of features tailored specifically for instructors at Broadoak and
also allows the author to give immediate technical support.

2.3 Mobile vs Web Application

A debate on whether a web or mobile application was best suited occurred as
there are arguments for both applications.

The instructor reasoned that due to the nature of the job, a mobile application
would be most appropriate as instructors will need to access the information
before and after a lesson. After explaining that a web application can also be
used on a mobile and the majority of mobile users spend little time browsing
the web and thus a low chance of coming across the downloadable mobile app
on their website. The monthly usage rate chart below can support this.

Figure 3 Monthly Usage of App and Mobile Web (Chaffey, 2016)

10
A cross-browser web application can be cross-platform and therefore able to
engage both web and mobile/tablet users. The advantage of a native mobile
application would be the performance compared to web views (Cho, 2015).

After the market research and further discussion, it was decided that the
creation of a web application as a base is more important and a native mobile
application can be developed in the future.

11
Design

This chapter presents the approach, the architecture and some of the
technologies used during the development of the web application as well as
insight into the thought process in deciding these factors.

3.1 Software Development Approach

There are many different software development approaches such as agile,
lean, feature-driven and waterfall methodologies that all excel at different
areas.

For this project, end users are defined, requirements are unclear and due to
the limited development time for this application it is important for the
business to have some form of a working product thus using agile methods and
techniques, an iterative and incremental approach was taken.

Agile principles value working software over documentation and are meant to
be adaptive and responsive to changing situations (Yu & Petter, 2014). Agile
methodologies are best suited to projects that have unstable scopes and
requirements as it would be difficult to follow a predictable software
development process model (Mishra & Mishra, 2011). Additionally, agile
methods require continuous delivery of functionality that adds business value,
which allows for continuous feedback and testing by the end user.

Some of the agile practices used in the project development process will be
explained in this chapter.

3.2 Requirements Gathering

Requirements gathering is the cornerstone to any successful project, they are
critical for scoping, defining, and managing the project. In agile projects,
achieving desired results requires a measured approach that may be unique to
each organisation (PWC, 2014).

In agile, only the minimum level of documentation necessary is produced to

save time on areas that do not add value to the business (Cooke, 2014).
Hence for this project, a broad scope of the project was defined at the
beginning and thereafter the use of User Stories was employed. Stories are an
alternative to specification documents; they represent a small piece of

12
functionality that provides some sort of business value. Stories were written in
the connextra format “As a (role) I want (functionality) so that (value)” as
suggested by Mike Cohn (Cohn, 2004).

The user story acts as a reminder to discuss in further detail when the
respective story is to be implemented in the upcoming iteration. User stories
are also assets in the planning process of agile projects as they allow for
scheduling and estimation.

A numerical prioritisation strategy was used, where a story is assigned an

arbitrary value for its presumed business value and also an effort rating, an
example from the first iteration is shown in Table 1.

User Story Value Difficulty

As a Learner, I want to be able to 100 5
make a booking for a driving
lesson.
As a Learner, I want a calendar to 50 15
view a timetable of my driving
lessons.
As an Instructor, I want a way to 30 5
view all my students and their
details.
As a Learner/Instructor, I want a 20 5
dashboard to show my current
lessons, notifications and
important information.
As a Learner/Instructor, I want a 20 10
login system to keep my personal
information safe.
As an Instructor, I want a 20 40
navigation system to help direct
me to my student’s destination.
Table 1 Iteration One User Stories

The highest value to lowest effort ratio is of the highest priority and for each
iteration, the highest priority stories are implemented first as shown in the
process in figure 4.

13
 Figure 4 Selecting Stories to be implemented (Ambler)

Aside from the set of functional requirements gathered using user stories, it is
important to consider non-functional requirements such as usability,
compatibility, security and robustness. Being able to incorporate these
requirements would result in being closer to achieving the goals of the
application.

3.3 Task Boards

A task board is a visual tool providing an at-a-glance reference for the
developers and stakeholders, serving as a daily reminder of the goal and the
functionalities the developers have committed to (Bowes, 2014).

Through requirements gathering, user stories were generated and added to

the “Backlog” column of the task board. A meeting at the beginning an
iteration occurs and stories that are selected to be implemented for that
iteration is discussed in further detail. At this point, the selected story will be
moved from the “Backlog” to the “In Progress” column. As soon as a story is
believed to be complete, it is moved to the “Completed” column. At the end of
the iteration, the client would test and verify the “Completed” stories. If the
story did not pass the client validation, it would be moved back to the
“Backlog”, otherwise it would remain in the “Completed” column.

14
Functionality from stories that are moved back to the “Backlog” can either be
completely removed from the application if the client doesn’t require it
anymore or the business value it adds is not worth the time required to make it
functional. However, if it only requires minor changes or bug fixes it will be
moved back to the “In Progress” column to be worked on for the next
iteration.

Task boards are more commonly used in team environments as it shows clearly
the number of stories in progress and the distribution of names reveal whether
the collaboration is apparent in the team or each team member is working
alone (Lawrence, 2011). However, it was also beneficial for this project
because it provided a method of organising requirements that promotes
interaction, as it is placed in an open space visible to all stakeholders,
encouraging conversation.

3.3 System Architecture

Following agile principles, functionality delivered should be a thin end-to-end
slice and after some consideration the project was built using a Model-View-
Controller (MVC) architecture. A Controller class is inserted between the View
and the Model layers to remove model-view dependencies causes a separation
of concerns, less coupling between layers and code reuse. This makes
maintenance and adding new functionality easier.

The Model contains the logical data structure and handles all database
transactions. It receives input from the controller and decides what data is
required. The View contains the user interface controls the end user uses to
interact with the application, composing of HTML, CSS and JavaScript. The
Controller retrieves datasets from the Model and formats it before sending it
to the View, all events originating from the View is handled by the Controller.

For maintainability and readability of code, access to data in stored procedures

is executed in the model layer and therefore no SQL code is used in View or
Controller layers.

Google Chrome, Mozilla Firefox and Internet Explorer are the main web
browsers the web application supports and used for testing. These three
browsers were chosen as they are the top most used browsers for several
years (Browser Statistics, 2016). This is to provide cross-browser compatibility
and ensure the application is usable to the widest range of audiences.

15
 Figure 5 MVC Architecture (Brinkman-Davis)

An alternative to this MVC pattern that was considered was the Model-View-
Presenter (MVP) design pattern shown in figure 6. MVC and MVP are very
similar in that they both are concerned with separating concerns and contain
Model and View layers. The major difference is that in MVC, the Controller
handles all mouse and keyboard events (Haack, 2008); whereas in MVP, the
Graphical User Interface components handles the user inputs and delegate the
interpretation of the input to the Presenter layer (Potel, 1996). This difference
was the deciding factor on selecting MVC over MVP as User Experience is a
primary factor in creating a successful web application and being able to design
the graphical components of the application separately with MVC is essential.
This is because there is no universal set framework for determining good UX
and thus user-centred design methods are employed, which leads to multiple
iterations of deliverables thus MVP will require multiple changes in the
Presenter layer instead of only the View layer.

Figure 6 MVP Design Pattern (TAMBOLI, 2011)

16
3.3 Technology Selection
Due to the nature of agile development, valuing individuals and interactions
over processes and tools (Apke, 2014), tools that amplify an individual’s
effectiveness are chosen instead of tools that require the individual to steer
and control as long as it satisfies the client’s needs (Relevance Inc).

3.3.1 Codeigniter Framework

“Codeigniter is a powerful PHP framework with a very small footprint, built for
developers who need a simple and elegant toolkit to create full-featured web
applications” (Codeigniter). Codeigniter (CI) offers many features that are
favourable for the development of the web application. Codeigniter offers a
MVC based system satisfying our chosen architecture. At the start, non-
functional requirements such as Security were considered and CI is regularly
updated thus new security protocols are constantly added to tackle new
vulnerabilities. The templating system CI offers allows pages to be more
responsive, this is by separating components of the page and only loading new
data when necessary. For example, the navigation would be loaded at the start
and will not be required to refresh or reload saving loading time and
bandwidth.

A PHP framework was selected as the author has had previous experience with
this programming language unlike AngularJS and ASP. In 2015 a PHP
framework popularity survey was conducted and Laravel won by a large
margin (Skvorc, 2015). Laravel was an alternative that was considered which
offered many of the same features that Codeigniter did but the main problem
was the web server compatibility (Otwell). The development of the web
application using Laravel was possible but new and more expensive web
hosting was necessary for Broadoak and therefore the option was rejected.

Another reason for choosing Codeigniter was it offered Bootstrap integration.

Bootstrap is the most popular HTML, CSS and JS framework for developing
responsive web applications. Bootstrap offers cross-browser compatibility and
details coding conventions which allow web applications to become more
consistent over all platforms (Bootstrap).

3.3.2 jQuery
jQuery is a lightweight JavaScript library, which offers a feature-rich API (The
jQuery Foundation). The features used in the web application include CSS
manipulation, event handling, animation and AJAX.
17
Integrating jQuery into the project was useful in handling cross-browser issues
as different browsers and different versions of browsers interpret pure
JavaScript differently and thus using jQuery eliminates the need to write
different code for multiple browsers.

AJAX was used for asynchronous exchanging of data with the database and
creating dynamic content on web pages.

3.3.3 Google Maps APIs

The Google Maps APIs are a collection of APIs that help build new location
experiences via a HTTP web service (Google). The APIs used in the web
application are Directions, Distance Matrix, Geocoding and Geolocation APIs.
The Geocoding API is used to convert addresses to geographic coordinates and
the Distance Matrix API is used to predict travel time based on historical time-
of-day and day-of-week data. The Geolocation API is used for pulling location
data from cell towers and Wi-Fi nodes to predict the user's current location,
acting as a Global Position System. Finally, the Directions API is used to plan
routes for transit, using Waypoints to plot a journey for the Instructor for the
specific working day.

3.4 Web Application Design

Initially sketches on papers were made to help decide how the application
should be visually. The basic structure of the page was established from the
sketches and only a basic design was done using bootstrap themes at first. This
was because the implementation of functionality that adds value to the
business, such as the lesson booking component, is of higher priority than the
graphical user interface design. After the important functionality of the system
was completed more focus was brought onto the User Experience aspect of
the web application, which encompasses all aspects of the end-user's
interaction with the business including the visual design as expressed by the
Nielsen Norman Group (Norman & Nielsen). Methods and techniques used to
tackle the UX facet will be further discussed in the implementation phase of
the report.

18
3.5 Database Structure
Following agile principles and implementing end-to-end functionalities means
the tables are created only when necessary thus the KISS (Keep It Simple
Stupid) principle was enforced to ensure stories being implemented later will
not cause any conflicts. The structure of the existing database is simple; each
table has an auto-incrementing primary key and each table has a relationship
with another existing table. A data dictionary has been included in Appendix A.

19
Implementation

This chapter discusses the processes and techniques used in the

implementation of the web application, with an emphasis on the user
experience domain.

4.1 User Experience

4.1.1 Star User Interface
The Xerox Star development team released the ‘Designing the star user
interface’ article in 1982, changing the notions of how interactive systems
should be designed, introducing a set of key principles to enhance user
experience by simplifying human-machine interaction (Smith, Irby, Kimball,
Verplank, & Harslem, 1989).
The five key principles for enhancing user experience are (Harper, 2012):
 Familiar Conceptual Models
 Universal Commands
 Consistency
 Simplicity
 User Tailor-ability
These principles were kept in mind when designing the web application and
adhered to when possible. For example, the system abided by the
conventional concepts of any application, whenever a button or a link is
clicked, an expected event occurs; whenever data is saved, it can be retrieved;
and so forth. Universal commands were handled by the PHP backend; the web
design and structure is kept consistent and simple. The User Tailor-ability
principle was considered in the navigation design to allow for showing and
hiding links and editable user preference settings.

4.1.2 Google Material Design

Material Design is a visual language created by Google, “that synthesises the
classic principles of good design with the innovation and possibility of
technology and science” (Google). Matias Duarte explains “unlike real paper,
our digital material can expand and reform intelligently. Material has physical
surfaces and edges. Seams and shadows provide meaning about what you can
20
touch” and Material Design is a reflection of this. It also provides a system that
allows for a unified experience across all platforms and resolutions.

Some of the principles adhered to, include:

 Material is the metaphor
 Surfaces are intuitive and natural
 One adaptive design
 Content is bold, graphic and intentional
 Users initiate change
 Motion provides meaning

A material metaphor is the unifying theory of rationalised space and the

Broadoak application follows the Bootstrap responsive grid system which also
complies with the adaptive design principle as each view from a device is
tailored to its size and interaction while keeping colours, icons and spatial
relationships constant (Summers, 2015).

Surfaces and edges provide visual cues for our experience of reality and the
use of these familiar attributes speaks to primal parts of our brain and help us
understand dimensional affordances. Elevation and shadows are used in the
design to form a familiar spatial model that can be applied consistently
throughout the application (Google).

Good design will create hierarchy, meaning and focus; whereas good structure
will create immersion and clarity. The Broadoak application follows the
Material layout principles and utilises ‘Material colours’, edge-to-edge
imagery, typography and intentional white space to achieve this.

Changes to the web interface is derived from only user actions and these
changes activate animations serving to focus user attention and maintain
continuity.

4.2 Data Constraints and Validation

Data constraints and validation were used to ensure input were of the correct
format and the correct information was being saved. This was extensively used
in the booking and account areas of the web application. For example, data
constraints used in the account section, were length limits for mobile numbers.
An instance of validation would be using Google API to check if the address and
postcode were valid.

21
4.3 RESTful Web Service
At the beginning of the development, a native mobile application was
discussed and it was decided that it would be attempted once the web
application was completed. This aspect has been acknowledged during the
implementation of certain functionalities to ensure the end system can
interact with the future mobile application. The creation of a RESTful API was a
solution to this problem.

REST is an acronym for Representational State Transfer, which is a software

architecture style and approach to communications in the development of
Web Services (Abeysinghe, 2008).

HTTP requests made via the RESTful service will be forwarded to a Controller
which receives and processes the request, retrieving data from the database or
executes relevant queries. It is then transferred to a Service Handler which
decides the type of response to return (Vincy, 2015).

REST API has been created for handling bookings and account information,
which are the main functionality of the web and future mobile application.

An example of execution is shown in the figure below.

localhost/broadoak/index.php/api/account/learners/id/1.xml

This sends a HTTP GET request to the Controller account, learners_get()

function with parameter id of value 1, returning in xml format. Other
supported formats include JSON and HTML and plain text.

22
Results

This chapter examines the end result for the web application, with a detailed
walkthrough of the functionality. Screenshots will be provided to aid the
explanation and demonstrate the look and feel of the components.

5.1 Login

The login system takes the email address and password of users, when the
“Sign In” button is clicked, input validation for the email will occur and if it is
successful, a POST request will be sent to the Controller layer where it calls an
user authentication method in the Model to see if the email and password
match. If details are correct, a user session with related user data, pulled from
the database, is created and the page redirects to the Dashboard.

23
5.2 Dashboard
5.2.1 Instructor View

If the user ‘Right’ is above 1, then the user is an instructor or administrator

thus they will have access to the view above. FlotJS is a jQuery plotting library
used to display the age demographic in a more attractive manner, abiding by
the Material Design principles. The Heatmap panel uses Google API to plot the
highly condensed areas of registered learners on a map, to help provide
geographical data that may be helpful in marketing strategy. The Booked
Lessons panel will show upcoming lessons that learners have booked with said
instructor.

24
5.2.2 Learner View

If the user does not have the correct rights, they will be deemed as a learner
and upcoming lessons and lesson feedback is shown in the dashboard. Lesson
feedback provides a summary of the driving lessons and a score to help the
learner assess their capabilities and help their learning.

5.3 Account

This is the page that allows users to modify their account details, from address
to personal information, which all abide by a set of data validation rules and

25
constraints to ensure the correct information is given. The date of birth
requires the user to be aged 17 or over, mobile 11 digits and a valid email.
Address information is required to be valid and is confirmed using Google API.
User password can be changed in the Security tab.
The Holidays tab is only viewable for Instructors, and it allows them to set days
off work. When a holiday date is set, all bookings on that date for that
instructor will be cancelled automatically.

5.4 Learners

The learners tab is only viewable to Instructors and allows them to search for
registered learners and view their user profile, the green active particle shows
the user has last used the web application less than a month ago.

26
When viewing their profile information, Instructors also have an option to
book a lesson for them using the system.

5.5 Bookings

The booking system allows users to select a desired date and one or more time
slots for their lesson. The selected date must be between within a month and a
day in advance and this is a data constraint set in the Date Picker and
Controller.

The Date Picker widget is activated when a click event occurs within the date
input area. It does not allow users to select days not within the constraints set.

27
After selecting a day, you will be able to select from a list of available time slots
which is dynamically updated using jQuery. Each time slot is an hour long
whilst taking into account the driving time from the instructor to the learner’s
address for optimisation purposes.

5.6 Instructor Schedule

Instructor are able to view their daily schedule which is dynamically updated if
any lesson is cancelled at the last minute. Google Directions API is also used to
generate approximate distance and time to destination.
28
5.7 Navigation

The entire navigation and its links are collapsible, when it is toggled, using
JavaScript the constituent parts are animated to slide left and up to be hidden
following the Material Design principles in section 4.1.2. Certain links are only
viewable to Instructors, such as the Learners tab and Search hyperlink.

29
Testing

This chapter describes the extensive testing processes that were undertaken to
ensure requirements and specification were met with a high standard.

6.1 Functional Testing

Functional testing of the system was done on a constant basis in conjunction
with the implementation of each user story functionality. This allows for the
detection of bugs at an early stage which will reduce the high maintenance
costs if discovered later. For example, ensuring a booking slot for a specific day
can only be reserved once and appear on the booking schedule.

As an agile philosophy was followed, the functional requirements were

discussed only after the respective story was selected for implementation for
that specific iteration and notes were written on the reverse of the user story.
This allowed the requirements to be fresh in the mind of the developer.

If bugs were identified and not fixed during that iteration, its respective user
story would not be moved to “Complete” on the task board. If no bugs were
detected or all bugs were fixed, the story would undergo System Integration
and Ad Hoc tests.

6.2 System Integration Testing

After passing functional tests, the main functionality of the relevant sub-
systems would be tested. This mostly applied to the Booking sub-system and
the Schedule sub-system that retrieves the booking information and utilises
Google Maps APIs to display the daily itinerary in the form of waypoints.
System Integration Testing did not uncover any hidden issues; this may be due
to the errors being caught and fixed during functional testing.

6.3 Ad-Hoc Testing

Unlike Functional and System Integration testing, Ad-hoc is an informal and
unstructured software test designed to find defects and break the software. It
is an effective method as the developer may have an unconscious bias when
examining functionality. Most problems detected were due to front-end input

30
issues rather than back-end problems, which is difficult for Functional and
System Integration testing to detect. For example, one issue was when using
the Date Picker for the Booking System, if a click was registered outside of the
box, it would return back to the form which was intended but the Date Picker
could not be re-used unless the user refreshed the page.

6.4 User Acceptance Testing

At the end of each iteration, prototypes for all “complete” user story
functionalities were shown to the client. The following tests were used to
ensure the functionality behaves appropriately and up to satisfactory
standards as well as collect feedback that may be valuable for future story
implementations.

6.4.1 Black Box Testing

Black Box testing is conducted with the client, allowing the client to analyse the
functionalities with no specific knowledge of the features. Black box testers are
only aware of what the software is supposed to do, but they don’t know how it
should be done (Peham, 2015).

6.4.2 Usability Testing

Usability testing was used to understand how user friendly the application is.
While the client interacts with the application, his behaviour was observed and
feedback was collected on what changes were required to make the
application easier to use or more intuitive. Usability testing was very important
as the most trivial elements can have a considerable impact on a user’s
understanding of the software. For example, the naming conventions of the
navigation links and the placement of design artefacts affects how easy it is to
find and use certain functionality.

6.5 Compatibility Testing

The web application was tested for compatibility on Google Chrome, Mozilla
Firefox and Internet Explorer on multiple resolutions using the respective
browsers and also the browser’s Web Developer Tools. The Web Developer
Tools in these browsers also offer a device toggle which is a mobile web
simulator to allow for cross-platform compatibility testing. There were a few
CSS problems due to the difference in how these browsers interpret and
render the website so browser-specific CSS had to be incorporated.

31
Evaluation

This chapter describes the methods of evaluating the effectiveness of the web
application post-implementation, insuring both quantitative and qualitative
data measures were considered.

7.1 Usability
For a successful adoption of the application by learners, it is imperative for
them to be able to use the booking system easily. This also applies to
instructors at Broadoak, to reduce time and cost spent training instructors in
using the app.

7.1.1 Think Aloud

Participants are asked to use the system while continuously speaking their
thoughts aloud as they navigate through the user interface. Jakob Nielson
believes thinking aloud may be the single most valuable usability engineering
method (Nielsen, 2012). This is because what the users really think about the
design is discovered and any misconceptions in the design elements will arise
and can be changed. Thinking aloud is also a cheap, robust and flexible
usability tool.

7.1.2 Task Scenarios

The identified end-users of the booking management system are Learners and
Instructors and different tasks were planned for each user group based on
their usage patterns. These tasks represent the most common user goals for
the respective user group. All participants start the usability tests at the
Dashboard. The task scenario must avoid clues and describing the steps to
abstain from bias (Nielsen Norman Group, 2014).

Tasks for Instructor End-user

The client was the sole participant for this exercise.

1. Make a booking for next Tuesday for Sarah Parker.

The client was able to carry out this task without prompt but the
completion of the task but he expressed that making a booking for a
learner could be more intuitive as he had to navigate through the
Learner Search page then View Learner Details before Booking a Lesson
for the learner.

32
 2. Change your current mobile number.
The task was easily understood and carried out by the client, noting that
finding the page to modify user information was easier than the
previous task.

3. Apply for a holiday on the 20th May.

This task took longer than expected and required prompting for the
client to be able to reach the page for Instructor holiday bookings. The
process of making the booking was many times easier remarked by the
client.

4. Check how many lessons you have for the day.

This was a task was relatively simple and has several different ways to be
completed so it was interesting to see the option and the thinking
behind decisions made by the client. The lessons of the day could be
viewed in the Dashboard, Schedule or View Bookings and the booking
data is displayed in a different manner in each page. The client viewed
the schedule immediately and when queried about the decision, he
expressed it was done without thinking.

5. Cancel the booking you made previously for Sarah.

Again this task was easily completed as there are many areas of the
website that have the functionality to view and cancel existing bookings.

Tasks for Learner End-user

Participants for these tasks consisted of students and associates that are of the
driving age.

1. Make a booking for next Wednesday at any time in the morning.

This task was completed by all participants with no problems, many of
the participants expressed positive opinions on the booking system.

2. Check when your next driving lessons is.

This task had two solutions, using the Dashboard or the View Bookings
page and the majority of participants remembered that the Dashboard
had an Upcoming Bookings panel so they reacted instinctively without
much thought. The participants that did not notice the Upcoming
Bookings panel navigated towards the View Bookings with no problem
either.

33
 3. Cancel the booking you made previously.
This task was completed immediately by participants and there were
almost no comments as the task was short.

7.1.3 First Click Analysis

First Click Analysis examines participants first click based event on the interface
in order to complete their set task. Research shows that a participant who
generates the correct click based event first time will complete their task
successfully 87% of the time otherwise the task completion rate is 46%
(usability.gov, 2013). Therefore, it allows you to evaluate the effectiveness of
the linking structure of your web application.

Tasks for Instructor End-user

The two task scenarios that had incorrect first clicks are:
 Make a booking for next Tuesday for Sarah Parker.
 Apply for a holiday on the 20th May.

This first-click data coupled with the qualitative feedback from the task
scenarios correlate and show that the linking structure may be attributing to
the poor UX for those specific tasks.

The first clicks of the Learner-based tasks were generally correct and that may
be due to the interface of the Learner Booking System has less options thus
less wrong options.

7.1.4 Surveys
"Surveys are best used as tools to rate user experiences and users’ needs and
preferences as they relate to system features" (UsabilityFirst, 2015). Surveys
are a quantitative data gathering method for user's opinions about a product.
Unlike interviews, follow-up questions cannot be asked and thus the survey
questions should be clear and planned well. Surveys were used to evaluate the
experience of the web application for Learners. The survey was specifically
designed to have a logical flow to make questions easy to understand, relevant
to the context and short to ensure the participant would not lose interest or
commitment.

The results from the conducted survey are shown in Appendix B.

34
Feedback from surveys suggest that the concept of a driving lesson booking
system is generally new and would have a considerable impact in the choice of
selecting a driving school. The design of the web application has been well
received, however there were many responses on their thoughts on improving
the website which will be considered in the future continued development of
the application.

7.1.5 Summary
The evaluation of the web application shows that there are definite
improvements to be made, mostly quality of life changes that require minimal
effort but has a considerable impact in the way users think about using the
application.

35
Conclusion
This chapter reviews the successfulness of achieving the set objectives and
reflects on the author’s personal development, in addition to the details of the
continuation of the web application.

7.1 Reflection
The main objectives defined at the start of the report were:
 Producing a web application to be used by instructors of the driving
school, that acts as a management system for their learners and their
schedule.
 Producing a web application to be used by learners of the driving school
and act as a booking management system.
 Evaluating the overall effectiveness of the new system and if it will have
a considerable impact on the day-to-day running of the business.

The functionalities required for managing bookings for learners and instructors
have been completed as shown in Results in section 5. The scheduling and
rostering system for instructors is also operational, therefore the first two
objectives have been achieved. However, a definite conclusion on the
effectiveness of the system cannot be drawn until the application is released
live into the business environment and research on the app usage is analysed.
From the evaluation and feedback, it is believed that there is definitely a
considerable interest in online bookings compared to via traditional methods.

7.2 Future Work

There are several components of the web application that could be expanded
upon and functionality that has been left out due to time constraints.

The Booking Suggestion System and the Global Notification System are
worthwhile features that were not fully implemented in time for submission.

The Booking Suggestion System is a feature that can speed up the booking
process for users using a Heuristic algorithm which considers the most

36
frequent time slots and days by the user. The development of this system was
left incomplete as it was too time consuming as creating a great suggestion
system requires an incredible amount of research and user data which was
difficult to obtain without the web application being live to real live users.

The Global Notification System handles all alerts and reminders for all
platforms; for example, when a booking is cancelled all related parties are
notified by user preference (text, email) and alerted via a web popup or push
notification if being accessed using a mobile device.

A native mobile application is in discussion with the client and the base API
created using RESTful web services will allow for easier back-end
implementation.

Completion of these features, though not necessary, would greatly improve

user experience and satisfaction.

7.3 Personal Development

This opportunity has given the author learning experiences beyond the scope
of what was noted in this report. The challenges encountered during
development forced the author to research, digest and regurgitate various
software development approaches, methodologies and practices which
enabled the author to reach higher levels in Bloom’s Taxonomy.

37
Bibliography
1. Abeysinghe, S. (2008). RESTful PHP Web Services. Packt Publishing.
2. Ambler, S. W. (n.d.). User Stories: An Agile Introduction. Retrieved from
AgileModeling: http://www.agilemodeling.com/artifacts/userStory.htm
3. AnythingResearch. (2016, 4 2). 2016 Market Research Report on Automobile Driving
Schools Industry. Retrieved from AnythingResearch:
http://www.anythingresearch.com/industry/Automobile-Driving-Schools.htm
4. Apke, L. (2014). Understanding The Agile Manifesto: A Brief & Bold Guide to Agile.
Amazon Digital Services LLC.
5. Bill Plant Driving School. (n.d.). Book a Driving Lesson. Retrieved from Bill Plant
Driving School: http://www.billplant.co.uk/booking.php
6. Booksy. (2016, 1 7). Pros and cons of booking online. Retrieved from Booksy:
https://booksy.net/blog/us/pros-and-cons-of-booking-online/
7. Bootstrap. (n.d.). Bootstrap. Retrieved from Bootstrap: http://getbootstrap.com/
8. Bowes, J. (2014, 10 2). Agile concepts: the Scrum Task Board. Retrieved from
Manifesto: https://manifesto.co.uk/agile-concepts-scrum-task-board/
9. Brinkman-Davis, S. (n.d.). Basic Of Web Development. Retrieved from Basic Of Web
Development:
https://basicsofwebdevelopment.files.wordpress.com/2015/01/mvc_role_diagram.p
ng
10.BroadoakSOM. (n.d.). Broadoak School of Motoring. Retrieved from BroadoakSOM:
http://broadoaksom.co.uk/
11.Browser Statistics. (2016). Retrieved from w3schools:
http://www.w3schools.com/browsers/browsers_stats.asp
12.Chaffey, D. (2016, 4 27). Mobile Marketing Statistics. Retrieved from Smart Insights:
http://www.smartinsights.com/mobile-marketing/mobile-marketing-
analytics/mobile-marketing-statistics/
13.Cho, P. (2015, 8 3). Benefits of Native vs Hybrid Mobile Apps. Retrieved from Phase2:
https://www.phase2technology.com/blog/the-benefits-of-native-vs-hybrid-mobile-
apps/
14.Codeigniter. (n.d.). Codeigniter. Retrieved from Codeigniter:
https://www.codeigniter.com/
15.Cohn, M. (2004). User Stories Applied: For Agile Software Development. Addison-
Wesley Professional.
16.Cooke, J. (2014, 5 29). Agile vs Waterfall: Requirement Gathering. Retrieved from
BlackPepper: http://www.blackpepper.co.uk/agile-vs-waterfall-requirement-
gathering/
17.Google. (n.d.). Google Developers. Retrieved 4 2016, from Google:
https://developers.google.com/maps/get-started/
18.Google. (n.d.). Material Design. Retrieved 4 2016, from Google:
https://www.google.com/design/spec/material-design/introduction.html

38
19.Haack, P. (2008, 6 16). Everything You Wanted To Know About MVC and MVP But
Were Afraid To Ask. Retrieved from Haacked:
http://haacked.com/archive/2008/06/16/everything-you-wanted-to-know-about-
mvc-and-mvp-but.aspx/
20.Harper, S. (2012, 1 10). Designing the Star User Interface. Retrieved from Bugs
Become Features: https://simon.harper.name/2012/01/10/designing-the-star-user-
interface-ux/
21.Lawrence, R. (2011, 11 21). Making Agile a Reality. Retrieved from Agile For All:
http://agileforall.com/building-a-useful-task-board/
22.Markam Driving School. (n.d.). Driving School Business Plan. Retrieved from BPlans:
http://www.bplans.com/driving_school_business_plan/market_analysis_summary_f
c.php
23.Mishra, D., & Mishra, A. (2011). Complex software project development: agile
methods adoption. 23: 549-564.
24.Nielsen Norman Group. (2014, 1 12). Turn User Goals into Task Scenarios for
Usability Testing. Retrieved from Nielsen Norman Group:
https://www.nngroup.com/articles/task-scenarios-usability-testing/
25.Nielsen, J. (2012, 1 16). Thinking Aloud: #1 Usability Tool. Retrieved from Nielsen
Norman Group: https://www.nngroup.com/articles/thinking-aloud-the-1-usability-
tool/
26.Norman, D., & Nielsen, J. (n.d.). The Definition of User Experience. Retrieved from
Nielsen Norman Group: https://www.nngroup.com/articles/definition-user-
experience/
27.Otwell, T. (n.d.). Laravel. Retrieved from Laravel: https://laravel.com/
28.Peham, T. (2015, 10). 5 TYPES OF USER ACCEPTANCE TESTS. Retrieved from
UserSnap: http://usersnap.com/blog/types-user-acceptance-tests-frameworks/
29.Potel, M. (1996). MVP: Model-View-Presenter. Taligent. Retrieved from Wildcrest:
http://www.wildcrest.com/Potel/Portfolio/mvp.pdf
30.PWC. (2014). Adopting an Agile methodology Requirements gathering and delivery.
PricewaterhouseCoopers LLP.
31.Red Driving School. (n.d.). Book and Pay Online. Retrieved from Red Driving School:
https://student.go-red.co.uk/bookpayonline/existingornew.aspx
32.Relevance Inc. (n.d.). Agile Principles. Retrieved from Think Revelance:
http://thinkrelevance.com/how-we-work/agile_principles
33.Skvorc, B. (2015, 3 30). The Best PHP Framework for 2015: SitePoint Survey Results.
Retrieved from Sitepoint: http://www.sitepoint.com/best-php-framework-2015-
sitepoint-survey-results/
34.Smith, D. C., Irby, C., Kimball, R., Verplank, B., & Harslem, E. (1989). Perspectives on
the computer revolution. Norwood: Ablex Publishing Corp.
35.Summers, N. (2015, 5). Principles Google Created. Retrieved from The Next Web:
http://thenextweb.com/google/2014/06/26/google-explains-principles-material-
design-language-android-chrome-web/
36.TAMBOLI, P. (2011, 11 17). MVP Pattern. Retrieved from Impulse Code:
http://impulsecode.blogspot.co.uk/2011/11/mvp-pattern.html
37.The jQuery Foundation. (n.d.). jQuery. Retrieved from jQuery: https://jquery.com/
39
38.usability.gov. (2013, 9 6). First Click Testing. Retrieved from usability.gov:
http://www.usability.gov/how-to-and-tools/methods/first-click-testing.html
39.UsabilityFirst. (2015, 2 28). Surveys. Retrieved from usabilityfirst:
http://www.usabilityfirst.com/usability-methods/surveys/
40.Vincy. (2015, 10 18). PHP RESTful Web Service. Retrieved from phppot:
http://phppot.com/php/php-restful-web-service/
41.Yu, X., & Petter, S. (2014). Understanding agile software development practices using
shared mental models theory. Information and Software Technology, 911-921.

40
Appendix A

Data Dictionary

41
42
43
Appendix B

Usability Survey Results for Learners

44
45
46
47
48