Progression — Special Topic

In this section:

Calculation of Grade Point Average / Weighted Average Mark

The GPA and WAM values can be calculated for a Student Course Attempt, in 3 ways.


Calculation of Grade Point Average

Where a Grade Point Average value is calculated for a student, the calculation uses the following data.

Achievable Credit Points: Every unit in a Student's Course Attempt has an Achievable Credit Points value (as defined in form CRSF2210). The calculation of a GPA value requires the total value of a student's Achievable Credit Points. Where an override credit point value is set for a Student Unit Attempt, the Override Value is used

Grade GPA Value: When defining a Grading Schema for use at an institution (in ASSF5110), each Grade can have a corresponding GPA Value nominated. Where this has been recorded, the grades recorded against the units a student has studied have an equivalent GPA Value.

The standard formula for calculating a student's GPA is:

GPA = Total (Achievable Credit Points * Grade GPA value) / Total (Achievable Credit Points)

 

Example

A student has the following grades recorded against 6 units

Unit

Achievable Credit Points Value

Student's Grade

Grade GPA Value

1

1

D

6.00

2

1

C

5.00

3

2

N

2.00

4

1

N

2.00

5

1

P

4.00

6

2

PC

3.00

Total:

8

   

Using these values the calculated GPA

=(6+5+4+2+4+6) / 8
= 27 / 8
= 3.3

The inclusion/exclusion of Student Unit Attempt Grades or the substitution of Grade Point Average values for use in the calculation is determined by the 'type' of GPA calculation. For the available types of Grade Point Average calculations refer to Progression Rules Overview or the syntax of Progression Rules. The inclusion/exclusion of discontinued Student Unit Attempts is determined by the associated Administrative Unit Status. A discontinued unit is only included in the calculation where that is a status with the 'Effectively Enrolled for Progression' check box set. (See ENRF0110.)

 

Storing GPA Values

Some GPA values, calculated as part of the process of applying Progression Rules, can be stored. This is only possible where the configuration parameter 'Calculate GPA check box' is set at the configuration level applicable to the Student Course Attempt (either System, Organisational Unit or Course Version configuration).

The GPA value is stored along with data that identifies the Progression Period in which it was calculated. Only Course GPA and Progression Period GPA values calculated using finalised results, can be stored.


Calculation of Weighted Average Mark

Where a Weighted Average Mark value is calculated for a student, the calculation uses the following data:

Achievable Credit Points: Every unit in a Student's Course Attempt has an Achievable Credit Points value (as defined in form CRSF2210). The calculation of a WAM value requires the total value of a Student's Achievable Credit Points. Where an Override Credit Point value is set for a Student Unit Attempt, the override value is used.

Numeric Mark Value: This is the numeric mark recorded as the assessment outcome for each unit a student has studied.

WAM Weighting Value: This is derived from one of two values.

The Unit Internal Course Level value is used where it exists. If not, the Unit Level WAM weighting value is used. If neither exist, a WAM Weighting value of 1 is used.

The standard formula for calculating a student's WAM is:

WAM = Total WAM Achieved / Total Achievable WAM

The Total WAM Achieved is calculated from the results recorded against each unit in a Student's Course Attempt.
For each unit:

WAM Achieved = Achievable Credit Points * WAM Weighting * Numeric Mark.

The Total Achievable WAM is calculated from the basic unit details recorded against each of those units.
For each unit:

Achievable WAM = Achievable Credit Points * WAM Weighting.

 

Examples

Example 1 - Using the Unit Level WAM Weighting:

3 Units have the following Unit Level WAM Weighting values

Unit

Achievable Credit Points Value

Unit Level WAM Weight Value

ABG271

2

2.00

ASC238

1

2.00

HD0101

4

9.00

 

Using these values for a student with the given marks, the WAM for that student would be calculated as shown:

Unit

Achievable WAM
(Achievable CP * WAM Weighting)

Student's Mark

WAM Achieved
(Achievable CP * WAM Weight * Mark)

ABG271

4

71

284

ASC238

2

85

170

HD0101

36

80

2880

Total:

42

3,334

Using these values the calculated WAM is:

= 3,334 / 42
= 79.381

 

Example 2 - Using the Unit Internal Course Level Value:

