HLASCORM PROTOTYPE

1
HLA/SCORM PROTOTYPE

• FINAL REPORT

2
PROJECT REVIEW

• Background
• 5,100 active duty Marine Captains
• Reserve Captains and some SNCOs
• EWS schoolhouse can only accommodate 190 students
  each year
• Remaining students use Seminar or Individual
  Guided Study (IGS) distance education program
  (DEP)

3
PROJECT GOAL

• Provide a richer, more robust learning
  environment to DEP student

4
PROJECT TEAM

• Anteon SCORM 2004 content
• mGen SCORM 2004 LMS
• MAK Technologies MAGTF-XXI

5
PROJECT COMPONENTS

• SCORM 2004 conformant instruction
• SCORM 2004 conformant LMS
• HLA-compliant MAGTF-XXI simulation

6
Distance Learning

• ISD vs. Simulation ? ISD and Simulation
• Three SCOs excerpted from the schoolhouse MCPP
  curriculum
• Practical exercises and Assessments
• Cooperative instruction
• SCORM 2004 conformant

7
Delivery

• Simulation data
• Huge volumes of data
• Proprietary encoding
• Runtime data availability to groups of students
• Solution
• Create a repository location with read/write
  access for students
• Store the location as a session variable

8
Simulation

• HLA-compliant MAGTF-XXI simulation
• Virtual multi-player capability
• Additional requirements
• Record parameters for game Host vs. Client
• Transfer/download scenario files
• Launch into a scenario from a web page
• Collect data from game
• Read XML and Save on Exit added to MAGTF v2.8

9
Achievements

• Launched simulation in multi-player environment
  from a SCO
• Captured data from simulation
• Sequenced content
• Demonstrated collaborative training using
  simulation
• Transferred scenarios for a variety of PEs
• Implemented mGens SCORM 2004 LMS with simulation
  capability

10
DEMO

• mGen LMS
• Content
• Simulation

11
Next steps

• Develop paper for I/ITSEC 2006
• Demos
• I/ITSEC 2005
• Seminar EWS Distance Education Program
• Independent Guided Study
• More research
• Student roles
• Use of AARs
• Upload Log files

12
Questions / Feedback / Ideas
13
IMPLEMENTATION PLAN

• Introduction
• Identification
• System overview
• Document overview
• Applicable Documents
• Version Description
• Installation
• Recommended Environment
• Launching

14
REVIEW SOW

• Prototype
• Sharable Content Objects
• Contractor shall repurpose portions of an
  existing course following the Instructional
  Systems Design model. Content shall be of sound
  instructional design and include engaging
  multimedia. At a minimum, the development of a
  Sharable Content Object (SCO) that conforms to
  the specifications of SCORM 1.2 is required. The
  use of draft SCORM 2004 is encouraged if an LMS
  can be identified to support it.
• Deliverables Instructional Design Plan,
  storyboards, source code and/or files for the
  instructional content including SCORM content
  packaging manifest and support files.
• Simulation/Scenario
• Contractor shall develop a scenario that
  emphasizes learning objectives taught in the
  SCOs. The scenario shall allow students to
  practice and apply concepts and processes as an
  extension of the training. Contractor shall
  employ an existing credible HLA-compliant
  simulation asset in the development of this
  prototype.
• Deliverables MAGTF-XXI executable with the
  associated scenario files.
• Learning Management System
• Contractor shall employ an existing Learning
  Management System (LMS) that minimally conforms
  to Sharable Content Object Reference Model
  (SCORM) version 2004 as described in the
  appropriate documents at www.ADLnet.org.
• Deliverables Source code and/or files for any
  middleware or other software specifically
  developed for demonstration of the prototype.

15
REVIEW SOW

• Shared Assets
• Contractor shall design and develop shared assets
  to facilitate communication between the SCORM and
  HLA. The shared assets shall be capable of
  initializing a simulation, launching a scenario,
  and returning performance criteria on the
  student. This/these assets shall be capable of
  receiving and sending data in a format compatible
  with both HLA and SCORM.
• Deliverables Launcher and Collector
  applications and any required meta-data necessary
  for launching simulations or defining evaluation
  criteria.
• Implementation Plan
• Contractor shall develop an implementation plan
  to capture installation instructions, the
  recommended training environment, and
  instructions on launching the SCOs within an LMS.
  
• Deliverable Implementation Plan

16
REVIEW SOW

