Standards in e-Learning: Why do we need them?

Standards are an integral part in everyday life. We take things for granted like the stop lights, clocks (analog and digital), electrical plugs that fit into sockets (with in country/continent), light bulbs, Railroad tracks, Internet, etc. According to International Organization for Standardization (ISO), standards are “documented agreements containing technical specifications or other precise criteria to be used consistently as rules, guidelines, or definitions of characteristics, to ensure that materials, products, processes and services are fit for their purpose.” There are two types of standards: a de jure Standard and a de facto Standard. De jure standards are those ratified by recognized international standards bodies such as the ISO and IEEE. De facto standards are those used by the vast majority of the market, but which aren’t necessarily open or based on any de jure standards. For example, Adobe Photoshop is considered the de facto standard for image editing, because it was chosen by the people who use it.

Simply put, de jure and de facto are used instead of "in principle" and "in practice," respectively. Typically, the process of standardization starts with a problem, followed by efforts to resolve such problems, then passing through a number of stages resulting into specifications. Ultimately, these specifications lead to the publishing of an accredited standard. A specification can be defined as a documented description. Some “specs” become a standard, which means they have received the stamp of accreditation by an authorizing body like IEEE, ISO.

SCORM, which stands for Sharable Content Object Reference Model, is one such standard for e-Learning. SCORM came out of Advanced Distributed Learning, an initiative which was formed as a developer and implementer of learning technologies across the Department of Defense. It is a collection of standards and specifications adapted from multiple sources to provide a comprehensive suite of e-learning capabilities that enable interoperability, accessibility and reusability of Web-based learning content. ADL’s vision is to “provide access to the highest quality education, training and performance aiding tailored to individual needs, delivered cost effectively, anytime and anywhere.”

Some of the issues we had before SCORM in e-Learning were:
· We couldn’t move a course from one Learning Management System to another.
· We couldn’t reuse content pieces across different Learning Management Systems.
· We couldn’t sequence reusable content for branching, remediation and other tailored
learning strategies.
· We couldn’t create searchable learning object libraries or media repositories across
different LMS environments.


SCORM addresses these issues and fulfils ADL’s vision by fostering creation of reusable learning content as “instructional objects” within a common technical framework. It describes that technical framework by providing a harmonized set of guidelines, specifications and standards and uses web as its primary medium of instruction. SCORM is built on the proven work of prominent organizations. It provides a reference model to accelerate standards development and is the first step to the path to defining a true learning architecture.

· Do you need to control learner access to courseware, track learner progress, or monitor
the effectiveness of your e-learning content?
· Do you want to be able to control the learner’s path through the content in some way?
· Do you plan to develop content in house and also purchase content from one or more
third-party content vendors?
· Do you plan to use the content for multiple new audiences in the future?
· Do you plan to reuse parts of the content in future courses?
· Are you planning to redistribute or sell the content to another organization?

If your answer to one or more of the above questions is “yes,” then you need standards such as SCORM.

We will know we are successful when these standards become transparent, the “e” is no longer needed in e-Learning and e-government and when sharing and reusing of become common place.

General architecture for a SCORM 2004 LMS implementationPart

Ostyn Consulting Resources
General architecture for a SCORM 2004 LMS implementationPart 1
Claude OstynVersion 1.0.2 Copyright © 2005, 2006 Claude OstynThis work is licensed under a Creative Commons Attribution-ShareAlike2.5 License
This are working notes for part 1 of a multipart document. The other parts are not publicly available yet. The plan for the other parts includes topics such as user interface considerations, client/server implementation considerations, use of XML, and auditing.

Part 1: Functional overview

Functional components and services
There are many ways to implement a SCORM 2004 conformant LMS. However a fully functional LMS includes a number of features that are beyond the scope of SCORM. A useful way to manage this complexity is to look at a practical LMS implementation as consisting of several main functional components. The components are not listed in any particular order:
Content repository
Delivery management system
SCORM 2004 conformant delivery system (a.k.a. Runtime Environment)
Historical tracking information repository
Learner administration
Objective tracking (a.k.a. Lightweight Competency Management)
General administration (including reporting and notifications)
User portal (what a user sees when not actually experiencing a SCORM package)
The functional components may be implemented as cooperating services, or in a monolithic implementation. A services based implementation allows the ability to update the components independently. Also, architecting as a services-based implementation facilitates the creation of integration interfaces, e.g. to integrate the learner administration component with an HR system.

