Dynamic Pricing

Airlines have long used a dynamic pricing scheme to maximize their profit. Seats on more popular flights increase in price, while seats on less popular flights become cheaper. On the other hand, concerts, athletic events and stage productions fall victim to the practice of "scalping" where an outside agent buys a large number of tickets, artifically increasing the demand, then sells the tickets at a large profit. Dynamic pricing is a strategy to remove the profit from scalping, and allow the customers to get the best price possible.

With dynamic pricing, the cost of a seat increases as demand rises, and decreases as demand falls. Thus, if a concert was very popular, prices would increase, and if nobody wanted to see it, the price would fall. Price changes will be implemented on a per minute basis, but the price change can be weighted over a longer interval.

Dynamic pricing eliminates scalping when the initial price offering is very high. Assuming the price is sufficienly high to discourage anyone from buying, scalpers will be unable to make money from buying those tickets. Over time, the price will fall until it reaches the point consumers are willing to make purchases. Since this is the maximum amount consumers are willing to pay, scalpers are again unable to make a profit.

Your project is to implement a dynamic pricing system for performances. Your system must support

venues - places where events are held
events - performances for which tickets can be bought
seats - items which can be bought, and which are dynamically priced

Additionally, some seats may only be available to certain constumers (e.g., student section). You must also support discounts and other price differentials. Some sections within a venue may have different prices.

The customer accesses your system via a web interface. The interface must automatically update itself to show the current prices of multiple tickets. You must provide search capability to allow the customer to find desired tickets.

The facilities operator must also have access to your system. This will allow the creation of venues, events and various pricing structures.At a minimum, your system must support the Ferrel Center as a venue, and all of BU men's and women's basketball games for the 2008-9 season.

Additionally, the project must support access via a program running on your computer. The program will submit orders following a poison distribution, rapidly enough to cause changes to the exsiting prices. This will serve as a test for the dynamic pricing algorithm. The program will be written by the TA, and must not be modified by the groups.

Project Schedule

September 2 - Team formation, Oracle installation
September 9 - Q & A with Drew Pittman
September 16 - Initial database design, ER diagram
September 23 - Prototype
October 14 - Final database design
October 28 - Simulation testing
November 11 - Presentation, project completion
November 18 - Documentation deadline
Decemebr 2 - Technical review

The grading of the project is subjective, but it is based on the following criteria:

prototype - 10%
database design - 20% (including normalization analysis)
user interface - 10%
presentation - 10% (individualized based upon the presentation; every member of the group must make part of the presentation)
performance - 40% (20% for dynamic pricing implementation and 20% for venue/event/seating, etc.)
documentation - 10% (excluding database design)

Exceptional performance can generate greater than full credit on individual components. It is wise to go beyond these specifications because systems as large and complex as these will have bugs, which will lower your grade.