Managing Partial Student Schedules

The Scheduling Optimizer develops partial schedules for students who can not be fully scheduled in a simulation. The choice of which course requests are dropped significantly affects the job of manually completing the partial schedules. The Scheduling Optimizer includes two mechanisms which determine which course requests are dropped:

• Student ordering: The Scheduling Optimizer sorts students from highest to lowest grade prior to scheduling. This automatically gives students in the higher grades first access to available seats; course requests will be dropped from students in lower grades if sections fill up.
• Course request priority: The Scheduling Optimizer uses the sequence order of course request entries for each individual student as the course request priority, dropping course requests from the end of a student's list in the event of a conflict. A student's course request list sequence can be seen in the Scheduling atom (Requests tab) and the Student Course Requests atom (Schedules tab).

The Scheduling Optimizer's student ordering is completely automatic and requires no special setup. This document describes how to use CHANGE Queries to sequence student course request lists according to the desired priority.

Procedure

This procedure sequences student course request lists so that required courses (courses with Request Priority set to R or blank in the Course atom) are placed first, followed by elective courses (Request Priority set to E) followed by other courses (Request Priority set to O). Request Priority overrides can be defined for individual student course requests in the Student Course Requests atom. A Request Priority override value of R or E defined for a course request is used in place of the Request Priority in the Course atom to sequence the course request.

Note: If you would prefer to have blank Request Priorities in the Course atom default to E (elective) instead of R (Required), you can adjust this procedure accordingly; see Notes below.

In the example below, English courses (Course IDs 0001 and 0002) are used to anchor teams; these courses are to be assigned a higher priority than other required course requests for each student.

Use the Course atom/Schedule Pro page to set Request Priority to the appropriate value for all courses.

 

Set course request sequence numbers to 201, 202, 203, etc. for each student based on the current sequence order of course requests by running the following CHANGE Query:

<CHANGE> ASTU ASSS SQ = {$CNT + 200}

Run the following two Queries in order to resequence all student course request lists based on course Request Priority.

<CHANGE> ASTU ASSS ACRS SQ = {SQ - 100} IF 2,ReqPrior = "R" OR (2,ReqPrior = " " AND (3,ReqPrior = "R" OR 3,ReqPrior = " "))

 

<CHANGE> ASTU ASSS ACRS SQ = {SQ - 50} IF 2,ReqPrior = "E" OR (2,ReqPrior = " " AND 3,ReqPrior = "E")

If you are using teacher groups to team students, it is recommended that you place the "anchor" courses (courses used to link to connect a set of teamed courses with "same teacher group" rules) first in student course request lists to avoid producing partial schedules with cross-teamed courses. If you are not teaming students, you may have a different reason to prioritize some list of courses ahead of other required courses (perhaps Football Team or Marching Band courses).

For the purposes of our example, assume we are teaming students and the teaming anchors are courses 0001-English 7 and 0002-English 8. The following CHANGE Query resequences these courses ahead of other required courses in student request lists. Replace the Course IDs shown in the example with the Course IDs of your own "extra high" priority courses.

<CHANGE> ASTU ASSS ACRS SQ = {SQ - 100} IF CrsReq IN ["0001", "0002"]

After running the above Queries, use the Scheduling or Student Course Requests atom to confirm that courses have been correctly sequence according to the assigned priorities.

The following screen shows a student's original course request list.

After resequencing, the same student's course request list appears as follows.

Notes

• You can rerun the procedure described in this document from the beginning at any time to resequence student course request lists based on updated course requests and/or course Request Priority definitions.
• The CHANGE Queries used in this document all take some time to run. Once you start one of these Queries, do not interrupt it.
• The Query atom does not show Sequence as a selectable field for the ASSS file, but it can be included in a Query by keying in the field name Sequence or, alternatively, its abbreviation SQ.
• While it is convenient to use CHANGE Queries to define course request sequencing for all students at once, it is also possible to manipulate the order of requests for an individual student by dropping, then adding back courses (which will be placed at the end of the student's list) in the Scheduling atom. The Student Course Requests atom allows you to simply replace a requested course ID with a different one, making it easy for you to reorder an individual student's course requests.
• The above procedure treats a blank Request Priority field in the Course atom as R (required). You can choose to default a blank Request Priority field in the Course atom to E (elective) instead by modifying step 3 of the procedure to run the following two CHANGE Queries in place of the ones shown.

<CHANGE> ASTU ASSS ACRS SQ = {SQ - 100} IF 2,ReqPrior = "R" OR (2,ReqPrior = " " AND 3,ReqPrior = "R")

<CHANGE> ASTU ASSS ACRS SQ = {SQ - 50} IF 2,ReqPrior = "E" OR (2,ReqPrior = " " AND (3,ReqPrior = "E" OR 3,ReqPrior = " "))

Back to Top