Booking Management System: Third Year Project Report 2016
Booking Management System: Third Year Project Report 2016
Booking Management System: Third Year Project Report 2016
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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
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.
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.
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.
localhost/broadoak/index.php/api/account/learners/id/1.xml
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
44
45
46
47
48