cs445 - Spring 2012

Project


1. Introduction

The purpose of the project is to give you the opportunity to practice the concepts discussed in this class. The requirements are purposely somewhat vague such that you can interact with the client (that's your instructor) to figure out the detailed requirements.

Before we get into the functionality detail, I want to remind you that detail about the programming language, the platform on which the project will be tested, unit-testing, and how to submit your work is available in the syllabus.

Sections 2 through 4 in this document cover acceptance criteria for the project, Q&A, and a description of how you can earn extra credit for the project.


2. Acceptance Criteria

The basic implementation of the project assumes the application runs locally, on a single computer shared between all employees. This is, of course, unrealistic, however it will allow you to get the basic functionality done without having to worry about access control, or how to connect to a remote computer from your local client running the application, etc. For any additional work you do, you can get extra credit, as described below.

The GUI for your application will be written in Swing if you use Java for your project. If you use a different programming language, then find the equivalent GUI framework and use it.


3. Questions and Answers

Some answers to questions asked by students in relation to this project.


4. Extra Credit

The main purpose of this project is to practice object-oriented analysis, design and programming, not to teach you web development frameworks or relational databases. As such, you do not have to develop a web interface for this project, nor do you have to interface with a real relational database.

However, you can get extra credit for doing development work that's not required by the project, as follows:

  • Create a web interface: 20%
  • Interface with a relational database -- PostgreSQL, SQLite, MySQL, no other database will be accepted -- and create a true client-server application: 20%

The web interface will be tested using Firefox 10+ or Chrome.


5. Project Description

I am the owner of a website where I get a fair amount of traffic on a daily basis. One way I generate revenue from the website is to sell ad-banner impressions on my website's pages.

I have multiple sales people selling the inventory. Since they use spreadsheets to keep track of what they're selling and what they think is available to sell, we find ourselves very often in a situation where we sell too much and then cannot deliver the impressions sold. Other times we have inventory that goes wasted because nobody knew it was available to sell. All these problems are mostly due to the fact that keeping spreadsheets in sync is too difficult and error prone.

The time has come for me to commission the creation of a web-based system that helps me, my sales people, my ad operation employee and my accounting employee manage the web site inventory in a centralized fashion.

My website has the home page, and then various sections and sub-sections. For example "News", "Weather", "Entertainment" are sections, whereby "News Local", "News National", and "News World" are subsections of the "News" section. Within each section / sub-section there are individual topic pages, for example "Massive Snowfall in Europe" and "Early Spring in the Midwest" under "Weather"

Each page on the website belongs to a specific section / sub-section. Pages can be tagged with zero or more ad tags, such that they will display ad banners for each of those tags. Tagging each page with its own tags is very expensive and makes ad operations very complicated. Most websites will use the same ad tag(s) for groups of pages, based on how advertisers (aka clients) buy display inventory. For example, all pages under "News" may be tagged with the same ad tag(s) regardless of the subsection; on the other hand I may want to tag the main "News" page with one set of tags, and the "News National", and "News World" subsections with their own tags.

Each combination of pages and a certain position of an ad is called a placement. Assuming each page has two ads, then in the example above -- where we group all news pages together -- we would have two have placements which we can name, for example, News-728x90-top and News-160x600-right. The name of each placement is something that my ad operations employee determines in the beginning and then doesn't change in time. It is a good idea to give placements meaningful names, though there is no specific naming convention.

An advertiser such as "ACME Computer Security" may want to buy 1.5 million impressions of the wide skyscraper (a 160x600 unit) in the News section, to be displayed in the month of March. The point of this tool is to tell the sales person whether 1.5M impressions are available for that placement, between 3/1 and 3/31, such that she can book the order.

In another example, an advertiser such as "Buy Best" could buy 5 millions impressions of the home page header leaderboard (728x90 unit) and 3 million impressions of the page leaderboard in News, to be displayed between 3/15 and 4/30. The two parts of this order are priced differently: the home page inventory may be sold at $6 CPM (Cost Per Mille, that is $5 for each one thousand impressions), whereas the News my be priced at $2.5 CPM. For this example the total order will be worth 5000*6+3000*2.5 = $37,500.

On a regular basis my employee in charge with Ad Operations will need to update the system with the projected number of page views for each placement on the website. She will select a placement and a date (today or in the future) and then she will enter the projected page views number which is a positive integer.

A page view is generated every time somebody loads a page from my website in their browser. Each page view will generate zero or more impressions, depending on how many ad banners are placed on the page: for example, if a page has two ad banners, then a page view will generate two impressions, one for each of the ad banners. All pages within a placement have the same layout, e.g. they all have a leaderboard at the top of the page and a wide skyscraper on the right hand side of the page. Different placements may have different layouts.

Sales people should be able to view projected and available inventory for any combination of placements and a certain date range, book a portion of or all available inventory, modify or cancel a booking. The order will include the name of the client, the name of the sales person, and the dollar amount charged for that inventory. The system should calculate the average CPM for the order.

Sales people cannot see each other's orders. They may modify a booking, but not after it's been turned into a committed order. The VP of Sales can see everything that's been sold, by whom, and for how much money. The VP of Sales can also cancel anyone's booking, in which case the specific sales person will notified. The VP of Sales can also cancel a committed order.

Accounting should be able to turn a booking into a committed order upon receipt of payment from the client or for clients that have a good credit rating. When a booking is approved the sales person that created the booking and the VP of Sales must be notified.


Last update: Apr 9, 2012 Virgil Bistriceanu cs445 Computer Science

$Id: project.html,v 1.2 2012/04/09 23:16:05 virgil Exp $