Критический обзор концепции ОМС

Открытость

  Немодульные
энциклопедии
1990-е
IMS,
SCORM
1998-08
Проекты
ИСО
2005-08
УТ
ОМС
2006
УТР
ОМС
2008
Реально
ОМС
2008
16.Открытость для обмена / потенциально +– / +
17.Открытость для копирования ++ +++
18.Возможность внесения изменений ++ +++
19.Полная открытость для редактирования +
20.Поддержка основных медиа-форматов ++ +

– У нас остается единственная улика – пистолет.
– Ха-ха-ха! Так пистолет, Шарапов, перевесит сто тысяч других улик!

Итак, мы рассмотрели многочисленные слабости концепции ОМС. Остается проанализировать последний пункт, который иногда выдается за главное достижение предлагаемой технологии – «открытость» модулей и системы в целом. Быть может, здесь мы найдем нечто столь революционное, что это оправдает отказ ОМС от магистрального пути развития, принятого во всем мире?


ОМС – система, закрытая для обмена с другими

Говоря об открытости, нужно в первую очередь напомнить, что именно идеей открытости, «интероперабельности» контента вдохновляются создатели международных спецификаций IMS и SCORM. В самом деле, какую бы новую систему управления контентом я не придумал, если я обеспечил ее SCORM-совместимость, то смогу использовать любой модуль, выполненный в тех же стандартах любым другим производителем.

Ясно, что введением несовместимого с интернет плеера контента г-н Осин поставил ОМС вне международных стандартов – и тем самым наглухо закрыл систему. Теперь она может развиваться только как вещь в себе и, вместо сотрудничества и взаимообмена с многочисленными SCORM-ориентированными системами по всему миру, ей придется конкурировать с ними – с заведомо очевидным результатом.

Утверждение о том, что эта жертва принесена ради «настоящей открытости», которой якобы можно добиться только с использованием нестандартного ОМС-плеера вместо привычного всем браузера – абсолютно не соответствует действительности.


Пользователю нужен качественный продукт, а не возможность его исправлять

Перейдем от «открытости» системы к открытости контента на уровне отдельно взятого модуля. Начнем с того, что саму по себе практическую ценность открытости учебного модуля для редактирования пользователем г-н Осин многократно преувеличил. Реальность далека от пустых фантазий – исчезающее малый процент пользователей вообще когда-либо что-то правит, даже в простейших html-файлах. Общемировая тенденция предоставления услуг очевидна – сделайте мне хорошо, а не заставляйте меня что-то исправлять.

Я полагаю, г-н Осин как последовательный поклонник возможности «все подкрутить своими руками» должен ездить исключительно на «Жигулях»-классике и сторониться современных иномарок, в которых под капотом – черный ящик, доступный для ремонта только профессионалам.


Открывать сложный код – бесполезно, нужны редакторы

Обеспечить открытость текстовых или графических ресурсов – задача тривиальная, легко решаемая всеми современными модульными системами. Единственная область, где традиционно используется закрытый компилированный код – сложная интерактивность. И вполне очевидно, почему – сложный программный код в любом случае будет крайне сложно править постороннему.

Открытость сложного интерактивного контента в предлагаемом г-ном Осиным виде (JavaScript и «уникальный плеер», с несовершенством которого не сразу справляются даже профессиональные разработчики) совершенно бесполезна для рядового пользователя – поскольку программный код слишком сложен для непрофессионала.

Единственный общепринятый способ обеспечить возможность редактирования высокоинтерактивных модулей силами учителя или школьника – предоставление соответствующих wysiwyg-редакторов, позволяющих оперировать не с языком программирования, а с объектами высокого уровня (например, линиями и точками для модели динамической геометрии, областями и текстовыми полями для интерактивной карты и т.п.). При наличии такого редактора, открытость объекта «в кодах» не играет никакой роли, поскольку главная задача – обеспечить пользователю возможность редактирования контента – успешно решена. Частным случаем рассматриваемой проблемы является задача создания редактора курсов для агрегации элементов контента (см. раздел «Модульность»), так и не предоставленного г-ном Осиным.


Открытость тестовых заданий недопустима

Полная открытость категорически противопоказана для тестовых заданий – просто потому, что ученик всегда может подсмотреть ответ. Следует отметить, что г-ну Осину уже указывали на эту принципиальную и неустранимую уязвимость его концепции. Вот запись диалога на круглом столе «ЭОР нового поколения в вопросах и ответах»:

«– Вопрос по поводу тестов. Вот вы говорите, что можно залезть и вставить что-то свое. Значит, ученик может залезть и посмотреть правильные ответы тестов.
– Секунду! Подсмотреть – это не так-то и просто! Там вот нет такого, чтобы открыл сценарий – и сразу все ясно. Большие проблемы с этим.»

Все это не более, чем «жалкий лепет оправданья». Теперь уже, оказывается, модули не так-то легко править, как это доказывалось минуту назад.

«Может ли учитель сам изменить электронный модуль? Очень легко. Потому что ученики это делают исключительно просто

Не надо морочить людям голову – в рамках выбранной г-ном Осиным концепции указанная коллизия принципиально неразрешима. Если тестовый вопрос «полностью открыт для редактирования», я всегда могу найти в нем правильный ответ. Чтобы обеспечить осмысленность электронного тестирования, ответ на вопрос должен быть тем или иным образом закрыт.

Даже шифрование ответов не является неуязвимой защитой, если речь идет о серьезном тестировании – например, едином госэкзамене. В полноценных тестовых системах используется исключительно клиент-серверная организация контента, при которой на клиентскую машину пользователя вообще никогда не попадает правильный ответ – он хранится только на сервере, на котором и происходит сверка ответа пользователя с эталонным и пользователю отсылается только результат этой сверки, т.е. оценка. Такая архитектура, например, предусмотрена в спецификации IMS QTI. Впрочем, мы уже видели уровень непонимания г-ном Осиным понятия «клиент-серверная архитектура», так что удивляться его некомпетентности в области современных технологий тестирования не приходится.


Модули в ОМС закрыты, открытость только симулируется

Концепция «полной открытости», декларированная в Унифицированных требованиях (расширенных) к модулям ОМС, полностью дезавуирована практикой, официально одобренной г-ном Осиным. До разработчиков доведено следующее разъяснение к оценке уровня открытости:

«Если в данной сцене, наряду с закрытым фрагментом, присутствует открытый интерактивный учебный фрагмент, выполненный в строгом соответствии с OST, такая сцена считается частично открытой.
Если в ЭУМ на каждую закрытую сцену приходится по крайней мере одна открытая (выполненная в строгом соответствии с OST), содержащая образовательный контент сцена, модуль в целом относится к частично открытым.»

То есть ведущий идеолог проекта говорит по сути следующее: можете делать как угодно, но обязательно замаскируйте закрытость какими-нибудь фрагментами OST-скриптов. Например, если в какой-нибудь сцене учебного модуля рядом с закрытым объектом просто разместить картинку, сцена сразу превратится в «полуоткрытую». Разумеется, к реальной открытости для редактирования этот балаган отношения не имеет.

Читать дальше >>

  К началу страницы