2011 Computer Science Integrative Exercise



Hi, we’re Schedaroo, otherwise known as Sched-doodle, otherwise known as “Scheduling Comps.” We’re here to talk to you about scheduling problems at Carleton. Before we go on, let us introduce ourselves:

As we said, we are going to be talking about scheduling problems at Carleton, so it’s worthwhile to define what we mean by a “scheduling problem.”

So, What is Scheduling?

Our computer science definition of scheduling is actually pretty close to the more colloquial definition you already know.

As in the colloquial definition, you have a set of participants

Who are somehow assigned (or scheduled, to use the word in our definition), to a set of resources according to some set of constraints.

A constraint can be as simple as each participant needing to be assigned to exactly one resource, with no other restrictions on legal matchings. Or, we can also do things like require 5 participants to be matched with every resource. Or, we can require that participants be matched to resources in some hierarchical order. The important part is that our constraints tell us what we require in order to solve the problem at hand. Then, we find an algorithm, which is a systematic method for solving a problem, to find a matching that satisfies those constraints.

Examples of Scheduling Problems Relevant to Carleton

The music department at Carleton offers music lessons in various instruments to the Carleton student body. Every term, the students who take these lessons need to be assigned to instructors and rooms in which to take lessons. Student lessons are either 1 hour or 1/2 hour and rooms are in the music hall or the concert hall.

But here's where it gets complicated. Some rooms have pianos and some don't. Certain lessons need to be in rooms with pianos, while others are fine without. Plus, instructors need to have a break for lunch at some point, and some instructors don't like to have two lessons in a row because they get tired.

Here is another example:

You are David Ames, career center employee. Every so often, alumni come to visit Carleton to help out students with job opportunities. You want to figure out how to schedule Carleton students to those alums for half hour meetings, which are assigned on first-come first served basis.

You can see how this satisfies our definition of schedule. The participants we are assigning are Carleton students, and the resources are meetings with alums at specified times. The constraints are that each user is assigned exactly one meeting time and the first to respond gets his or her first choice. The second to respond gets his or her first choice over the remaining resources, etc.

In fact, these scenarios are pretty much exactly what we started with when we started our project.

When we walked into our first comps meeting this fall, there were 5 emails on the table, each from a different Carleton department or organization. One was from Mr. David Ames himself.

Our Goals

Although these emails came from different departments on campus with wildly different expectations for what we would do for them, some common themes emerged:

First, we needed something that was easy for a beginner to use. None of these emails came from the computer science department so we wanted to create a tool that the technically inexperienced could use.

Second, we needed something accessible. People, specifically Carleton students, weren’t going to want to use our scheduling tool if it was not simple to access.

Finally, we needed functionality. Our utility needed to actually solve problems people had and do it in a way that was simpler and better than the methods they were currently using.

For example, at the time they emailed us, the Career Center was using a public Google Docs Spreadsheet to make their alumni schedules. This was not perfectly suited to their needs; it didn’t have email notification, or any sort of security to protect users from losing their time slots to someone who simply logged in and edited the document.

Our Approach

These three overarching goals pointed to one obvious approach to the scheduling dilemmas we faced, namely make a website.

Websites are ubiquitous enough that if we designed ours well, even beginning users would be able to interact with it in a fruitful way, thus meeting our usability need.

Additionally, websites don’t require users to install software, which makes its use as simple as typing in a web address. For example, a user might want to make or respond to a schedule while on a lab computer. Lab computers are reset to their initial state every time a user logs off. Thus, if on the lab computers, users would have to download and install our software every time they would want to use it. This would be a hassle.

Since Internet access is so freely available at Carleton, and our site is focused to the Carleton community, we met our accessibility requirement.

Finally, we knew we could meet our functionality requirement because of the amazing things you can do with websites and the Internet in general.

Plus, everyone loves websites.

Sched-a-roo is Born!

Thus, we created Sched-a-roo, a Carleton only scheduling website. Carleton students validate their accounts by entering their Carleton usernames. They are then sent a randomly generated via email. Students can then log into the site, change their password, and then schedule events on campus.