Search code examples
scormscorm1.2

how to save and retrieve student responses SCORM?


Moddle: v3.10
SCORM: v1.2
LARAGON: v4.0

I was given the task of understanding how a SCORM package works.

With the examples on the SCORM website I was able to understand how to manage the lesson status, how to calculate the grade and from the grade inform the LMS if the student passed or failed.

But there is something that I am not able to progress.

When the student has already taken the exam I have already calculated his grade and told SCORM if he passed or not.

This same student can retake the exam and this is not expected, I did not find a way to store what his answers were and with that, instead of showing the exam form, showing the exam questions and the answers that the student answered .

The question remains:

  1. Does the LMS store the answers the student gave in the test?
  2. Will I need to use another language in parallel? jQuery, PHP, MySQL?

Solution

  • Yes, the LMS should store the answers the student provided. The data model you commit should be the same data model you get back when re-initialized.

    An LMS will not expect you to store student answers separately from the data model. Attempting to persist sessions on your own will likely confuse the LMS's developers/content managers and frustrate their tracking.

    Some platforms modify this implementation to impose pseudo-sessions on a package once a learner has completed/failed/passed the content. Others allow users to reset/retake the package.

    If you are implementing the package and do not wish to handle test retakes, you are not obligated. It is sufficient to store the questions and answers in cmi.interactions and mark cmi.core.score, cmi.core.credit, cmi.core.lesson_status, cmi.objectives.n.status, etc...

    One solution I've seen is to erase and re-use cmi.interactions for retakes while storing the previous scores in cmi.suspend_data.

    If you are implementing a SCORM engine for an LMS... honestly, I'd recommend not attempting. The specification is one thing, but attempting to comply with all the eccentricities of individual package creation tools, homebrewed packages, packages desiged for specific LMSs without regard to how they would function elsewhere, and misuse of data model fields to enable in-package features...

    It's a big specification, let alone what has been added/modified/hacked in the last two decades.