AICC Objetivos CMI005 Obj

8/4/2019 AICC Objetivos CMI005 Obj

http://slidepdf.com/reader/full/aicc-objetivos-cmi005-obj 1/26

DOCUMENT NUMBER: CMI005

Handling Objectives in the

AICC CMI Guidelines

WORKING DRAFT: 6-Jul-1998

THIS DOCUMENT IS CONTROLLED BY:

AICC CMI Subcommittee

ALL REVISIONS SHALL BE APPROVED

BY THE ABOVE ORGANIZATION PRIOR TO RELEASE

POINT OF CONTACT:

Scott Bergstrom

AICC Administrator P.O. Box 472

Sugar City, ID 83448-0472

Telephone: (208) 356-1136E-mail: [email protected]

File name: CMI005_obj.DOC

Caveats... The data contained in this document has been collected by the AICC as an

information resource for computer-based training programs. Neither the AICCnor any of its members assumes nor shall any of them have any responsibility for

any use by anyone for any purpose of this document or of the data which it

contains.

©1998 AICC

All rights reserved.



AICC/CMI Handling of Objectives DRAFT (1998-07-06)

Prepared by: ________________________ ______________ Jack Q. Hyde Date

FlightSafetyBoeing Training International

(206) 662-8484

Approved by: ________________________ ______________

Mark Scansen Date

Matsushita Avionics

Draft ii CMI005




REGISTRATION FORM

To receive free notification of revisions to this document,mail or fax the following information to

Scott BergstromAICC Administrator

P.O. Box 472

Sugar City, ID 83448-0472

Telephone: (208) 356-1136Internet address: [email protected]

Name:

Title:

Organization:

Address:

City:

State: Zip Code:

Telephone: Fax:

E-mail:

Draft iii CMI005




ABSTRACT

This document describes features in the AICC CMI

Guidelines relating to objectives.

KEY WORDS

CMI

Completion requirementsComputer Managed

Instruction

Guidelines

ObjectivesPrerequisites

The use of registered names, trademarks, etc. in this publication does not imply, even in theabsence of a specific statement, that such names are exempt from the relevant protective laws

and regulations and therefore free for general use.

Draft iv CMI005




Table of contents

1 INTRODUCTION.......................................................................................................................................1

1.1 PURPOSE...................................................................................................................................................1

1.2 R ELATED AICC DOCUMENTS......................................................................................................................1

2 OVERVIEW.................................................................................................................................................2

2.1 TYPES OF OBJECTIVES.................................................................................................................................2

2.2 METADATA ASSOCIATED WITH OBJECTIVES IN A COURSE....................................................................................2

2.3 OBJECTIVE IDENTIFIERS...............................................................................................................................3

3 OBJECTIVE RELATIONSHIPS .............................................................................................................4

3.1 R ELATION TO OTHER COURSE ELEMENTS.........................................................................................................4

3.2 OBJECTIVE R ELATIONSHIP TABLE.................................................................................................................6

J73...........................................................................................................................................................7

J74...........................................................................................................................................................7

4 INFORMATION FLOW..........................................................................................................................10

5 USING OBJECTIVES..............................................................................................................................11

5.1 PREREQUISITES.........................................................................................................................................11 Example 1.............................................................................................................................................12

Example 2.............................................................................................................................................13 Example 3.............................................................................................................................................13

5.2 COMPLETION R EQUIREMENTS.....................................................................................................................15

Example 1.............................................................................................................................................15

Example 2.............................................................................................................................................15

Example 3.............................................................................................................................................17

Example 4.............................................................................................................................................19

6 SUMMARY................................................................................................................................................20

Draft vi CMI005



AICC/CMI Handling of objectives DRAFT (1998-07-06)

1 Introduction

1.1 Purpose

The purpose of this paper is describe features related to learning objectives in the AICC CMI

Guidelines for Interoperability. This description should help developers understand how they

can use CMI features to identify, track, and analyze objectives in their courses.

1.2 Related AICC Documents

CMI001 - Guidelines for CMI Interoperability

Draft 1 CMI005




2 Overview

2.1 Types of Objectives

