Module Preference Exercise (MPE)

Undergraduate Office, School of Computing

(updated on 15 Sep 2016)

Introduction

Module Preference Exercise (MPE)aims to determine the demand by SoC students for SoC and important non-SoC modules offered in the following semester before the execution of CORS. Early knowledge about module demands provides the UG Office precious time to negotiate with various departments and faculties for class sizes; it also provides students a clearer perspective of various module demands in the following semester.

MPE works by requesting students to declare their preference for module selection in the following semester. With this information, the UG Office works with departments and faculties to adjust the class quota for each module offered to meet the demands if possible, and inform students of the expected class quota for each module offered.

MPE also enables UG Office work out the module requirements of graduating students, so as to smoothen their path towards graduation. In some cases, MPE enables UG Office pre-allocation of modules so as to allay anxiety among students during module bidding at CORS.

MPE Operating Principles

The design and implementation of MPE adheres to the following four operating principles:

  1. Honouring CORS Bidding Spirit

There will beno violation of the spirit of CORS bidding. If final demand exceeds final supply during MPE, the bidding exercise will be required (during CORS sessions). If final demand is less than final supply during MPE, module pre-allocation is performed.

  1. Serving Graduation Requirements

Students will be grouped according to the urgency of their graduation. In the situation where the demand for a module exceeds its supply, students choosing the module and meeting the following criteria will be given priority in studying the module:

(a)The module chosen is used to meet the student’s programme essential/elective requirement

and

(b)The student belongs to a group that identifies him as closer to graduation than other students

For practicality, we classify students into three groups:

  1. Group A
  • BZA4and COM4 students in their final semester
  • Graduating within one semester (MC ≥ 136)
  1. Group B
  • BZA4 and COM4 students in their second final semester
  • Graduating within two semesters (MC ≥ 116)
  1. Group C
  • The rest ofBZA3 and COM3 students
  • With (116≤ MC 96)
  1. Group D
  • All other students
  1. Emphasising on Essentials & Electives

MPE attempts to help students in their selection of modules that are used to fulfil their respective programme essential and programme elective requirements. If possible, MPE performs pre-allocationof these modules for the relevant students.

MPE takes into consideration that a module that is identified as elective in one programme can be more urgently needed than in another programme. Specifically,

  1. An elective module, such as CS4247, is considered elective for both students in BComp (CS) and BComp (CM). However, students in BComp (CM) needs CS4247 for graduation more urgently than students in BComp(CS). As such, CS4247 will be considered as high elective for students in BComp (CM) and considered as elective for students in BComp (CS).
  2. A module, such as CS1231, is not listed as essential for students in BComp(EC) following curriculum 2009 and before. However, students must read CS1231 in order to take the essential EC module CS2102. In this case, we identify CS1231 as pre-Essential for students in BComp(EC).

Assumptions about Students’ Current Status

Students are classified into three groups, A, B, C and D, according to the MCs that they may have attained. During MPE, we make the assumption that

Students will pass all modules that they are studying in the current semester.

The implications of this assumption are thus:

  1. Students will be awarded the MCs for the modules taken in this semester.

Example: Student X has accumulated 130MCs before the commencement of the current semester, and he is taking 5 modules of a total of 20 MCs. During MPE, X will be considered to have 150 MCs, and be classified as a Group A student.

  1. Students will be allowed to state their preferences to modules which require modules they are currently studying as pre-requisites to them.

Example: Student X is taking CS2105 this semester, and CS3235 requires CS2105 as a pre-requisite. During MPE, X can choose to study CS3235, since he is considered to have met the pre-requisite for CS3235.

Students taking an SoC degree as their second degree will be treated the same as those taking an SoC degree as their first degree.

For students who are away from NUS during the current semester, special consideration in computing their MCs is required:

  1. Students on exchange programmes: 20 MCs will be added to their MC counts during MPE. Modules taken overseas will be mapped to NUS modules for the purpose of pre-requisite check.
  2. Students on NOC: 40 MCs will be added to their MC counts during MPE.Modules taken overseas will be mapped to NUS modules for the purpose of pre-requisite check.
  3. Students on French DDP expected to return in the following semester: They will not participate in MPE, and their request will be handled offline.

Students on exchange programmes or on NOC are encouraged to contactMs Diana Wong at rly to provide information about the NUS equivalent modulestheyare currently studyingat the partner university.

Operation Detail of MPE

Students will need to declare their module preference once during MPE. Depending on demands for modules, students in Group A may need to re-declare in order to receive better pre-allocation of their modules.

The schedule of MPE is given at:

Round 1: Input from Students

All SoC students (except those who have filed for graduation in this current semester) are requested to declare their module preference in Round 1 of the exercise. Here, quota for each module will be made known. For each module chosen by a student, the computer system will verify that the student’s study so far has met the module pre-requisites.

