Consider refactoring AssessmentPeriod

Typical examples of assessment periods (in the "abstract" sense):

• Beginning of Year, Middle of Year, End of Year
• Fall, Winter, Spring

Current Data Standard:

• Assessment.AssessmentPeriod (as optional)

Proposed Changes:

• Assessment.AssessmentPeriod (as optional collection)
• StudentAssessment.AssessmentPeriod (as optional)

Benefit:

When the structure of the assessment does not change based on the assessment period, it is currently necessary to duplicate the assessment to describe each period the assessment is taken in. While the duplication is in itself not a problem, it tends to promote workarounds in the field to avoid the duplication (e.g. excluding the period altogether, or storing it as a student assessment score/ performance level). As a result, downstream analytics suffer.

The proposed changes will allow a more natural association of assessments to the periods that students take them in, while also allowing master data on the assessment to declare the periods that an assessment is intended to be used for.

Drawbacks?

Does this weaken the modeling of "concrete" assessment periods (i.e. with begin and/or end dates)? I think no because the current modeling of a single concrete assessment period on the assessment is still supported and the dates can be omitted for the student assessment period if desired. It may be useful though to describe some usage scenarios as guidance for implementors.

This would be a breaking change