Williamsburg Players

Contact: R Noonan, noonan -at- cs.wm.edu, 221-3465

In 1957 a group of Colonial Williamsburg employees decided that their play-reading group would begin offering live theatrical performances. The resulting community theater, now named The Williamsburg Players, recently celebrated its 50th season of bringing quality shows to the greater Williamsburg area.

One of the problems of the organziation is that there is no readily accessible database of volunteers and their activities. Much of this information is scattered across multiple databases: audition cards (non-electronic), the volunteer coordinator's email list, the house manager's email list, the box office manager's email list, etc. Nor is any systematic record kept of who did what (other than the director) on any given show.

The Players have asked for our help in enhancing their web site into one which will serve as a corporate resource. A typical question is: who can do light design that has not already done so in the current season.

Some minimal aspects of this Volunteer Database include:

• Must replace the current box of audition cards, including pictures.
• Must be able to list people with certain skills, together with their phone numbers and email addresses. Example skills include: director, light designer, singer, scenic painter.
• Must be able to produce a contact sheet (with or without addresses) for a given show.
• For any given person,must be able to list all of their credits, both as cast and crew.
• For a given show, anyone whose name might appear in the playbill should be able to be entered into the database and linked to their role in their role in the show. For example, your instructor was co-producer of the show Sleuth. He was also Technical Director and had to fill in occasionally as a stage hand (grip) and as the light/sound operator.
• Access must be restricted to those who have an account. Different levels of access control should be possible.

The problem (like most real world problems) is somewhat ill defined. Part of your task is to identify the real problem to be solved.

Design Proposals

Each team should should show all of the following items (also deliver as a zip or tar file):

• Overview of the proposed system.
• Your database design, which should be in normal form.
• For each database table, you should give: the name of the table, its purpose, the name of each field, its type, its size (if text), and a comment or example.
• Forms should be an actual HTML web form (but without a real script) and should be neat and presentable.

Deliverables

Each team should deliver all of the following items as a zip or tar file:

• A copy of the final proposal, with commentary by the team as to:
  • Which parts are the propoposed system are complete and which are incomplete and their status.
  • What the team would do differently and why.
• For each database table, you should give: the name of the table, its purpose, the name of each field, its type, its size (if text), and a comment or example.
• A directory (or directories) of PHP files which comprise the delivered application.
• A directory (or directories) of PHP files which comprise the test cases and test data.
• All of the code is to be documented using PHPDoc (or an analogous tool).
• A description of the system from the maintainer's viewpoint.