Открытость
|
Немодульные энциклопедии 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-скриптов. Например, если в какой-нибудь сцене учебного модуля рядом с закрытым объектом просто разместить картинку, сцена сразу превратится в «полуоткрытую». Разумеется, к реальной открытости для редактирования этот балаган отношения не имеет.
Читать дальше >>
|