• Prototype Demonstration
• Contractor shall provide all licenses, software
  and hardware necessary to establish the final
  prototype demonstration in the Joint ADL Co-Lab.
  Contractor shall document the actions and
  outcomes of the prototype demonstration.
• Deliverable Meeting minutes within one week of
  prototype demonstration
• Documentation
• At the conclusion of the HLA/SCORM prototype
  development, delivery, and testing, a final
  analysis document shall be provided which
  captures all relevant processes, decision points,
  considerations, and conclusions that resulted
  from this effort. Recommendations and lessons
  learned will be described. This documentation is
  intended to provide insight and information to
  further the process of integrating HLA-compliant
  simulations with SCORM-conformant courseware.
• Deliverable Final Technical Report

17
TECHNICAL REPORT

• ADL/HLA Integration Research Blueprint
• The prospect of integrating ADL SCORM courseware
  and HLA simulations raises a number of
  technological, instructional and programmatic
  issues
• Will a simple technical approach work for all
  cases?
• Can the use case be supported from an
  instructional perspective without changing the
  SCORM or HLA specification?
• If specifications changes are required, what are
  they and how long will they take to vet through
  the standards communities?
• Are the use cases realistic?

18
TECHNICAL REPORT

• Project Summary
• Purpose
• Background
• Prototype Use Case
• Technical Report
• SCORM 2004 Conformant Courseware
• Shared Assets
• Simulation and Scenarios
• SCORM 2004 Learning Management System
• Lessons Learned
• Future activities
• Conclusion

19
LESSONS LEARNED

• True RD has known and unknown schedule risks.
• Stay use case focused
• Use Case needs to be referred at each stage of
  development.
• Keep the Warfighter in mind
• MAGTF-XXI instruction is a prerequisite to this
  course.
• The learner environment and target audience must
  be considered when introducing this technology.

20
LESSONS LEARNED

• Minimize collateral impact
• Extending the data model for this project would
  have reduced the impact of the technical
  achievements.
• Simulation data requirements need to be analyzed
  using instructional design methods
• Several group instructional strategies exist. To
  focus on extending the data model for
  cooperative-based training only would be too
  narrow

21
FAILURES

• Future Requirement Uploading the scenario files
  after each practical exercise or after the COA
  game

22
FUTURE

• Group coordination
• A future version of the prototype would
  investigate ways to manage and link the group
  members in a more coordinated fashion. LMS group
  assignment, a multi-player lobby, and coordinated
  launch of a simulation or SCOs would enrich and
  simplify the distance learning experience.
• There needs to be more work performed in the area
  of requesting a shared URL for a specific group
  of learners within a simulation.
• I.E. Request a shared URL repository for.
• Section HLA Simulation 101
• Content Red-Blue Simulation
• Specific Users Joe, Mary, Larry, Mike

23
FUTURE

• Simulation data variables.
• The Launcher and Collector assets could be
  extended to enable a variable set of objectives
  and measurements to be sent to the simulation and
  more detailed assessment data to be returned.
• Extended data model prototype.
• Establishing a prototype environment which
  included extensions would allow prototype
  research and development to more quickly discover
  benefits and limitations.

24
FUTURE

• Data model extensions
• Simulation data. Mapping HLA specifications to
  instructional design methodologies may be a first
  step toward a closer linking of the two
  standards.
• Performance metrics. The SCORM standard needs to
  have the capability to record performance metrics
  in a more detailed cross learner nature. SCORM
  has no support for comparing learners
  performance and content effectiveness with a
  trending model.

25
FUTURE

• Data model extensions
• Course evaluation. Provide a way to evaluate the
  learning activity as a whole unit of instruction
  and supply valuable trending feedback to an
  evaluator.
• Content evaluation. This cluster could instruct
  the LMS on what sections of the activity tree
  will record detailed learner performance
  information Pass, Fail, or Score.
• Expected activity data. Provide information
  about the type of data produced by each activity,
  i.e. time, score, pass/fail, or none.

26
FUTURE

• Data model extensions
• Extend SCORM Standards by adding API Calls
• The simulation required a repository for runtime
  data and common data between users.
• New API call to request a unique repository URL
  based upon User-Content-Section of learning
• New API call to request a shared repository URL
  based upon Content-Section of learning
• New API call to request a shared repository URL
  based upon Section of learning
• Server response to the API would create a new
  folder on the server and with permissions to
  allow for HTTP PUT, WEB DAV writes and HTTP
  GETs to the folder.