The guideline defines two types of objectives: simple objectives and complex objectives.

Simple objective:

This is an Assignable Unit level objective. These objectives are only found inside assignable

units. There are none, one or more per assignable unit. An assignable units determine and report

the status of simple objectives.

Complex objective:

This is an objective that is not confined to a single assignable unit. It is defined by various

combinations of AU’s, blocks, and other objectives. It is an objective whose status cannot be

reported by an assignable unit. Only a system that can look at the status of multiple courseelements can determine the status of a complex objective.

2.2 Metadata associated with objectives in a course

The following information is available for each objective in a course. This information is found

in the course interchange files.

Objectives Metadata

Name Definition Data Type Name Title for an objective. Provided by the

Assignable Unit developer string

Description Textual description of an objective. Provided by the AU developer.

string

Developer_ID An identifier for an objective. Created by the

AU developer.

string

System_ID An identifier created by the CMI system for

an objective. Unique to each objective in acourse.

restricted string

Draft 2 CMI005




2.3 Objective Identifiers

As can be seen in the Objectives Metadata, most objectives in a course have two identifiers, a

Developer ID and a System ID. The assignable unit or course developer assigns the developer

ID. The CMI system assigns the system ID.

Every course element – objectives, assignable units, and blocks – have a system ID. This assures

at least one totally unique identifier for each element in a course.

The system ID's have a defined format for each type of course element.

• Assignable unit ID's begin with the letter A followed by an integer number.

• Objective ID's begin with a J followed by an integer.

• Blocks begin with a B followed by an integer.

Developer ID's can be made up of almost any combination of characters.

A descriptor table with these two metadata elements is used to identify the relationship betweenthese two identifiers, when it becomes necessary in the examples. In the Objective RelationshipTable and in the diagrams, only the system ID's are used. The developer ID only becomes

relevant in the communication between assignable units and CMI.

Descriptor Table

System ID

J = Objective

A = Assignable Unit

Developer ID

A2 OVERVIEW_LESSON_2

J3 DEV361

Draft 3 CMI005




3 Objective Relationships

3.1 Relation to other course elements

Course elements, in the context of the AICC Guidelines, consist of

• Objectives

