Summary

Course demand analysis is complex in that it requires analysis of multiple kinds of information such as program requirements, the existing academic record, future course offerings, schedules, and what the student desires to pursue in terms of electives and optional course work.

This entry isn’t so much about how to do that but rather how to break down the problem into some manageable integration points. To do that will require breaking down and identifying the questions.

Parts

Actual Academic Record

The Academic Record typically communicates what the student has completed and is pursuing in terms of programs and courses. This is certainly a piece of the puzzle. For simplicity, we’ll call this information in osid.course.chronicle Actual Academic Record. That was easy,

Projected Academic Record

Based on the requirements of the program in pursuit, we can get a first cut understanding of the remaining courses. These can be slotted into terms and communicated using osid.course.chronicle.CourseEntries, a course expected to be taken next term. We’ll call this the Projected Academic Record.

What If There Are Choices?

Program requirements are not generally a simple list of courses which must all be taken. They have their share of options.

The problem then is that we don’t really know which course of a set the student will take. The answer is that we really won’t know until the student registers for it.

But for determining whether or not a program is achievable in a set time frame, aside from registration limits, we don’t care. As long as one of them can be slotted in a term, we’re good. The algorithm looks at prerequisites and co-requisites to lay out the needed courses while while respecting a reasonable student load per term.

For respecting known course offering registration limits, an optimization algorithm would move courses around to include this criteria.

Questions

There will not be a one size fits all implementation where we get to sit back and say we answer any question. Nor do you want to be in the business of providing endless streams of data integrations so some other bolt-on system can attempt to answer them. Bolt-on systems are notoriously poor at integration because they attempt to solve half the problem while trying not to get their hands dirty in the overall work to be done. Saying it differently, the problem with bolt-on systems is that they try to externalize a rules engine in the role of a service consumer because it consumes data, demanding every data detail coming through an endless set of micro-integration points, when in fact it is the service provider. This is the difference between the businesses of service integration versus data integration. Degree audit systems and schedulers are other examples of bolt-on non-service oriented data mungers in the academic enterprise.

Some of the questions in this sphere include:

1. Are you trying to test overall program requirements for sanity – that they can be accomplished in a time frame?

2. Are you trying to test overall program requirements for sanity, based on knowing that some courses are not offered every term?

3. Are you trying to test to see the number of students enrolled in a program (actual or projected) can get through? What is the maximum students the program, with its existing courses and registration limits, can support?

4. Are you trying to understand if the success is impacted by a course schedule for next term? What are the important scheduling conflicts?

5. Are you trying to understand if the success is impacted by a course schedule in future years?

6. Are you trying to understand the demand on a future course in order to predict the number of sections and/or size of classroom required?

   • Is this to be based on historical numbers? Historical numbers normalized against total enrollment?

   • Is this to be based on a student learning plan? What is a learning plan?

The implementation of these questions require data from all over the place The top integration points, however, are relatively few.

Providers

Projecting Program Completion

Can the student, enrolled in a credential program, complete and in what time frame? These are the ultimate results for questions 1-5 above. The highest and simplest integration point is osid.course.chronicle.CredentialEntry. Yes, the student can complete by this point in time or they cannot.

Where the credential program includes multiple enrollments to other programs such as majors and minors, the detail of which specific programs are problematic is communicated through osid.course.chronicle.ProgramEntry.

The implementation of this projected academic record handles the existing enrollments, requirements analysis and demand.

Simulating Demand on a Course By Course Basis

When we want to see students slotted into specific Course (or Course Offering), we look at osid.course.chronicle.CourseEntry as the main integration point.

One could get fancy and back this using an underlying provider of osid.course.registration.CourseRegistration. This leads us to…

Simulating Demand on a Section By Section Basis

To address question 6, a next level detailed simulation is needed we can see students slotted into various sections using osid.course.registration.ActivityRegistrations. From here we can do a demand analysis to test capacity limits and determine if the lack of capacity in terms of size or number of sections impedes student success.

Arrangements

Top Level

Shaded light to dark depending on how deep an OSID Consumer needs to go (how many questions?).

Implementation Scenario

This has everything going on where registration is used as the vehicle for delivering specific slotting. This is how question 6 would be addressed. Or, this can be dropped and simplified to project directly up to the academic record layer.

Notes

1. The Engine can be broken apart into smaller pieces. For example, the learning plan projection can surface through one set of projected registrations which feed an offering and scheduling analysis.

2. Demand analysis is often tuned to produce results of likely, some other threshold, and worst case scenario. These various results can be accessed simultaneously using multiple OsidCatalogs.

3. EagleApps is the only known system in production with an explicit concept of bundling activities into a single offering. These can be found in source systems in section-level co-requisites, course code games, or some other linking data.