3 Units have the following Unit Internal Course Level values

Unit

Achievable Credit Points Value

Unit Internal Course Level Value

ABX712

2

2

ACC382

1

1

HD0411

4

4

 

Using these values for a student with the given marks, the WAM for that student would be calculated as shown:

Unit

Achievable WAM
(Achievable CP * WAM Weighting)

Student's Mark

WAM Achieved
(Achievable CP * WAM Weight * Mark)

ABG271

4

71

284

ASC238

1

85

85

HD0101

16

80

1,280

Total:

21

1,649

 

Using these values the calculated WAM is:

= 1,649 / 21
= 78.52

 

The inclusion/exclusion of Student Unit Attempt outcomes, and the full execution of the calculation, is determined by the 'type' of WAM calculation. For the available types of Weighted Average Mark calculations refer to Progression Rules Overview or the syntax of Progression Rules. The inclusion/exclusion of discontinued Student Unit Attempts is determined by the associated Administrative Unit Status. A discontinued unit is only included in the calculation where that is a status with the 'Effectively Enrolled for Progression' indicator set. (See ENRF0110.)

 

Storing WAM Values

Some WAM values, calculated as part of the process of applying Progression Rules, can be stored. This is only possible where the configuration parameter 'Calculate WAM check box' is set at the configuration level applicable to the Student Course Attempt (either System, Organisational Unit or Course Version configuration).

The WAM value is stored along with data that identifies the Progression Period in which it was calculated. Only Course WAM and Progression Period WAM values can be stored. This means the resulting value from those calculations that include Recommended marks cannot be stored.


Derivation of Show Cause / Appeal Expiry Date

When Progression Rules are applied, under a configuration that allows a student to show cause or appeal, the date by which that student must show cause or lodge an appeal is calculated. This calculation uses:

  • The Show Cause / Appeal Length value (from the configuration level which applies to this student)
  • The Show Cause / Appeal Cut Off Date Alias Instance (from the applicable Progression Calendar)
  • The date on which the Progression outcome was approved.

A Student's calculated Show Cause / Appeal
Expiry Date = Outcome Approval Date + Show Cause / Appeal Length value.

    • If this resulting date is later than the Show Cause / Appeal Cut Off Date Alias Instance, the Expiry Date is set to the Cut Off Date Alias Instance (where it is still a future date). This is the case for Student B in the example below.
    • If the Cut Off Date Alias Instance has passed, the Expiry Date for this student is set to the current date. This is the case for Student C in the example below.

This System derivation gives all students an equal number of days in which to show cause or appeal, providing the derived date is before the Cut Off Date. A user with the required level of security can override the derived date.

 

Example

Applicable Show Cause Cut Off Date Alias Value

Applicable Show Cause Length

Outcome Approval Date

Expiry Date (by which Student must have shown cause)

Student A

31/07/03

14

25/06/03

9/07/03

Student B

31/07/03

14

20/07/03

31/07/03

Student C

31/07/03

14

3/08/03

3/08/03


Derivation of Progression Outcome and Encumbrance Expiry Date

These dates can only derived be where the Duration and Duration Type are defined as part of the Student Progression Outcome. Only outcomes with the System Progression Rule Outcome Types of SUSPENSION, PROBATION or MANUAL can have a duration/duration type and therefore derived Expiry Dates (for both the outcome and the associated Encumbrance).

The derivation depends on the existence of instances of the future Progression Calendars of the same Stream Number as the Progression Calendar in which the outcome was applied. The number of instances that must exist is the number entered for the Duration of the Progression Outcome. The instance (for the identified Progression Calendar) of the Encumb End Date Alias (set in the System-wide configuration) is recorded as the Expiry Date. (If there is no instance of this Date Alias in the existing Progression Calendar, the End Date of that Progression Calendar is used instead.)

Where the Duration Type = NORMAL, the Expiry Date is the Encumb End Date Alias instance for the nth future Progression Calendar instance, where n = Duration.

Where the Duration Type = EFFECTIVE, the Expiry Date is the Encumb End Date Alias instance for the nth future Progression Calendar instance in which the student had a Student Unit Attempt with the status of ENROLLED, COMPLETED or DISCONTIN recorded in a subordinate Teaching Period.