Other services and enterprise integration
Obviously learning and training is not limited to SCORM content. A practical LMS will often need to include services such as:
Scheduling of offline learning activities, such as classroom instruction
Scheduling of facilities and resources such as physical or virtual classrooms and equipment or software tools
Gradebooks or similar means of tracking learner information in instructor-led learning contexts
Online virtual classrooms
Various synchronous or asynchronous collaborative learning tools, such as chat rooms, shared repositories for work products and resources used in group learning, wikis, help desks for expert advice on specific topics, etc.
Performance support, including reference libraries and help desks
Digital reference libraries for research or exploration, not necessarily tied to specific performance goals or targets
Collaborative learning facilities, such as multiuser simulation or game environments.
Personal portfolios
Also, increasingly, enterprises are looking at learning management as only part of a larger enterprise context in which human performance is managed to align with business goals and priorities. So, the LMS may be integrated with a competency management system that may include competency models, assessment processes and workflows, individual and group competency records, and various management tools to create, manage and mine competency information and facilitate alignment with business drivers.
Educational institutions have their own requirements. Some functional features that mesh with academic traditions, priorities and methods can be significantly different from those in a typical enterprise.
This document describes only the basic LMS functionality that is assumed to surround the management, delivery and tracking of SCORM based content. The other services and integration requirements are best described in separate documents with a broader scope.

Content repository
This is where SCORM packages are imported and stored for delivery. The basic repository features include:
Ingest process: Import, unpack and validate a SCORM 2004 package and store in a virtual or physical directory structure.
Maintain a catalog of imported packages. The catalog allows listing and searching. The catalog may use a subset of LOM metadata.
Extract metadata upon import and add to repository catalog, allowing minimal review/editing of metadata and completion of missing metadata.
Make a package available to the delivery management system (design to determine whether this is either in native form, or in a form pre-massaged for ease of delivery)
Maintain access permissions and provides access only as authorized. This supports workflow, in which a package that is being imported is not available until import is completed and the catalog entry is validated by an administrator. It may also support segmentation of the repository (e.g. different users have access to different types of content, or a content area may be restricted to users with certain privilege)

Support for remote content
SCORM content packages delivered by the LMS may reference learning objects that reside on remote servers, or the LMS might launch content packages that reside on remote servers. Because of the security constraints imposed by Web browsers to prevent cross-site scripting exploits, such remote content must appear to be coming from the same server of the LMS. This typically requires some infrastructure level implementation to allow the LMS server and remote content server to appear to be the same host.

Delivery System (a.k.a. Runtime Environment)
Figure 1: Schematic view of a SCORM runtime environment
This system provides the learner experience for a SCORM 2004 package. It manages the sequencing of the package. As a learner attempts to use the package successfully, this system manages the attempt. It also collects and maintain tracking data until the attempt is completed. The Delivery System is split into a server-side component and a client-side components.

Server side component
Delivers a single attempt on an activity tree on behalf of the Delivery Management System. The attempt may be suspended and resumed in a later learner session.
Instantiates the client side component (frameset and the original content of the frameset) for delivery in the client side browser
Receives and responds to communications from the client side component.
Maintains state for the activity tree and sequencing state.
Maintains state for each activity, including communication data model data that persist between sessions
Requests persistent storage of suspend data as needed from the Delivery Management System.
Offers system global objective status data to the Objective Tracking system, and gets global objective status data from the Objective Tracking system.
Offers historical tracking data to the Delivery Management System on an ongoing basis, or at least before discarding the data at the end of an attempt on a SCORM package activity tree or sub-activity.