Every student can indicate up to a maximum of four modules from the list of modules that are available in the following semester. For each module indicated, the student must indicate the part of programme requirements he attempts to fulfil with this module. That is, the student must indicate if the module chosen will be used to satisfy programme or common essential, pre-essential, programmeelectiveand high electiveorUE. These declarations will be verified at the back end by the computer system, through pre-processing by SoC’s FFG system. Specifically, a student can identify an elective module to count towards either elective requirement or others (i.e., Unrestricted electives), but the student cannot identify a UE module to count towards meeting programme elective requirement. Essential modules should generally be highlighted by students as counting towards essential requirement, but since a student might take a replacement module to meet the essential requirement, he is therefore permitted to indicate that the module be used to fulfil other requirement.

Just like CORS, the MPE system will ensure no clash in lecture and examination timetable before allowing students to commit to their choices.

Negotiation with Departments on Module Quotas

For those modules with demands exceeding supplies, the UG Office will submit these requests to the offering departments/faculties for readjusting the module quotas. The eventual quotas given by the offering departments/faculties will be the final quotas used in the remaining process of MPE, and the following CORS exercise.

Processing Group A’s Preferences – Part 1

Modules chosen by Group A students for meeting either essential or elective requirement will be considered for pre-allocation. For each of these modules, the numbers of Group A students choosing the module as essential, pre-essential, high elective and elective are identified (by NA_S, NA_PS, NA_HE and NA_E respectively). Iterative process is performed to match the demands for the modules against the quotas, as follows:

Pre-allocation Process

  1. If the demand (NA_S + NA_PS) falls below the supply (the module quota), module pre-allocation will be made to assign modules to respective students in Group A; otherwise, exit the iterative process.
  2. If the demand (NA_HE) falls below the remaining supply, module pre-allocation will be made to assign modules to respective students; otherwise, exit the iterative process.
  3. If the demand (NA_E) falls below the remaining supply (after steps a and b), module pre-allocation will be made to assign modules to respective students.
  4. Exit the iterative process.

Group A students are informed of:

  1. The list of essential/elective modules which they have successfully been pre-allocated in MPE.
  2. The list of essential/elective modules which they have not successfully been pre-allocated, and the need for them to bid for the modules during CORS exercise.

Processing Group B’s Preferences

Modules chosen by Group B students for meeting either essential or elective requirement will be considered for pre-allocation. For each of these modules, the numbers of Group B students choosing the module as essential, high elective and elective are identified (by NB_S, NB_PS, NB_HE and NB_E respectively). The iterative pre-allocation process as described in Part 1 above will be activated, matching the demands against the remaining supplies.

Group B students will be informed of:

  1. The list of modules which they have successfully been pre-allocated in the entire MPE.
  2. The list of modules which they have not successfully been pre-allocated, and the need for them to bid for the modules during CORS exercise.

Processing Group C’s Preferences

Modules chosen by Group C students for meeting either essential or elective requirement will be considered for pre-allocation. For each of these modules, the numbers of Group C students choosing the module are identified (by NC_S, NC_PS, NC_HE and NC_E respectively). The iterative pre-allocation process as described in Part 1 above will be activated, matching the demands against the remaining supplies.

Group C students will be informed of:

  1. The list of modules which they have successfully been pre-allocated in the entire MPE.
  2. The list of modules which they have not successfully been pre-allocated, and the need for them to bid for the modules during CORS exercise.

Processing Group D’s Preferences

Modules chosen by Group D students for meeting either essential or elective requirement will be considered for pre-allocation. For each of these modules, the numbers of Group C students choosing the module are identified (by NC_S, NC_PS, NC_HE and NC_E respectively). The iterative pre-allocation process as described in Part 1 above will be activated, matching the demands against the remaining supplies.

Group D students will be informed of:

  1. The list of modules which they have successfully been pre-allocated in the entire MPE.
  2. The list of modules which they have not successfully been pre-allocated, and the need for them to bid for the modules during CORS exercise.

Post-MPE Processing

Students who are successful in securing (being pre-allocated of) modules through MPE will find the respective modules being pre-allocated to them in CORS, subject to them satisfying the pre-requisite/preclusion of these modules. Specifically, if a student does not manage to pass a module M in the current semester, and M is a pre-requisite of one of his pre-allocated module M’, then the student will not be pre-allocated with module M’.

One CORS point will be deducted from students’ accounts for each module pre-allocation. During CORS exercise, students are allowed to drop modules that have been pre-allocated to him during MPE. However, the associated CORS points will not be refunded.

Students will not be preallocated module that has class and examination time-table clashes with other preallocated module(s) base on the finalised class and examination time-table.

Conclusion

The design of Module Preference Exercise (MPE) is not to outsmart CORS. Rather, it aims to estimate the quotas required for modules offered in the following semester, so as to allay anxiety among students during CORS. The success of MPE hinges on the active and honest participation of all SoC students. In return, MPE enables pre-allocation of modules to students during CORS.

Acknowledgment

The Undergraduate Office would like to thank the following members of SoC-ITU, Sze Eng Koon, Lim Sing Ing and Philip Lim, for the help in design and implementation of MPE.