Where the required Calendars do not yet exist, Expiry Dates are not recorded and the batch maintenance process (PRGJ6450) derives the dates as soon as it is possible (because the Calendar Instance has been created).

Some Progression Outcomes (and their associated Encumbrances) cannot have a Duration/Duration Type specified and therefore cannot have a derived Expiry Date. These are outcomes with a System Progression Rule outcome type of EXCLUSION, EXPULSION or NOPENALTY. These types of student Progression outcomes must be manually ended in one of the following ways.

  • A Decision Status of CANCELLED can be entered for the outcome. When this change to decision status is applied (through running job PRGJ6800) the System Date is entered as the Expiry Date for both the Student Progression Outcome and associated Encumbrance/Encumbrance effects.
  • An outcome could have the Expiry Date manually set to enable the ending of an outcome without changing the decision status. This can be done to end one of the Outcome Types that cannot have duration details recorded. It can also be used to expire a current outcome to allow the application of another incompatible outcome. For example where a student who currently has an applied PROBATION outcome is to have an EXCLUSION outcome added. This incompatible outcome cannot be added until the existing probation is expired.

Any outcome can be manually expired by overriding a derived Expiry Date where the user has the required authority.

 

Examples

Scenario One:

A suspension of a NORMAL duration type and duration length of 2 is applied to Student1 on 25/6/2003. The Progression Periods in this scenario are semester length with a Stream Number of 1, so the student is suspended for Semester 2 2003 and Semester 1 2004. The Outcome Expiry Date = the Encumb End Date Alias Instance for the Semester 1, 2004 Progression Calendar.

Outcome Duration Type

Duration

Stream Number (of Progression Calendar Instance)

Required Conditions to Derive Expiry Date

Applied On

Outcome / Encumbrance Expiry Date

NORMAL

2

1

2 active future Progression Calendars with Stream Number = 1

e.g. Semester 2, 2003
& Semester 1, 2004

25/06/2003

Encumb End Date Alias Instance from 2nd identified Calendar
= 1/6/2004

 

Scenario Two:

A suspension of a NORMAL duration type and duration length of 2 is applied to Student2 on 25/11/2003. The Progression Periods in this scenario are year long with a Stream Number of 2, so the student is suspended for the academic years of 2004 and 2005. The Outcome Expiry Date = the Encumb End Date Alias Instance for the year 2005 Progression Calendar.

Outcome Duration Type

Duration

Stream Number (of Progression Calendar Instance)

Required Conditions to Derive Expiry Date

Applied On

Outcome / Encumbrance Expiry Date

NORMAL

2

2

2 active future Progression Calendars with Stream Number = 2

e.g. Year 2004
& Year 2005

25/11/2003

Encumb End Date Alias Instance from 2nd identified Calendar
= 1/12/2005

 

Scenario Three:

Student3 has a probation outcome applied that has an associated encumbrance type restricting this student to part-time enrolment. This outcome has the duration values of 2 EFFECTIVE periods. The Expiry Dates cannot be derived until the student has been effectively enrolled for 2 Progression Periods. When the second period in which the student is effectively enrolled is identified (through running of the batch maintenance job PRGJ6450) the Expiry Dates are derived.

Outcome Duration Type

Duration

Stream Number (of Progression Calendar Instance)

Required Conditions to Derive Expiry Date

Applied On

Outcome / Encumbrance Expiry Date

EFFECTIVE

2

1

Active future Progression Calendars with Stream Number = 1
e.g. Semester 2, 2003
Semester 1, 2004
& Semester 2, 2004

Student must have at least 1 Student Unit Attempt with status of ENROLLED, COMPLETED or DISCONTIN recorded in a Teaching Period subordinate to each of the Progression Calendars.

25/06/2003

Completed Student Unit Attempt in Semester 2, 2003 Teaching Period.

No Student Unit Attempt in Semester 1, 2004 Teaching Period.

Enrolled Student Unit Attempt in Semester 2, 2004 Teaching Period.

Encumb End Date Alias Instance from 2nd identified Calendar
= 1/12/2004

 

Note: where the unit status is DISCONTIN, the associated Administrative Unit Status must be one that considers this unit 'effectively enrolled for Progression' (see ENRF0110)

 

Last Modified on 12 March, 2004