...
Term | Definition |
|---|---|
Unit | This is a system-generic quantity to describe the currency a program uses to manage the value of activities in the system. Unit is almost always translated into some other label, such as “PDU,” “CEU,” “Point,” or “Credit.” The purpose of the unit is to standardize a way of measuring progress. |
Activity Unit | This is a number assigned at the Activity Definition regarding the value of a pre-defined Activity. Programs use Activity Units to specify the value of an Activity as it is used throughout the system. Activity Units are used commonly in Education Management scenarios in which the program evaluates course submissions and defines how much credit the activity awards upon completion. |
Requested Unit | A Requested Unit is the amount of credit a person wishes to receive for credit. |
Granted Unit | A Granted Unit is the amount of credit the program agrees to assign to the request. |
Activity Units vs the Requirements Model
Requested and Granted Units function very well to assign value to specific Activities at a local level. When an Applicant Requests a specific credit for an Activity, any determination of the value of that Activity is made at the local level independent of the overarching Requirements Model.
For example, if an Applicant requests 6 units for an Activity and the program agrees that the Activity is worth 6 units, that represents a complete transaction.
One of the challenges we have in LearningBuilder is that the Requirements Model may discount Requested and Granted Units based on Requirements Model Limits. The system has no way to enforce Requirements Model rules during the data entry process. For example, the system cannot prevent someone from requesting units in an Activity that will subsequently not be counted. The reason for this limitation is that the evaluation workflow process is designed to evaluate units at the local level independent of its function in the broader application. A course is worth whatever the course is worth whether or not the application will count it towards requirements.
This limitation causes some confusion in our customers and prevents some operations that might seem accessible, for example:
We cannot represent and accurate number of Requested or Granted Units on a macro level because the count of Requested or Granted Units available to count is not subject to Requirements Model limits
We have some functional design options to close this cap, including:
Expose the Requirements Model to the Activity context when the Activity data is submitted;
Store the state of Requirements Model calculations;
In the meantime, we need to reinforce that Requested and Granted Units are to be used specifically to represent the amount of credit that represents the inherent value of the Activity independent of whether the program will accept in in the context of other Activities.
Practices for using Requested and Granted Units
...