The generation of a schedule is based on databases of information, and a list of constraints on how to match the information together.
The various constraints are as follows:
· Teachers can’t be double booked for a single time slot. (Must Achieve)
· Rooms can’t be double booked for a single time slot. (Must Achieve)
· Teachers can’t be assigned a class they have no proficiency in. (Must Achieve)
· Courses that require a certain type of room, get that type of room. (Must Achieve)
· Teachers can’t surpass their WTU’s. (Preferred)
· Teacher travel time between classes and their office should be minimized. (Preferred)
· Teacher’s class times should correspond with their preferred times. (Preferred)
· Certain 3XX, 4XX, and 5XX level classes shouldn’t have overlapping times. (Preferred)
If the user selects Schedule > Options, it brings up the Constraints dialog.
Figure 2.3.2.1.
From this window, the user can change the order in which the “generate schedule” function prioritizes the preferred constraints. The Must Achieve constraints are followed no matter what, and order doesn’t make a difference for those.
Must
Achieve Constraint Violations
When the user chooses to generate a schedule and a “Must Achieve” constraint gets in the way, the program will list the course assignment using “Staff” and “TBA” (To Be Assigned). Staff fills the spot of a teacher, and indicates that no suitable teacher can be found for this class. This can be due to a lack of qualified teachers for that course, or teachers are all maxed out with their WTU’s in other classes. TBA fills the spot of a room, and symbolizes that there are no suitable rooms for this teacher and course. The TBA pops up when all the rooms are full at that time, or when a specific type of room is not available (a lab room for a lab class).
In this example, we have 1 teacher (B Ruth), and 2 classes. This example school is only open for a short amount of time. If the administrator took in this data, and generated a schedule, the result would look something like Figure 2.3.2.2.
Figure 2.3.2.2.
This schedule would violate the constraint that a teacher can’t be double booked, so for the second class, the teacher assigned was Staff. It is then the administrator’s job to find a new teacher to fit that class, or widen the times available.
The user then decides not have a second class, but instead, adds a new class, that has a lab. If the user forgot that his school didn’t have a lab classroom, the result would look like Figure 2.3.2.3.
Figure 2.3.2.3.
This schedule would violate the constraint that a lab class has to be in a lab room. The temporary solution is to list the class in the room TBA. The administrator would then have to go back later, and get a room for that class.
In this continuing example, the user finds a lab room for the class, and realizes that he isn’t utilizing Tuesdays and Thursdays. So he adds another course to his schedule. However, our one teacher isn’t qualified to teach that class. Had the teacher set his preferences accordingly, the result would look like Figure 2.3.2.4.
Figure 2.3.2.4.
This schedule would have violated the constraint that a teacher shall not be assigned a course that he/she can’t teach. It is then the administrator’s job to find a new teacher to fit that class.
The admin in our sample example decides to take the drastic method, and instruct the one teacher how to teach that class. Now that the teacher is proficient in the class, he is eligible to instruct the class. The admin is so happy that he has someone to teach the class, that he adds another section of the new course. The admin forgets to take into account that the one teacher has a limited number of WTU’s. The program will detect this and give a result similar to Figure 2.3.2.5.
Figure 2.3.2.5.
This schedule would have violated the constraint of surpassing the teachers WTU’s. The solution to this would be for the admin to find a new teacher to fill the position.
Changing Teacher Preferences
If to get a better schedule, the administrative user may change a teachers preference for that quarter. To do so, open the constraints dialog (Figure 1) as shown above, and click the “Change Teacher Prefs” button. The program will open a dialog box to choose which teacher to adjust. Once the user selects a teacher, a window similar to the Teacher Application will appear (Figure 2.3.2.6). The interface will act the same, however the teachers information will not be editable. Any changes made and saved will only apply to the schedule being made for that quarter. For more information on adjusting the teacher preferences, see section 2.6
Figure
2.3.2.6.
Example
Let’s say there are 3 teachers, and only a few rooms. One of the teachers is strict with his time preferences, only taking times right before labs are available, even though he doesn’t teach a lab class. Thus the other two teachers, who have more open preferences, end up getting the odd other times. The labs and lectures have also became distanced due to the first teacher’s preferences. This creates a schedule like the one below. (Figure 2.3.2.7)
Figure 2.3.2.7.
The admin sees this crazy schedule and wishes to alter the first teacher’s preferences. Using the method above, the admin enters the teacher’s preferences (a separate copy, only valid for this schedule). The admin then changes the preferences to allow the teacher to teach when the other professors are in lab (Figure 2.3.2.8).
Figure 2.3.2.8.
After the updates are made, the admin generates a new schedule, and a much more pleasant schedule comes out (Figure 2.3.2.9). Because the other teachers have their labs closer to their lectures, like they wanted, their fairness value goes up, increasing the schedule’s fairness value as well.
Figure 2.3.2.9.
Prev: Fine Tuning | Next: Fairness Formula | Up: admin schedule tuning | Top: index