• Assignable Units (AU's)

• Blocks

Assignable units may have none, one, or more simple objectives.

A complex objective may encompass one or more assignable units. Some of the assignable

units may contain other objectives.

A block contains other blocks or assignable units. A block may also contain one or more

objectives

Draft 4 CMI005

AU Obj

Block

Objective




A complex objective may encompass one or more blocks

A complex objective may encompass two or more additional objectives

Simple vs. Complex Objectives

In the graphic below, the objective on the left is a simple objective, the objective on the right is acomplex objective. On the left, the assignable unit can report the status of the objective and a

different status for the lesson itself. On the right, the status of the lesson is reported to the CMI

system and the CMI determines the status of the objective based on the report. The assignableunit on the right may not even know of the existence of the objective associated with it.

Draft 5 CMI005

Simple Objective Complex Objective




3.2 Objective Relationship Table

All of these relationships can be described in the Objectives Relationship Table. It defines therelationship of the simple and complex objectives to other elements in the course structure. It

can also describe the relationship of assignable units and blocks to the objectives in a course.

The following example shows the relationship of three assignable units and five complexobjectives with the rest of the course.

Objectives Relationship Table

Course

Element

Member Member Member Member

A1 J1 J2 J3

A11 J2 J23 J24 J29

J73 J15 J16 J18

J74 A10 J12 J19 J20

J75 A 11 J74J76 B5 B7A2 J4

J5 A3

Assignable Unit A1 contains three objectives, J1, J2, and J3. A single objective may appear

more than once in a course. Assignable Unit A11, for instance contains objective J2 as well as

J23 and J24.

Draft 6 CMI005

J1J2

J3

A1

J23J2

J24

A11

J29





Course

Element


A1 J1 J2 J3

A11 J2 J23 J24 J29J73 J15 J16 J18

J74 A10 J12 J19 J20

J75 A 11 J74

J76 B5 B7

A2 J4

J5 A3

A default assumption in the CMI system is that a complex objective gains a status of passed

when all of its members are passed. Based on this table, Objective J73 is considered passed (or mastered) when objectives J15, J16, and J18 are all passed.

Objectives J15, J16, and J18 may all be in a single assignable unit, or they may each be indifferent assignable units. Other records in the Objectives Relationship Table need to be

consulted to determine which simple objectives are in which assignable units.

Objective J74 mastery requires that Assignable Unit A10, plus Objectives J12, J19, and J20 all

be passed.

Draft 7 CMI005

J15

J16

J18

J73

J12

J19

J20

J74

A10





Course

Element


A1 J1 J2 J3

A11 J2 J23 J24 J29J73 J15 J16 J18

J74 A10 J12 J19 J20

J75 A 11 J74

J76 B5 B7

A2 J4

J5 A3

Objective J75 requires that Assignable Unit A11 and Complex Objective J74 both be passed.

Objective J76 requires that Blocks B5 and B7 be passed. These blocks may contain several

assignable units and several objectives. The default assumption of the CMI guidelines is that a

block is passed when its members are all passed.1

1 The default assumptions can be changed by explicit entries in the Completion Requirements table.

Draft 8 CMI005

A11

J74

J75

B5

B7

J76





Course

Element


A1 J1 J2 J3

A11 J2 J23 J24 J29J73 J15 J16 J18

J74 A10 J12 J19 J20

J75 A 11 J74

J76 B5 B7

A2 J4

J5 A3

The last two entries in the table show the difference between the description of a simple

objective (J4) and the simplest of complex objectives (J5).

Draft 9 CMI005

A2

J4A3

J5




4 Information flow

When the CMI system launches an Assignable Unit (AU) it sends information to the lesson.

Some of this information is related to the objectives in the lesson. At the conclusion of theassignable unit, student performance in the lesson (AU) objectives is sent back to the CMI

system.

The information related to objectives is in the Objectives_Status group. Simple objectives may

have a status or both a score and a status associated with them.

Objectives_Status Group

Name Definition Data Type

J_ID.1 An identifier for the first objective. Created

by the AU developer. The same as theobjective Developer_ID. Each objective inthe lesson is arbitrarily identified by a

numerical extension to J_ID.

string

J_ID.2 The second objective whose information is

being reported by the lesson.

string

Score.1 A number associated with a student’s

performance of the first objective. A raw

score. Determined by a lesson.

integer

Score.2 The student’s performance on the second

objective.

integer

Status.1 An assessment of the student’s performanceof the first objective. Values: Passed, Failed,

Completed, Incomplete, Not_attempted,Browsed

vocabulary2

Status.2 An assessment of the student’s performanceon the second objective.

vocabulary

2 A vocabulary is a limited set of words, one of which must be selected as a value for the data element.

Draft 10 CMI005

CMI System

Lesson Start Lesson

EndAU




5 Using Objectives

Developers and instructors can use information on objectives to revise training programs and

optimize instruction for individual students.

A CMI system can also use data on objectives. The AICC CMI Guidelines do not prevent a CMIsystem from using objective mastery information in any way. For instance, CMI systems can

use objectives data to sequence student learning activities using artificial intelligence.

However, when a course is exported or imported the Guidelines enable describing only two

types of decision-making based on the status of objectives. The course interchange files to

describe the use of objectives to:

• Determine when the student has mastered a learning activity.

• Decide when the student has met the prerequisites for a learning activity.

5.1 Prerequisites

Prerequisites can be used to set up and describe a very complex lesson sequencing system if desired. Prerequisites are the basis for the description of sequencing in the course interchange

files.

Draft 11 CMI005

Complete?Ready?




The following are three examples of how objectives can be used to describe course sequencing.

The first is a simple linear sequence.

Example 1This is a course with only 3 lessons in it. They are A1, A2, and A3. The following prerequisite

table is for this course.

Prerequisite Table

Course Element Prerequisite

A2 J1

A3 J2

There is no prerequisite for A1, but there are prerequisites for A2 and A3, so A1 must be taken

first. After mastering objective 1 (J1) the only lesson for which the student has met the prerequisites, is A2. So A2 must be taken second. After mastering J2, A3 must be taken. So

this table forces the student into a linear sequence.

Draft 12 CMI005

A1

J1

A3

J3

A2

J2




Example 2This is another course with the same three lessons, A1, A2, and A3. This course however has a

different prerequisite table.

Prerequisite Table

Course Element PrerequisiteA3 J1 & J2

In this case, there are no prerequisites for A1 or A2, so the student can enter either lesson first.However, he can only begin A3 after mastering the objectives in A1 and A2.

Example 3This example shows how a relatively complex student navigation scheme can be represented in

only two lines in the prerequisite table. This course has 10 lessons, each is an assignable unit.

Three of the lessons must be taken before any of the others. However, they can be taken in any

order. After mastering all three, the student then has a choice of four additional lessons that he

can take in any order. Only after passing these four lessons can the student have access to the

last three lessons, which again can be taken in any order.

This example requires the addition of a Course Structure Table, which enables the description of

blocks. The first three lessons can be placed in block 1 (B1), the next four lessons in block B2,and the last 3 lessons in block B3. The Course Structure Table is organized like an Objectives

Relationship Table. However, it shows the relationship of blocks and assignable units without

reference to objectives. Three lines in this table represent the entire course of 10 lessons divided

into 3 blocks.

Draft 13 CMI005

A2

J2A1

J1

A3

J3




Course Structure Table

Course

Element


B1 A10 A11 A12

B2 A13 A14 A15 A16B3 A17 A18 A19

Prerequisite Table

Course Element Prerequisite

B2 B1

B3 B2

By default, a block is only considered passed, when all of its members have been passed. In this

example, the lessons inside each block can be taken in any order. However, the blocks must be

taken in sequence. For instance, a student can begin lessons A10, A11, or A12 at any time. Buthe or she could not begin lesson A14 until all three lessons (A10, A11, and A12) in block B1 had

been passed.

Although in this course the objectives are not used as prerequisites, they may be critical elements

in determining when each assignable unit is passed. In other words, they may be completionrequirements.

Draft 14 CMI005

A12

J3

A10

J1

A11

J2

B1

A16

J24

A15

J23

A13

J21

A14

J22

B2

A19

J33

A17

J31

A18

J32

B3




5.2 Completion Requirements

Objectives may be used to determine when a student has passed a lesson, or assignable unit. ACompletion Requirements Table is used to tell the CMI system what objectives must be mastered

to consider an assignable unit passed.

Example 1

Completion Requirements Table

Course Element Requirements

A5 J11=P & J12=P & J16=P

Assignable Unit 5 (A5) is considered passed if objectives J11, J12, and J16 have all been passed.

The assignable unit might pass back a lesson status as well as a status for each objective in theAU. However, the completion requirements table has priority over AU-reported lesson status.

The table tells the CMI system that the mastery of 3 objectives is required for a lesson status of

passed, regardless of what lesson status is passed back from the assignable unit.

Example 2

This is another example of how the Completion Requirements Table takes precedence over AU-reported lesson status.

Descriptor Table Completion Requirements Table

System ID Developer ID Course Element Requirements

A6 POW12_1 A6 3 of {J24=P, J25=P,

J26=P, J27=P}

J24 DEV324

J25 DEV325

J26 DEV326

J27 DEV327

The Descriptor Table shows the ID for each objective assigned by the original developer, and theidentifier given to that objective by the CMI system. The CMI system identifier is used in tables

showing course structure, prerequisites, and completion requirements. The Completion

Requirements Table entry says that any three of the set of objectives {J24, J25, J26, and J27}will result in a status of passed for the assignable unit A6.

Draft 15 CMI005

A5

J11 J12

J16




Assume that the following information is sent from the lesson to the CMI system at the

completion of the lesson.

CBT to CMI Communication

Lesson_Status = FailedJ_ID.1 = DEV324

J_ID.2 = DEV325

J_ID.3 = DEV326J_ID.4 = DEV327

J_status.1 = Passed

J_status.2 = Failed

J_status.3 = PassedJ_status.4 = Passed

The AU passes back a lesson status of failed because one of the objectives is failed. However,

the CMI overrides the lesson status with a status of passed, because the completion requirements

table indicates only 3 of the four objectives are required.

Notice that the CMI system must figure out the system ID for each objective status passed back

to it. The system ID is what is required to interpret the completion requirements table.

Draft 16 CMI005

A6

J24 J25

J27

J26

CMI System

A6 Lesson_Status = Passed




Example 3This example shows how objective status can be passed from one lesson to another via the CMI

system.

Descriptor Table

System ID Developer IDA4 SL3_2

A5 SM4_5

J11 DEV311

J12 DEV312

J16 DEV316

J18 DEV318

Objectives Relationship Table Completion Requirements Table

Course Element Members Course Element Requirements

A4 J16, J18 A4 J16=P & J18=P

A5 J11, J12, J16 A5 J11=P & J12=P &J16=P

Draft 17 CMI005




CBT to CMI

Communication


J_status.1 = PassedJ_status.2 = Failed

CMI to CBT

Communication

J_ID.1 = DEV311


J_status.1 = Not attempted

J_status.2 = Not attemptedJ_status.3 = Passed

If a student completes objective J16 in A4, then when the learner comes to A5 he or she onlyneeds to master J11 and J12. When entering lesson A5, information passed into the lesson

includes the status of all objectives in the lesson. Because the CMI knows that objective J16 isin both A4 and A5 (from the Objectives Relationship Table), it will pass the status of J16 into

A5.

While in A5, the lesson may be smart enough to route the student around the part dealing with

J16 and consider the student passed when he finishes J11 and J12. However, a less sophisticated

AU may ignore incoming information on objectives status. The student may recognize thematerial as something already seen and mastered. The student may consequently skip that

material and leave the lesson after passing J11 and J12. When he leaves lesson 5, because he

skipped the part of A5 with objective J16, the AU may believe its status is incomplete.However, because the CMI knows that J16 was mastered elsewhere, it will identify A5 as having

been passed.

This scenario assumes that the objective in both lessons has the same identifier -- J16 -- assignedto it in both A4 and A5. These two lessons came from the same developer or team, which

enabled the objective J16 to have the same developer ID in each assignable unit it appears.

Draft 18 CMI005

A5

J11 J12

J16

A4

J16

J18

CMI System




Example 4Sometimes a course is made of elements assembled from different sources. These different

sources may result in the same objective being covered in different assignable units. However, because different developers designed the different AU's, the objectives may have been given

different ID's by their developers.

Objectives Relationship Table Completion Requirements Table

Course Element Members Course Element Requirements

A20 J21, J22 A20 J21=P & J22=P

A30 J31, J32, J33 A30 J31=P & J32=P &

J33=P

Assume that in these two lessons objectives J21 and J33 cover the same area. How can the CMI

pass to lesson A30 that objective J33 has been mastered in lesson A20? The answer lies in theCompletion Requirements Table.

Assume the following two additional entries in the table.

Completion Requirements Table

Course Element Requirements

A20 J21=P & J22=P

A30 J31=P & J32=P & J33=P

J21 J21=P or J33=P

J33 J21=P or J33=P

This tells the CMI system that receiving a pass status from a lesson with either objective shouldresult in a pass status for both objectives. So when the CMI launches lesson A30, it will know

the status of J33 is passed because lesson A20 told it that J21 was passed.

Draft 19 CMI005

A30

J31 J32

J33A20

J21

J22




6 Summary

The CMI system has a pool of information about objectives. Objective status information on

simple objectives is updated as information comes back to the CMI system from each assignable

unit. The status of complex objectives is calculated, based on all information known by the

CMI. Known objective status information about any objectives inside an assignable unit is sentto the unit at startup.

Information on objectives may be used in sequencing assignable units. Identifying objective

prerequisites for assignable units does this. Simple linear sequences, to very complexsequencing can be described this way.

Objectives may also be used to determine when course elements are completed or passed.

CMI System

AU

AICC Objetivos CMI005 Obj

Documents

Transcript of AICC Objetivos CMI005 Obj