Client side component
Typically consists of a persistent frameset that displays the runtime environment user interface components as well as the sequenced SCOs or Assets in a "stage" frame.
Includes the ability to send and receive data from the server side component without affecting the frameset itself or the stage frame. Some of the data may be fairly large (communication data model instances and/or runtime environment user interface data, such as the user's view of the activity tree, updated according to sequencing rules)
Manages the communication session for each SCO that is being launched.
Implements an API object that responds synchronously to the API calls from the SCO.
Sends data reliably to the server side content in response to API "Commit" calls that may come in rapid succession or be widely spaced.
Implements minimal user interface components as listed in SCORM 2004 S&N book.
Implements a way for the user to inspect and navigate through a "tree of activities" that is updated dynamically to reflect the current state of allowed or visible activities, and which allows the user to choose activities randomly when allowed by the sequencing rules.
Manages display of interstitial state content "between SCOs" as necessary; for example, prompts the user for choices when the sequencer encounters a choice situation with no default flow control mode to guide the choice toward a specific activity.
Attempts to manage gross user errors such as attempts to close the browser before server side data has been committed.

Delivery management system
The delivery management system keeps track what is being delivered and for whom, and manages the persistent state of SCORM data between user sessions and user attempts.
Provides minimal management of user "attempt registration" status, e.g. maintains relevant state info as long as a user is "registered" for an attempt on a SCORM package.
Prevents multiple concurrent registrations by the same user for the same package.
Negotiates with repository for access to the content package to be delivered by the Delivery System.
Instantiates the Delivery System when the user is ready to experience a SCORM package.
Prevents multiple concurrent instances of the Delivery System for the same user.
Maintains state data on current attempt, including maintenance of the temporary persistent storage for the complete suspended state of an activity tree and its sub-activities.
Offers historical tracking data to the Historical Tracking Information Repository on an ongoing basis, or at least before discarding the data at the end of an attempt on a SCORM package activity tree or sub-activity.

Historical tracking information repository
The historical tracking information repository maintains historical records of past attempts to use SCORM 2004 packages. It may also maintain current records that are subject to update until "finalized". Note that the SCORM does not define any requirements for the management of historical records, except for the status of certain objectives declared in content packages (see below).
Provides structured access to viewing or reporting services that are used to review learner and/or package activity records.
Accepts records of SCORM Activity tree sequencing status data model and individual activity status data model (IEEE 1484.11.1 data instances)
Manages storage and indexing of the data records (keyed to learners IDs, package IDs and attempt number)
Manages aging and archiving of aged data (storage space management, hierarchical storage, etc.)

Learner administration
The learner administration scope of complexity may vary considerably, depending on the level of integration with enterprise systems. The SCORM does not define any requirements for learner administration, but obviously this is a key component of a practical learning management system. At a minimum, the learner administration provides services such as:
Provides a means to register users or relate to existing user data.
Provides a means for learners to self-register for learning activities that use SCORM packages, if allowed by enterprise policy.
Provides a means for managers of the learning process to assign learning activities that use SCORM packages to users and to set constraints on those learning activities, such as number of attempts allowed or deadlines.
Provides a means for learners and managers to view the status of assignments and review tracking data and summary results.
If groups are supported by the LMS, provide similar services for a group as for an individual user, as well as administration of group membership.

Objective tracking (a.k.a. Lightweight Competency Management)
This is a lightweight system that manages the status of objectives associated with a learner. SCORM 2004 has a concept of "system global objectives" for which the status is maintained across attempts and across SCORM 2004 packages. This system may be built into the Delivery Management System or be a standalone component, or a service provided by a real competency management system.
This system:
Stores objective status for users in the form of "competency records"
Provides the Delivery System with current objective status data, if available.
Receives updated objective status data in the form of "evidence records" with the source of the data change (e.g. SCORM package, attempt number, timestamp) and updates the current competency records or propagates the information to "official" records according to administrative policy. For example, if policy is that an employee's competency records cannot be directly modified by a SCORM course without review or vetting, the status that is persisted for SCORM does not automatically propagate to the official competency records but a change of status may result in a workflow event to request review and update the official competency record.

General administration
There are three major components of General Administration:
General glue
Authentication and Authorization
Reports

General glue
This is the "glue" system that a system integrator uses to tie together the different components and services of the LMS.

Authentication and Authorization
This may include user authentication and single sign-on management, role management (e.g. unrestricted administrator, learner, repository administrator, learning management administrator, etc.) and role associations (e.g. managers can only view reports on the employees they supervise). This system can be arbitrarily complex, and when the LMS is a good candidate for integration with existing enterprise administrative management systems (LDAP, Active Directory, etc.). A basic implementation might implement a very minimal rights and authentication system with a very small set of roles, such as: Administrator and Learner.

Reports
Management wants reports. Reports are typically required to monitor whether the enterprise goals are being met by the LMS, and to identify problems that may occur in the system or with particular users of the system. Extracting and massaging usage, status and tracking data requires the design of reports, or at least of some generic query interfaces or guidelines.

Notifications
A practical system often includes some kind of notification mechanism, typically using email. The SCORM does not define any requirements for notifications. A well designed notification system removes the need for concerned users to log into the LMS to receive notices that concern them. A notification system might provide periodic summaries for administrators or faculty, alerts sent to learners when a new course is being offered, alerts sent to learners when a deadline approaches to register for a course or to complete a course, confirmation of successful completion sent to a learner, or alerts sent to LMS administrators when abnormal conditions are detected, such as security alerts, storage limit alerts, or abnormal usage patterns.

Security and privacy
Beyond authentication and authorization as described above, a practical system typically includes security features, such as encryption of sensitive data, logging of events with security implications, administrative oversight procedures, and user interfaces provided to learners and managers only through a secure SSL session in approved browsers. Most LMS are operating in a context where new requirements for privacy and auditability may be imposed by law.

User portal
This is the set of services and/or components of user interface that allow a user to interact with the LMS. The LMS might have its own portal, or might be integrated in an enterprise knowledge portal or workflow system. For example, direct access and launching of SCORM packages might be taking place in an embedded performance system, where the entire LMS only appears as a link to a tutorial embedded in the reference that pops up when the user requests help on a task. In an enterprise portal, the LMS is typically embedded among other enterprise specific offerings available to authorized enterprise users.
More Ostyn Consulting Resources