Progression measures available for use in rules

Creating progression rules

Creating the Progression Rule Application

This document is written for specialist Progression staff with responsibility for the creation and maintenance of Progression Rules. The following is assumed:

To support students in achieving course completion and graduation, institutions regularly evaluate students' academic progress and institute action where a student is not making the required progress. The Progression Subsystem provides a flexible means to both evaluate student progress and to manage the administrative tasks associated with progression evaluation.

Evaluating progress is done through the creation and application of progression rules, using those means of measuring progress which an institution determines are best suited to its needs.

Determining which measures are to be used is an institution decision, as is the configuration of the Progression subsystem (i.e. determining when the rules are to be applied).

The Progression subsystem currently provides the ability to construct rules using the following measurement tools: Grade Point Average (GPA), Weighted Average Mark (WAM), Proportional Failure, Unit Failure and Research Milestone measures. Combinations of these measures may also be used when constructing progression rules.

In calculating either a GPA or WAM value for a Student Course Attempt, only Student Unit Attempts with a status of COMPLETED, DUPLICATE, DISCONTIN or ENROLLED are included in the calculation. Those unit attempts with a status of ENROLLED are only included in calculations that can use a recommended result.

A Grade Point Average is a calculated average commonly used as a means to evaluate a student's progress in a single course attempt. The Progression subsystem allows the construction of rules that evaluate progress based on a Grade Point Average value alone or in combination with other measures (Unit Failure or Proportional Failure measures).

The 'type' of Grade Point Average calculation that is executed is determined by the rule option selected when constructing a progression rule. Some types of GPA calculation use all student unit attempt grades, others restrict the grades considered to the current progression period. Some GPA calculations allow the substitution of grade point average values where a student unit attempt has no recorded grade. All, except those that specifically nominate the inclusion of Recommended Grades, use only finalised grades in the calculation.

Where the Progression subsystem has been configured to calculate, store and display a student's current GPA, the Course and Progression Period calculations are used.

A Weighted Average Mark is a calculated value that can be used as a means to evaluate a student's progress in a single course attempt. The Progression subsystem allows the creation of rules that evaluate progress based on a Weighted Average Mark value alone or in combination with other measures (Unit Failure or Proportional Failure measures).

Proportional failure rules calculate the number of failed credit points or units as a proportion of the number attempted in a single student course attempt. This proportion can be calculated for the whole student course attempt or only for specified progression periods. Rules using this proportional value measure it against an allowable maximum value, entered as part of the rule. Rules can be constructed based on this measure alone, or in combination with other measures (GPA, WAM or Unit Failure).

The option selected determines whether the measurement uses Credit Points (attempted and achieved) or Units (attempted and achieved). It also determines whether the whole student course attempt is included or only those CP/unit attempts from specified progression periods.

Unit Failure rules consider student unit attempt failures for a single student course attempt. Rules can be constructed which evaluate a student's progress using a measurement of Unit Failure alone or combined with a GPA, WAM or Proportional Failure measure.

Rule options can be selected to consider the number of times a unit has been failed and evaluate this against an entered maximum number. They can also limit the measurement to only consider failure in unit attempts matching unit codes from a designated list or the opposite - to only consider failure in unit attempts other than those in a designated list of unit codes.

Research Milestones rules are used to measure the progress a research candidate is making. The milestones recorded for a candidate and maintained throughout the candidature (in RESF3232) are used as the measure of progression.

Rules can be constructed to evaluate progress based on the existence (for a candidate) of milestone types with a FAILED milestone status. This can be further qualified to measure the number of failed attempts at reaching that milestone against a minimum number allowed by the rule.

Alternatively, a rule may be constructed to evaluate the existence of any milestones that do not have an ACHIEVED status by the required date.

Both of these milestone measurements can evaluate the Milestone Status of all milestones recorded for the candidate or be limited to those matching a designated list of milestone types, entered when constructing the rule.

Minimum Rate of Progress rules are used to ensure that students maintain a satisfactory rate of progress. I.e. That they score the required number of credit points during the current progression period or over the previous X number of progression periods.

Maximum Time rules are used to determine if the maximum time available to complete a course has been exceeded.

Some of the measures described above can be used in combination. Using a Rule Category based on the appropriate system rule call code when constructing the rule gives access to the rule options from both progression measures plus the logical And operator to join options into a single rule.

Every progression rule is constructed with the following component parts: Rule Category, Rule Code or Reference and the Rule Text. (A Description is required when the rule contains a Rule Code rather than a Reference.)

Rule Categories can be used as a way of grouping progression rules and there can be multiple categories mapped to the same System Rule Call Code. For example an institution may define the Rule Categories of UNITFAIL (a category for rules evaluating unit failure in compulsory units of study), PRACFAIL (a category for rules evaluating failure in practicum units) and UNITFAILNC (a category for rules evaluating failure in non-compulsory units of study). All three can be mapped to the system rule call code of PRG-UFAIL.

Progression rules are of two types. They may be general application progression rules that can be seen as a 'pool' of rules that can be applied at one or more levels in the rule application hierarchy (e.g. for more than one organisational unit). The second group is the 'application-specific' rules. These are built for a specific application element (e.g. a specific course type) and cannot be used against other system elements.

