SCORM

From TechWriter Wiki

Jump to: navigation, search

Contents

[edit]

Introduction

The SCORM (Shareable Content Object Reference Model) is a collection of standards and specifications for developing and delivering on-line (Web-based) training. In a nutshell, the SCORM seeks to improve the development and delivery of training courses through the creation of 'blocks' of training material (termed shareable content objects, or SCOs) that can then be re-used across multiple courses, and that can be included in or excluded from any given course without destroying the overall navigability of the course.

The SCORM standard enables the creation of small, reusable, sharable course content. It provides discoverable learning content, and the ability to find and move entire courses through the use of interchangeable repositories and consistent content descriptions. It also enables the development of adaptive learning systems that can assemble content to meet the learner's needs 'on the fly'. The SCORM achieves much of this by separating the course content from the delivery mechanism, and by providing a standardized way of describing and launching course content.

The SCORM is a relatively new standard, but adoption is growing. More and more applications are claiming 'SCORM-compliance' (or at least are providing ways of working within a SCORM-compliant environment). Many organizations are starting to consider e-learning as a viable proposition, and as they do, are looking to the SCORM as a way of insuring against vendor lock-in, and a way of ensuring ease of future maintenance of their learning content.

[edit]

SCORM requirements

The overall objectives and benefits of the SCORM are best understood by considering the requirements that the SCORM makes of any e-learning environment before the environment can be considered "SCORM-compliant'. These requirements are:

  • Reusability: It must be possible to re-use learning objects across multiple courses. This means that the learning objects must be discrete chunks of content that do not rely on other chunks of content being present in the course. This will make it possible to combine existing learning objects, quite possibly taken from separate courses, into a new course, without the new course looking like some kind of Frankenstein's monster that has been stitched together from spare parts. This speeds up the development time for new courses enormously, especially where existing courses are being re-worked for a new system version, or where different 'flavors' of a course are developed for different audiences.
  • Accessibility: It must be possible to locate and access learning objects stored in one location and deliver them (as learning events) to other locations. This is generally interpreted as the ability of developers to store content on a server and then for users to access this content via the Internet (or other Web-based network). This requirement is also sometimes used to refer to the 'discoverability' of content - that is, content should be described (via meta-data) in a way that allows content developers to easily find it.
  • Interoperability: It must be possible for a learning object created using one Learning Management System to be easily transported to another Learning Management System, without the need to re-work any of the content. Being able to do this has a number of advantages:
    • Vendor lock-in can be avoided (because the content is not stored in a proprietary format).
    • Content from many different sources can be used on any SCORM-compliant LMS.
    • Legacy content can be transformed into SCORM-compliant content and re-used without extensive new development (or re-development).
  • Durability: Content should not need to be changed (or at worst should only require a small amount of modification) if the system software changes - that is, if the LMS is upgraded.
  • Adaptability: It must be possible to tailor training content to meet the needs of the individual. Specifically, this means that the e-learning environment must support 'adaptive learning'.
  • Affordability: It must be possible for e-learning content to be developed and delivered quickly, and at a relatively low cost. This requirement recognizes the fact that for the SCORM to be widely adopted, it must be cost-effective - both in terms of the need to build the skills necessary to develop SCORM-compliant content, and the ability of users to access this content.

These requirements are requirements on an e-learning environment. Typically, this environment is provided by a Learning Management System (LMS). An LMS is a (typically Web-based) software application that manages the provision of courses. Typically, this includes registering learners in courses, delivering the content to the users, and recording learner progress for courses. A Learning Management System may also support content authoring, classroom and resource management, competency and certification, virtual classrooms, chat, and discussion boards, amongst other things (but the SCORM does not impinge on these areas).

Much of the SCORM specification therefore applies directly to the LMS, and not necessarily to the actual content (which is where the average Technical Writer comes in). It does not provide guidelines for the content, nor make any suggestions for how to best deliver e-learning. However, content developers must ensure that they build learning objects that can be used effectively by the LMS. It is therefore important that content developers develop 'SCORM-compliant' content.

[edit]

The SCORM specification

The SCORM specification is really just a collection of other standards and specifications (although some of these have been adapted for, or developed solely for, the SCORM). This was a shrewd move on the part of ADL (who developed the initial specification) as it is much easier to co-opt a pre-approved standard than it is to have a brand new standard approved. It also means that in some cases the expertise and tools already exist in the industry, which have adoption an early boost.

The standards used by the SCORM are gathered together into three 'books'. These are:

  1. The Content Aggregation Model
  2. The Run-time Environment
  3. The Sequencing and Navigation Specification

Each of these books are described in more detail below.

[edit]

The SCORM Content Aggregation Model

The Content Aggregation Model (CAM) describes how content is to be combined (aggregated) to form a learning object. Specifically, the CAM describes how to identify the SCOs that comprise a training course, and describes how to provide meta-data about course components. This information is contained in the manifest file (of which there is one per course). The manifest file is written in XML, and is always called imsmanifest.xml.

The CAM consists of the following standards:

[edit]

Learning Object Meta-Data

