Ранее я писал о CMI001 — «бабушке» технических спецификаций e-learning. Теперь поговорим о SCORM — «бате» электронного обучения.        SCORM — парадоксальный стандарт: создавался для военных, но применяется в корпоративном обучении. Поддерживается многими вендорами, но полностью — почти никем. Признан устаревшим, но активно используется. Требует от e-learning мастера технических знаний, но не добавляет ни копейки к ценнику в резюме. Позволяет запихнуть в совместимую систему управления обучением любой контент, но используется в основном для интерактивных презентаций.        Обо всём по порядку.        Shareable Content Object Reference Model создан в начале 2000-х инициативой ADL (Advanced Distributed Learning) — организацией при Департаменте обороны США. Авторы объединили 7 спецификаций, в том числе CMI001.     В итоге вышло три тома:    🔸 Модель упаковки контента (CAM). Про то, как собрать вместе файлы, из которых состоит курс и упаковать так, чтобы LMS их и правильно отображала.    🔸 Среда выполнения (RTE).  Отвечает на вопрос «какие данные и каким образом курс передаёт в LMS»    🔸  Структурирование и навигация (SN). Описывает, как материалы должны быть упорядочены и как объяснить LMS, в каком порядке и по каким правилам их показывать.    Вдобавок в последних поколениях стандарта есть раздел со сценариями тестирования (TR), которым очень удобно мочить вендоров на закупках.        Коротко о том, что описано в стандарте:    🔸 Из любого цифрового контента можно сделать электронный курс.    🔸 В курсе может быть несколько разделов, в том числе вложенных. На практике в 99% случаев раздел один.    🔸 Разделы курса бывают двух типов: asset (простой файл, например PDF или изображение) и SCO (объект распределённого контента — набор asset-ов с HTML-обвязкой, фактически веб-сайт). На практике чаще используются SCO, чем asset.    🔸 SCO сохраняет прогресс учащегося в LMS через определённый в стандарте API. Коммуникация происходит через ECMA Script: ранее через Action Script, сейчас через JS. Скрипт находит API в клиентской части LMS и передаёт данные о прохождении курса. Для этого есть около 20 переменных: статусы, баллы, ответы на задания, результаты целей обучения (не используется, как правило).    🔸 Курс поставляется в виде пакета (архива), содержащего весь контент и файл, описывающий структуру и правила воспроизведения.    🔸 Стандарт определяет механизмы навигации по учебным материалам и контролирует порядок прохождения курса. Опять же на практике это почти не используется, поскольку большинство курсов — single SCO.        SCORM на долгие годы стал стандартом:    🔸 упаковки учебных материалов;    🔸 разработки среды для их воспроизведения;    🔸 треккинга обучения и фиксации результатов.        А ешё, SCORM способствовал появлению WYSIWYG-редакторов для создания учебных курсов (авторскиз средств). Это позволило разработчикам не вникать в технические детали, а сосредоточиться на дизайне. В результате снизился порог входа в профессию, что ускорило развитие электронного обучения.     Конечно, без проблем не обошлось.    Во-первых, SCORM содержит неоднозначные положения: например, предлагает две переменные статуса прохождения курса (completion_status и success_status), но не определяет когда какую использовать. Это приводит к некорректному сбору данных, когда курс отправляет одни значения, а LMS ожидает другие. В целом, не смертельно и решается костылями, но интероперабельность страдает. Во-вторых, стандарт получился слишком объёмным, его полная поддержка затратна. Популярные редакторы создают только single SCO, игнорируя многосекционную навигацию. LMS в след за ними ограничивают поддержку multiple SCO. В-третьих, у SCORM несколько несовместимых версий, которые использовались одновременно. При работе приходилось проверять поддержку версий как в LMS, так и в авторских средствах, учитывая разную степень их реализации.    И наконец, SCORM — это только про электронные курсы. Но есть же и другие формы обучения. Вопрос их интеграции в LMS решился в другом стандарте - xAPI. Но про него - в другой раз.