Note: The Rule Code (for a general application rule) or Reference (for an application-specific rule) should not be named with the 'greater than' symbol > as the leading character. This may cause errors in the use of these rules.

Constructing the rule itself is done in the same way for both types of progression rules. The text of the rule is built in RULF2000, where all the options relevant to the rule category can be displayed using the Options/Validate button. If any option not applicable to the system rule call code is entered; the rule does not 'parse' successfully and cannot be saved. Similarly other syntax errors in the rule text do not parse and cannot be saved.

The concepts behind the linking of a progression rule to a system element (and the linking of progression calendars and outcomes) are described in the next topic.

A complete Progression Rule Application is one where a progression rule is linked to a system element, at least one progression calendar and at least one progression outcome. The processes of applying progression rules and outcomes to a student are controlled by this link between the rule, a progression calendar, a system element and a progression outcome.

Any rule application with no allocated calendars or outcomes (at any level) is incomplete and cannot be applied. An lamp displays on the Progression Rule Application form (PRGF5200) to alert the user of this.

Which rules can be applied to any individual student course attempt, is determined by the linking of the rule and a system element. These 'system elements' are Course Type, Organisational Unit, Course Version and Student Course Attempt. These form a hierarchy of rule application levels.

Where a Progression Rule Category contains a number of rules, the element to which each is linked, determines which of the rules is applied to a student.

A Rule Application at

In establishing these hierarchies of application, careful consideration should be given to the implications of these overrides. For example, an institution may have an organisational unit that represents the whole institution. A Rule Category covering unit failure rules is developed. This category contains 2 different rules. Rule 1 is intended to apply to all students (must not fail the same unit twice), Rule 2 is designed to apply to only those studying courses with a practical component (must not fail any practical unit). A Rule Application is defined for the 1^st rule, linking it to the 'whole institution' organisational unit. If the 2nd rule is assigned to a Course Version (which includes practical units) in defining its application, this overrides the 'whole institution' application of Rule 1 for any student in that course. This may not be the intentional outcome, when the hierarchy is not clearly understood.

Where the intention had been for both rules to apply to a student in a course with a practical component, a second rule category should be created to prevent this 'accidental' overriding of Rule 1 by Rule 2. Rule 2 can then be defined in Category 2 and linked to the course version, when the rule application is created.

For a student of that course, both Rule 1 and Rule 2 can now be applied.

Example: a progression rule may be linked to two semester-based progression calendar types. This rule can be applied in all instances of those two calendars. This means the rule is applied in each semester (at the date specified by the Apply Start date alias). A different rule may be linked to a year-long progression calendar type. This rule can then be applied according to the dates defined for that annual progression calendar.

The rules are applied to all active Student Course Attempts in the applicable time periods. But which Student Course Attempts are considered 'active' within a calendar instance? Any that has a status other than UNCONFIRM and that fits within the system element that is the context for the progression rule application.

The linking of a rule to a progression calendar can be done at three levels:

These levels at which the progression calendar type is assigned, have an order of precedence.

This is illustrated in the diagram below where semester length calendars (configured at system-wide level) are linked to the rule category and inherited by the 'GPA >= 5' rule application. These calendars assigned to the category are overridden (for any student under Organisational Unit 04) by the year-length calendar linked to the 'GPA >= 3.5' rule (and inherited by the rule application).

A rule application is applied from the period of its definition and continues to be applied in each instance of that progression calendar. Specified start and end points for a rule application can be defined as part of linking a progression calendar and a progression rule (at either the category, rule or rule application level). These include setting a Start Period, End Period, Student Start Period and number of Applications. All may be entered against the Progression Calendar Type selected (using PRGF1600, PRGF5100 or PRGF5200).

For a rule to be applied it must have one or more outcomes assigned, at some level in the rule application hierarchy. A progression outcome is the 'penalty' applied to a student who fails a progression rule.

The assigning of progression outcomes to a rule can be done at three levels in the hierarchy:

Attaching outcomes to multiple levels in the rule hierarchy may lead to an overly complex structure. Institutions may find it is better practice to attach all required outcomes to a single level in this hierarchy (and to note this in the Message text box field as a guide to users).

The same precedence and inheritance principals apply to assigned outcomes as to assigned calendars. Outcomes assigned at a preceding level may be appropriate for use at a 'child' level and can be inherited without defining any outcomes at the 'child' level.

In the diagram below, two progression outcomes have been linked to the Progression Rule Category. One of the rules within that category (GPA >= 5) has an outcome assigned to it. The other rule (GPA >= 3.5) inherits the outcomes assigned at the category level. When the rule applications are created, the appropriate outcomes assigned at preceding levels are inherited and no outcomes need to be assigned at the application level.

When defining and linking calendars and outcomes to a level in the rule application hierarchy, users should be aware of any linked at preceding levels in the hierarchy. Those assigned at a preceding level may be appropriate for use at the current level, so can be inherited without creating additional links. Inherited and assigned calendars and outcomes can be viewed through the Progression Rule Summary pop-up screen (displayed using the Category or Rule Summary button on PRGF1600, PRGF5100 or PRGF5200.