At the risk of diving into too low a level of detail, it is worth taking a closer look at the Meta-Data specification. This specification provides a way of describing content using a common vocabulary. By using a common way of describing content, it is much easier to locate content and to understand its nature and purpose. The vocabulary consists of nine categories of information:

  1. General: Information describing the resource as a whole.
  2. Lifecycle: Information about the history and current state of the resource (effectively, a version history).
  3. Meta-metadata: Information about the Meta-Data record itself.
  4. Technical: Information about the technical requirements and characteristics of the resource.
  5. Educational: Information about the educational and pedagogic characteristics of the resource.
  6. Rights: Information about the intellectual property rights for the resource (such as the copyright owner) and conditions for use of the resource.
  7. Relation: Information about the relationship between this resource and other targeted resources.
  8. Annotation: Comments on the educational use of the resource.
  9. Classification: How the resource fits into a particular classification system.

For a full list of the data elements, refer to the IEEE 1484.12.1 specification.

[edit]

The SCORM Run-time Environment

The Run-time Environment (RTE) defines how a Learning Management System and Shareable Content Objects interact. The RTE effectively provides a simple API that allows an SCO to set and retrieve data values that are held within the LMS, and also provides a data model for representing this information. Because the actual data storage and retrieval is mechanism is managed by the LMS and not the SCO, the SCO can easily be used with another LMS that perhaps uses a different storage and retrieval mechanism. Al that is required is for the LMS to accept the same 'set' and 'retrieve' commands, and support the same data elements - and this is the part that is defined by the SCORM.

The SCORM Run Time Environment specification consists of the following standards:

[edit]

The API

The API defines the run-time commands that can be used for passing data between the SCOs and the LMS. In order to conform to the SCORM, an LMS should support the following eight functions (split into three categories):

[edit]
Execution commands

LMSInitialize();
LMSFinish();

These two functions allow the SCO to inform the LMS that the SCO has started and finished. For minimal SCORM conformance, a SCO only needs to call LMSInitialize(); when it starts, and LMSFinish(); when it stops.

[edit]
Data transfer commands

LMSGetValue();
LMSSetValue();
LMSCommit();

These three functions are used (respectively) to retrieve, save, and confirm the change of data values. The data elements are defined in the Data Model (see below).

[edit]
Error handling commands

LMSGetLastError();
LMSGetErrorString();
LMSGetDiagnostic();

These three functions are used to trap errors and gracefully handle them. All communication between the LMS and the SCO (and vice versa) must take place via one of the above function calls. No other communication is possible. Although this may seem overly-restrictive, it is exactly this that provides the flexibility to move content from one LMS to another, and to re-use SCOs across courses.

[edit]

The Data Model

The Data Model provides 49 data items, organized into the following six categories:

  1. Core items: Used to capture the learning state of the object. This includes the learner's name, and the page they were on when they last accessed the course.
  2. Objectives: Used for recording and tracking course objectives.
  3. Student preference: Used to define the interface method preferred by the user.
  4. Student data: Used to track the user's progress.
  5. Interactions: Used to describe and track the user's responses to quizzes.
  6. Communications: Used to provide the SCO-to-LMS interface.
[edit]

The SCORM Sequencing and Navigation (SN) Specification

The SCORM Sequencing and Navigation (Added in SCORM 2004) provides the specification for how content objects should be sequenced, and how navigation through the course can be performed. It is this section of the SCORM that facilitates adaptive learning, for example by indicating that if an activity has been previously attempted the activity can be retried, or if an activity has been mastered (as determined by the objectives or a test) the activity can be skipped.

Before SN, a learner could (by design) select any topic (SCO) within a course, in any order. This was possible (and in some ways necessary) because each SCO is entirely independent (there are no SCO-to-SCO links), but in practice, is not normally what is required within a course. Generally, users should progress through a course in the order decided upon by the developer. The SN addressed this need, by providing a means of defining the order in which the SCOs could be accessed for a given course. Note that because the navigation is specified outside of the SCOs themselves, SCO independence is still maintained, and there is no contradiction in the standard. For example, the SN for one course may specify that the user should take SCO1 before SCO2, but another course may not contain SCO1, so the SN for that course simply omits any mention of this. SCO1 never calls SCO2 itself.

The SCORM Sequencing and Navigation specification consists of the following standards:

[edit]

SCORM for content developers

[edit]

Types of information in SCORM

The simplest type of information is a learning object (sometimes referred to as a content aggregation). Technically, a learning object is something that can be used to achieve a learning objective. Effectively, a learning object is a training course, and a learning objective is the course objectives.

A learning object will consist of several Shareable Content Objects or SCOs. It is probably easiest to think of SCOs as the modules, topics, or subjects within a course. However, SCOs are much more important than simply a convenient way of 'chunking' course content. The SCO is effectively a chunk of content that can be re-used across multiple courses learning objects). An SCO is the lowest level at which learning resources can be tracked by an LMS, and must be a 'complete unit of learning content'. Courses are typically developed by assembling SCOs. It is therefore critical that SCOs lend themselves to this type of reuse (this is discussed in more detail below).

