DDES9911 Chap.9 Learning Systems and Performance Data
Learning Systems and Performance Data
A learning management system surrounds the simulation event with assignment, preparation, resource allocation, scheduling, access, support, capture, assessment, debriefing and reporting. This chapter designs that workflow around decisions rather than data volume.
It addresses context, access, retention, scenario versions, missing records, governance and the improvement actions that should follow from learner and program evidence.
What this chapter covers
- 01
Assignment and preparation
- 02
Resource and access management
- 03
Event capture
- 04
Assessment and debrief handoff
- 05
Reporting and analytics
- 06
Data governance
- 07
Continuous improvement decisions
Worked example · free
Specify analytics for distributed training
- 1Link assignment records to role, prerequisites and supported access.
- 1Capture only meaningful task traces and separate technical telemetry.
- 1Provide role-limited learner feedback and contextual program reports.
- 1Name the review owner, revision decision and scenario version control.
Key terms
- Learning system
- The coordinated people, technology, processes and evidence surrounding a learning experience.
- Event log
- A time-ordered record of selected actions and system events during a simulation.
- Scenario version
- An identifier preserving which task rules and content produced a performance record.
- Data minimisation
- Collecting only the information required for a defined and legitimate purpose.
- Action owner
- The person or role responsible for acting on an interpreted result.
Learning Systems and Performance Data FAQ
What belongs in the learning-system workflow?
The workflow can include module assignment, preparation, technical resources, access privileges, scheduling, support, the simulation event, selected capture, assessment, debrief, reporting, technical evaluation and program review. Each element should have a purpose and owner.
Why preserve scenario version and context?
Performance records are not comparable when task rules, hardware, support or learner conditions differ. Version and context data help reviewers distinguish a learning pattern from a delivery change, technical incident or altered scenario before drawing conclusions.
How much data should a simulation collect?
Collect the minimum trace required for learner feedback, valid assessment, safety and stated evaluation. Additional biometric, audio or video data need a specific purpose, access and retention plan. Cheap storage does not create an educational reason or a valid interpretation.
What should happen to failed session records?
Preserve enough technical context to distinguish a learner action from latency, tracking loss, software error or facilitator intervention. Mark the record as incomplete or invalid for its intended decision, route the fault to an owner and schedule a fair replacement where needed. Do not silently delete inconvenient data or score a failure as poor performance.
The audit trail should explain the exclusion without exposing unnecessary personal information.
Assessment move
Map the full workflow from assignment to improvement and place the simulation event in the middle rather than treating it as the whole system. For every data field, document purpose, context, access, interpretation, action owner and retention. Mark technical failures and missing records so they cannot become learner scores.
Design one learner-facing report and one program-level report, ensuring that each triggers a defined action. Finally, show how revisions are versioned and re-evaluated so continuous improvement is a governed cycle rather than a general promise. Construct a data dictionary for the traces you retain. Define each field, source, unit or category, scenario context and missing-value meaning.
A completion flag should not silently combine success, abandonment and technical failure. Clear definitions let educators and technical staff test the same interpretation. Draw an access matrix covering learner, facilitator, assessor, technical support, manager and researcher. Give each role the minimum view needed for its decision and explain any exception. Include the learner route for correction or questions.
If a supplier stores raw media, connect contractual and technical controls to the educational purpose. Design a dashboard from decisions backwards. Begin with the action a user may take, then choose the pattern, comparison and threshold required. Add a link to context and uncertainty. Remove any chart that has no owner or possible response.
For program comparison, preserve version, site, hardware, support and cohort information before interpreting change. End with a lifecycle review: confirm purpose before collection, monitor quality during use, revisit access and interpretation when the program changes, and delete records when the purpose ends.
Treat a proposed research use as a new decision requiring separate justification rather than an automatic extension of teaching analytics.
Working through Learning Systems and Performance Data in DDES9911? Sia is AskSia’s AI Education tutor — ask any DDES9911 Learning Systems and Performance Data question and get a clear, step-by-step explanation grounded in how DDES9911 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.