Wheretrip.Com Bachelor Thesis

Wheretrip.Com Bachelor Thesis

Wheretrip.com Bachelor Thesis R. Bergström M. Simidžioski G Spek Technische Universiteit Delft WHERETRIP.COM BACHELOR THESIS by R. Bergström M. Simidžioski G Spek in partial fulfillment of the requirements for the degree of Bachelor of Science in Computer Science at the Delft University of Technology, Project Duration: November 13, 2017 - February 1, 2018 Supervisor: dr. ir. O. Visser Thesis committee: dr. ir. O. Visser, TU Delft Asst. Prof. H. Wang, TU Delft S. van der Helm, Wheretrip This thesis is confidential and only the latest version can be made public after the 1st of February, 2018 An electronic version of this thesis is available at http://repository.tudelft.nl/. PREFACE This is the report for the completion of our (everyone except Rasmus who is an exchange student) Bachelor degrees in Computer Science. It documents a ten week project for the startup company Wheretrip. The project involved a full rewrite of the code base of the company, with many improvements for extensibility and modularity. Though it failed to meet the goals set forth at its outset, we are of the opinion that we have drastically improved the quality of the program. We would like to thank our supervisors at Wheretrip, Sando van der Helm and Wikaas Dihalu for believing in us and giving us this opportunity. We would also like to mention Rohan Sobha and Daryll Lobman, interns at Wheretrip who gave ample of their time to bring us up to speed with the state of the project. Thanks also to TU Delft and to our supervisor, dr.ir. Otto Visser. R. Bergström M. Simidžioski G Spek Delft, February 2018 iii CONTENTS 1 Introduction 1 1.1 The Company...........................................1 1.2 Problem Description.......................................1 1.2.1 Integrated Booking.....................................1 1.2.2 Personalization......................................1 1.3 Overview.............................................1 2 Initial Requirements 3 2.1 Features..............................................3 2.2 Integrated Booking........................................3 3 Research 5 3.1 Initial Features..........................................5 3.2 The State of the Codebase.....................................5 3.2.1 State of the Back End....................................5 3.2.2 State of the Front End...................................6 3.3 PCI-DSS Compliance.......................................6 3.3.1 When do you need to be Compliant?............................6 3.3.2 How do you become PCI Compliant?...........................6 3.3.3 PCI compliance and Wheretrip..............................7 3.4 Features..............................................7 3.4.1 Relevance.........................................7 3.4.2 APIs............................................8 3.5 Areas of Focus...........................................9 3.5.1 Features..........................................9 3.5.2 Front End.........................................9 3.5.3 Back End..........................................9 3.5.4 Hosting..........................................9 4 Plan of Approach 11 4.1 Requirements........................................... 11 4.1.1 Must Have......................................... 11 4.1.2 Should Have........................................ 12 4.1.3 Could Have........................................ 12 4.2 Time Plan............................................. 12 5 Design 13 5.1 Conceptual design........................................ 13 5.1.1 Front End......................................... 14 5.2 Back End............................................. 15 5.2.1 Controller......................................... 16 5.2.2 Repository......................................... 16 5.2.3 Entity........................................... 16 5.3 Choice of technologies...................................... 16 5.4 Front End............................................. 17 5.5 Back End............................................. 18 v vi CONTENTS 6 Implementation 19 6.1 Front End............................................. 19 6.1.1 Actions........................................... 19 6.1.2 Repositories........................................ 20 6.1.3 Reducers.......................................... 21 6.1.4 Testing........................................... 21 6.2 Back End............................................. 22 6.2.1 Controllers......................................... 23 6.2.2 Repositories........................................ 24 6.2.3 Entities........................................... 24 6.2.4 Testing........................................... 25 7 Software Improvement Group 29 7.1 Feedback............................................. 29 7.1.1 Unit Size.......................................... 29 7.1.2 Unit Interfacing...................................... 31 8 Evaluation 33 8.1 Deliverables............................................ 33 8.1.1 Must Haves........................................ 33 8.1.2 Should Haves....................................... 33 8.1.3 Could Haves........................................ 34 9 Discussion & Conclusion 35 9.1 Timeline............................................. 35 9.1.1 Weeks 1-3......................................... 35 9.1.2 Weeks 4.......................................... 35 9.1.3 Weeks 5-6......................................... 36 9.1.4 Weeks 7-8......................................... 36 9.1.5 Weeks 9-10......................................... 36 9.2 Recommendations........................................ 36 9.2.1 Front End......................................... 36 9.2.2 Back End.......................................... 37 9.2.3 Hosting.......................................... 37 9.2.4 Process........................................... 37 9.3 Conclusion............................................ 37 A Requirements 39 A.1 Personalization.......................................... 39 A.2 Technical............................................. 40 B APIs 43 B.1 Accommodation Types...................................... 43 B.2 Date Flexibility.......................................... 45 B.3 Travel Types............................................ 46 B.4 Weather.............................................. 48 B.5 Travel Information........................................ 49 B.6 Images.............................................. 50 C Choice of Technologies 53 C.1 Frontend Framework....................................... 53 C.1.1 Requirements....................................... 53 C.1.2 Options.......................................... 53 C.1.3 Conclusion......................................... 53 CONTENTS vii C.2 Testing Frameworks........................................ 54 C.2.1 Unit Testing........................................ 54 C.2.2 Integration Testing Front End............................... 55 C.2.3 End-to-End Browser Testing................................ 55 C.2.4 Integration Testing Back end................................ 55 C.2.5 Conclusion......................................... 56 C.3 Database............................................. 56 C.3.1 PostgreSQL......................................... 56 C.3.2 MongoDB......................................... 56 C.3.3 Conclusion......................................... 56 C.4 Hosting.............................................. 56 Bibliography 59 1 INTRODUCTION 1.1. THE COMPANY Wheretrip, describing themselves as, "A Dutch based start-up for travelers who like to explore new places, offering countless destinations within your budget. Being an official YES!Delft student start-up we have created our platform with the help of the best in-house experts available. With our diverse team of experienced travelers we have carefully selected the best destinations for every type of trip: Whether you are a party animal, surfer or both, we have got you covered! By combining our wanderlust with our smart algorithms, we offer you trips which truly fit your theme and budget" [1]. The company wanted to improve their (unpublished) website, and having had good experiences with BEP earlier, they decided to reach out to the Bachelor Program again. They wanted to propose two major improve- ments in how things are done, namely: implementing an integrated booking system and personalizing the current search engine. A more detailed description of these two components can be found in the following section. 1.2. PROBLEM DESCRIPTION 1.2.1. INTEGRATED BOOKING In order to make revenue out of trips made through Wheretrip, the company thought of monetization op- tions. One of the main ideas is asking a commission on the total price of the trip. To be able to charge this commission it is required that an integrated booking system is implemented within the platform itself. In the current situation the customer is directed off the platform and is responsible to book the trip themselves. This is not ideal since there is no confirmation whether the customer actually booked a trip through Wheretrip. This booking system would streamline this experience for customers on the platform, since they would not have to pay at both the transport provider as well as the accommodation provider. 1.2.2. PERSONALIZATION Wheretrip wants to offer their customers the best possible experience, and their target clients are mainly students and other travelers with small budgets. Thus, they created a system that revolves around the budget of their customers. Having realized, however, that money is not the only parameter relevant to people, as there are other that should

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    71 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us