Beds Hackathon 2017 - Scenario 2

Transcript

1. Scenario #2 - Planning On-board excursion booking system
2. 2 Planning • Estimate the scenario • Decide if the scenario is right for the team • Identify what you are being asked to do • Tasks - split the problem into small manageable tasks • Options - what are the technical options available to you? • Re-read the scenario! Remember this…?
3. 3 Planning • Estimate the scenario • Decide if the scenario is right for the team • Identify what you are being asked to do • Tasks - split the problem into small manageable tasks • Options - what are the technical options available to you? • Re-read the scenario! Remember this…?
4. 4 One of the main reasons for customers choosing a cruise is the potential to see many different countries, cities & places of interest in a short period of time. At TUI we are very keen to ensure that our customers have great time, relax & can see as much of the countries & their culture we visit as possible. One of the best ways of doing this is to offer excursions (trips away from the ship at a port). Excursions are tricky to manage as there is a limitation on the number of coaches & seats on them to transport the customers while off-ship. Scenario #2 - On-board excursion booking system
5. 5 • A booking system – for excursions – to be used on- board ship • Coaches are used to transport customers – the number of these is limited • Therefore, the number of available seats for each excursion – at each port – is also limited Identify
6. 6 Level #1
7. 7 • You have access to a file which has the available excursions for a cruise & that are available from each of the ports- of-call that the cruise stops at. • Design & build an on-board excursion booking system using the given data. At this stage, all a customer can do is book several seats on an excursion - you should require their name, number of seats required & their cabin number. The customer/cabin number combination must be unique - a customer cannot book twice. • Once all seats are sold for an excursion - no more bookings can be taken. • Assume that no seats are handed back. Scenario
8. 8 • You have data: available excursions at each port-of-call on a specific cruise • Design and build a booking system for these excursions • You need to store the customers name, cabin number and number of seats required • Business rules: • A customer can book several seats • The name/cabin combination must be unique • Once all seats for a particular excursion have sold out – that excursion is no longer available • Bookings are not deleted once taken Identify
9. 9 • How are you going to handle the data? • A database? Relational, NoSQL, other? • Flat file? • In memory? • How is the data accessed? • Is it accessed by the customer, or do the crew take the booking? • What kind of interface does it have? Web-based, command line, SQL form…? • Where is the system located on the ship? • Is it a single central computer, via touchscreens, in-room computer/TV, kiosk? • Does it matter? • Is it an API that can be called by numerous devices? Options
10. 10 • Figure out the data structure • Create a database? • Load the data • Decide what else you need to store – the structure of that data - and how you are going to store it • Write something that gives you access to the data • Write something that allows you to make a new booking Tasks
11. 11 Level #2
12. 12 • Your booking system has proven highly effective & very popular. But, some customers would like to return some seats previously booked. Implement booking cancellation within the system. • You have also been asked to add a 'wait list' for seats on each excursion. So that when the coach is full a customer can register interest in obtaining one or more seats. • For this purpose - assume there is only one coach with 32 seats per excursion & that the customer initially always accepts & purchases the seats they have requested even though they might cancel their booking later. Scenario
13. 13 • Implement the following business logic - choose suitable data structure(s) to support your algorithm: • If the incoming request is for less than the number of available seats - allocate seats to the requesting customer. This must be done in the order that the requests come in. Assume requests arrive one at a time. • If fewer seats are available than the number being requested - put the customer's request 'on hold' until sufficient seats become available. Do the same for all subsequent requests irrespective of whether the request could have been fulfilled (for example, when the next request is for fewer seats than are currently available). When seats are handed back (booking cancellation) and sufficient have become available - allocate the seats to the first requesting customer in the order they were originally requested. Scenario
14. 14 • Bookings are cancellable • A wait list is required • Business rules: • Only 1 coach with 32 seats per excursion • Once requested by a customer – wait list seats are always taken by the customer • Bookings are taken on a first-come-first-served basis until the next request for seats exceeds the number of seats left. At that point all bookings are placed on-hold until enough seats become available or the excursion runs • The on-hold list is processed in order Identify
15. 15 • Booking request data structure – queue, list/array, hash/map/dictionary? • Wait list – ordered list, queue? • On-hold list – list, queue, map? • 1 coach and 32 seats per excursion. This ’feels’ like it might change. What if it does – what would need to change to accommodate that? Options
16. 16 • Implement booking cancellation • Figure out the data structure for the wait and on-hold lists • Implement the wait list • Implement the on-hold list • Consider 1 coach/32 seats restriction and how the system needs to adapt if this changes Tasks
17. 17 Level #3
18. 18 • You have had complaints from some customers who are unable to go on some excursions due to lack of seats, but then going on other excursions where there have been empty seats! • Optimise your 'wait list' by maximising the use of available seats always. • Change your data structures & queuing mechanism to support your algorithm. Scenario
19. 19 • You have also been informed more coaches can be made available. The cruise team have given the logic for this as follows... • If the 'wait list' requested seats total is greater than 50% of the total number available on a coach (32 in this case, so more than 16) - make another coach available, increment the total number of seats as appropriate & and proceed as normal. • In the case of booking cancellations - if the number of required seats goes below the need for the additional coach or coaches. Remove the appropriate number of coaches - except one. All excursions have a minimum of one coach. • There is no limit to the number of coaches that can be added in this way. But, clearly there is a limit to the total number of customers on the cruise. As the cruise director Jean-Luc Pickard says - "If all customers on cruise want to go on a particular excursion - make it so!" Scenario
20. 20 • Optimise the wait list • More coaches can be made available – depending on uptake • Open question – what happens if you have 2 coaches – there are booking cancellations, and the requested seat total drops below 50% of coach availability? How should you handle this? • Business rules: • All excursions have at least 1 coach • Add an additional coach if the total number of requested seats is > 50% available on a coach (32) • Only use as many coaches as you need – when you need them! Identify
21. 21 • How does the wait list need to change to optimise it? • Can you keep the same list, array, queue? Should you? • How does the algorithm change? • Additional coaches • Hard-coded? Soft-coded? Configurable? Parameterised? • What if the rules change again? • Maybe this feels like a strategy? Options
22. 22 • Update the algorithm and/or data structure of the wait list to reflect the new requirements • Remove the on-hold list – it is no longer required • Implement the additional coach requirement Tasks
23. 23 Questions?
24. 24 Graham Lewis IT graham.lewis@tui.co.uk Thanks for listening