The concept of re-use is muddied slightly by the introduction of the course asset (sometimes referred to as a sharable resource). A course asset is any unit of information that can be shared amongst (that is, reused in) several SCOs. A course asset could be a video, an interactive simulation, a PowerPoint slide, or even just a few lines of text. The only caveat is that assets must be in a format that can be delivered via a standard Web browser. The Web (whether Internet, Intranet, Extranet or otherwise) was chosen as the basis for SCORM delivery because of its widespread availability, and its ability to display many different types of content.

In summary, course assets are grouped together to form SCOs, and these SCOs are then combined to create a learning object. Or, to provide a PowerPoint analogy, course assets are the individual slides; these are combined to form modules, and the modules together make up the course.

[edit]

Shareable content

In order to facilitate reusability in the manner described above, it is essential that SCOs are truly independent - that is, there are no direct dependencies between them. Specifically, SCORM prescribes the following rules:

  • An SCO cannot be directly linked to another SCO;
  • An SCO cannot call another SCO;
  • An LMS can only have one SCO 'open' at any one time.

In effect, the LMS must launch each SCO itself. All communication (or passing of information) takes place between the LMS and the active SCO. Finally, the LMS must terminate the LMS before launching a new one.

The independence of SCOs facilitates another important aspect of SCORM - adaptive learning. Because every SCO in a course is entirely independent, any SCO could be removed from the course, and the course would still be usable. SCORM extends the concept of removing selected SCOs right up to the time that the course is taken, and allows the decision of whether a specific SCO is 'displayed' or not to be based on the needs of the user. Typically, this would be done by providing a 'pre-test' which checks the user's existing knowledge. If the user 'knows' a particular topic already, then the SCO covering that topic can simply be omitted from the course content when the course is presented to the learner, so that the learner is only being taught what they don't already know.

[edit]

Developing SCORM-compliant content

So much for the theory, but how do you actually 'do it'? As explained above, much of the SCORM specification applies to the LMS side of things. The content developer needs to create one or more SCOs and then load these into the LMS. Delivery of the SCOs (either together, or combined into other courses) is then controlled by the LMS.

1. Decide on the SCO 
The first thing to do is to determine what will constitute the SCO. As mentioned above, a SCO can be anything from a single screen of data to an entire interactive module. Generally, it is advisable to create SCOs that address single learning objectives, and at a level that makes re-use both feasible and sensible.
2. Ensure SCORM-compliance 
Once the SCO has been decided upon (or maybe leveraged as a module from an existing course) it is essential to make sure that it is SCORM-compliant. The most significant requirement is that the SCO is a stand-alone object - that is, it does not contain links to any content that is not contained in the SCO itself. Furthermore, all assets used by the SCO (such as graphics, etc.) must be available locally (for example, in the same directory, or a sub-directory, and referenced via relative (not absolute) links.
3. Add the API calls 
Once the SCO has been built (as a learning object), it is necessary to include calls to the LMSInitialize(); and LMSFinish(); functions. Most e-learning development applications can build a 'wrapper' around the actual content that does this. Alternatively, it is possible to simply use JavaScript to call these functions from the first and last objects (pages, slides, etc.) in the SCO. For content objects that are launched via a single HTML page (as tends to be the case with Macromedia Flash presentations), it is possible to code the LMSInitialize(); call on the OnLoad event for the page, and the LMSFinish(); call on the OnUnload event.
As described above, there are other function calls that can be made - for example, to set or retrieve specific data values. These can also be included in the SCO at this time.
4. Define the Meta-Data 
At this stage, the Meta-Data can be defined for the SCO. Typically, three levels of Meta-Data should be provided (although in practice all of these are optional):
  • Asset meta-data: Information describing the individual assets used in the SCO.
  • SCO meta-data: Information describing the SCO itself.
  • Content-aggregation meta-data: Information describing the package (see below).
Again, the e-learning development application can generally assist in doing this. Alternatively, the Meta-Data files can be created manually using an XML editor (or as a last resort, a simple text editor such as Windows Notepad). The IEEE 1484.12.1-2002 Learning Object Meta-Data standard (see above) describes the format and content of these Meta-Data files, and the 'IMS Content Packaging Version 1.1.3 standard (see above) describes how to include these files into the content package.
5. Create the content package 
Once all required files (assets, Meta-Data files, etc.) have been created, they need to be bundled up into a content package. The content and the format of the package are governed by the IMS Content Packaging Version 1.1.3 standard (included in the SCORM specification under the SCORM Content Aggregation Model - see above). In brief, this states that all assets and learning objects required by the course must be packaged into a single archive file (such as a .zip or .tar file), and that the root node of this archive file must contain a file called imsmanifest.xml, which is the Manifest File. Again, the IMS Content Packaging Version 1.1.3 standard covers the format of this file.
6. Load the package into the LMS 
Finally, the content package can be loaded into the LMS. How to do this will depend on the actual LMS itself. SCORM does not provide any control over or recommendations for this.

And that's it! The content can then be delivered by the LMS. Again, how to do this is likely to vary depending on the particular LMS.

[edit]

Further reading

Retrieved from "http://www.technicalauthoring.com/wiki/index.php/SCORM"
Personal tools
Support