This is the third of three projects based on the GusAir case study, which is described in a the background document. For this project, your goal flows from the following paragraph of that document:
Finally, if our study of dynamic pricing is encouraging, the founders of GusAir are going to need to explain it to a lot of other people including bank loan officers, potential investors, and journalists. Therefore, we have been asked to provide some illustrative examples of how the price might vary over time as customers make their purchasing decisions. We have also been asked to provide a simple user interface that can be used to step through particular what-if scenarios.
We discussed three general forms the GUI might take. You should feel free to develop some variant of any of these. Hopefully some students will choose one and some another, and hopefully even those picking the same general form will do different variants. Moreover, if you have in the meantime thought of a fourth option, substantially different from the three we discussed, that would also be welcome.
One approach relied on the user to play the role of the consumers. The GUI would present the time remaining until flight and, for each of the two pricing models, the number of seats remaining, the current offering price, and the total revenue realized thus far. The user chooses whether to buy a ticket under both pricing models, just dynamic pricing, just fixed pricing, or neither. Illogical options can be grayed out. The user can also move back a time step, restart the simulation, or skip forward to a later time (without any purchases in the meantime).
Two other approaches relied on pseudo-random numbers to simulate the customers. In one, the user would control the passage of simulated time. The display could include information such as the time remaining, the number of seats remaining, the current asking prices under the dynamic and fixed price approaches, the simulated customer's threshold price (drawn from a Weibull distribution), and the total revenue to date using each of the approaches.
In the other approach that used pseudo-random numbers to simulate the customers, the user would only control parameters of the simulation such as the plane capacity, the arrival rate of potential customers, and the shape and scale of the Weibull distribution of price thresholds. When these parameters are set in accordance with the user's wishes, they would click a start button and the entire simulation run would proceed, producing a line graph displaying price (under each pricing model) against time. The total revenue realized under each pricing model would also be displayed. To show how this corresponds to the price graph, the points at which purchases happened could be marked. To do a second run with the same parameters would just require clicking the start button again; the resulting graph and revenues would generally be different, because of the pseudo-random generation of the simulated customers.
Your project report will be graded based on the following expectations. Ten percent of your grade will come from each of these ten areas.
You are to explain what your program does in language that would be clear to one of our clients at GusAir. In addition to explaining the particular controls and displays that your program offers, you should provide some higher-level explanation of the value the program provides. How would it allow stake-holders to appreciate the nature of dynamic pricing, including its impact on both the customer experience and the airline's revenue?
Each widget in your GUI should be of an appropriate type for the role it plays. (For example, an output value should show up in a label, rather than in a text entry field that seems to invite the user to edit it. Another example of a mistake would be checkboxes with a label warning users to check only one; radio buttons would be more appropriate for mutually exclusive options.)
The widgets in your GUI should be grouped into logically related categories. Where a number of adjacent widgets of the same kind are used for closely-related information, they should have consistent sizes and positioning.
When there is a logical order to widgets (such as chronological order or cause and effect), that order should be manifest in the top-to-bottom or left-to-right spatial order of your GUI's layout.
Your GUI should not have any distracting gaps (such as between a label and what it is labeling), nor any widgets with sizes grossly out of proportion to their contents. To the extent reasonably possible, this should remain true even if the overall window is resized.
Each widget that provides for user interaction should trigger appropriate behavior from the program when activated.
Your procedures should not only be free of bugs, but also as simple and clear as reasonably can be achieved.
Your project report should use devices such as section headings to provide a clear organizational structure.
The writing mechanics should not embarrass Gustavus in front of our business partners. Examples of mechanical issues are spelling, punctuation, grammar, and paragraph breaks.
You are to demonstrate your program in class on December 7th, accompanying your demonstration with an oral explanation in language that would be clear to one of our clients at GusAir. As in your written report, you should attempt to go beyond the mechanics of your user interface by providing some higher-level explanation of the value the program provides.