Difference between revisions of "The Line of Least Resistance"

From ESE205 Wiki
Jump to: navigation, search
Line 1: Line 1:
 
== Project Overview ==
 
== Project Overview ==
On a warm Saturday afternoon, Andrew found himself still waiting 30 minutes after his scheduled trip up the iconic St. Louis arch. Reflecting on the experience weeks later with fellow Systems Science and Engineering student Devon, they hypothesized there had to be a more efficient way to run the system by fixing how they manage the masses with their queues.  
+
Research has shown that many of the typical methods for queueing customers are incredibly inefficient [https://www.washingtonpost.com/news/wonk/wp/2015/09/09/researchers-have-discovered-a-better-way-to-wait-in-line-and-youre-going-to-hate-it]. Many attractions choose to utilize time slots rather than the proven-inefficient first-come, first-serve process, but this process can still be less than ideal when delays are introduced. We aim to create an "consulting" app that allows businesses, particularly tourist attractions, to input various data (e.g. weather conditions, average number of customers, minimum time between slots, minimum/maximum number of staff, time needed for each person to go through security, etc). The app will output recommendations based on the inputs that provide businesses with suggested set-ups for the day (e.g. how far to space time slots, how many staff members to have, estimated time until boarding). We will base our app on a simplified version of the St. Louis Arch, and then expand it to be applicable to similar systems. The goal is to minimize delay time.
 
 
We aim to model the current system at the Arch, and then work on designing a system that both accurately models customer behavior and eliminates delay time. Once this has been done, we will develop an application that Arch officials, as well as officials at other tourist attractions, can use to provide suggestions on setting up their queues on a given day in order to minimize delay time while also maximizing profits.
 
  
 
== Team Members ==
 
== Team Members ==

Revision as of 17:23, 25 September 2016

Project Overview

Research has shown that many of the typical methods for queueing customers are incredibly inefficient [1]. Many attractions choose to utilize time slots rather than the proven-inefficient first-come, first-serve process, but this process can still be less than ideal when delays are introduced. We aim to create an "consulting" app that allows businesses, particularly tourist attractions, to input various data (e.g. weather conditions, average number of customers, minimum time between slots, minimum/maximum number of staff, time needed for each person to go through security, etc). The app will output recommendations based on the inputs that provide businesses with suggested set-ups for the day (e.g. how far to space time slots, how many staff members to have, estimated time until boarding). We will base our app on a simplified version of the St. Louis Arch, and then expand it to be applicable to similar systems. The goal is to minimize delay time.

Team Members

  • Devon Essick
  • Andrew Sweren
  • Kjartan Brownell (TA)

Objectives

Note: Each objective depends on the success of the previous one and proximity to the demo.

  • Create a "consulting" application that accurately suggests how to most efficiently (in terms of minimal delay time) set up queues on a given day at a tourist attraction.
  • Expand the application in order to be useful to other companies that aim to minimize delay time (not just tourist attractions).
  • Expand the application to be able to make suggestions based on real time data (e. g. delay caused by security lines being understaffed).
  • Expand application to be able to solve problems other than minimizing delay time (e. g. minimizing wait time).
  • Expand the application to take into account different methods of payment when determining how to maximize profits.

Challenges

  • Making sure the simulations are realistic for an array of systems by taking into account myriad variables (e.g. understanding the challenges that come with a large system that may not be present with a smaller system, and vice versa)
  • Learning simulation software
  • Learning how to code an app

Budget

  • Monitor and peripherals for demo (available from Urbauer 015) - $0
  • Coding software (provided by school) - $0

Total: $0

Gantt Chart

EssickGantt.png

Design and Solutions

Results