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

Стандартизация   Немодульные энциклопедии 1990-е IMS, SCORM 1998-08 Проекты ИСО 2005-08 УТ ОМС 2006 УТР ОМС 2008 Реально ОМС 2008 13. Международный стандарт / потенциально – + – / + – – – 14. Кроссплатформенность – + + – + – 15. Стандартные плееры – + + – – – – Что нужно изменить, чтобы российские автомобили соответствовали мировым стандартам? – Мировые стандарты. В концепции ОМС много говорится о достоинствах стандартизации и необходимости ее внедрения в практику российского сообщества разработчиков. Действительно, во всем мире осознали преимущества стандартизированного подхода как при разработке учебных модулей, так и при создании систем управления контентом. Например, создавая модуль в точном соответствии со спецификациями SCORM, вы можете быть уверены, что он будет корректно отображаться в любой SCORM-совместимой системе. Вы думаете, что произнося аббревиатуру «SCORM» Александр Васильевич стремится приобщить нас к международному опыту? Вы глубоко заблуждаетесь, г-н Осин решил, что лучший стандарт – это стандарт, придуманный им самим. ОМС не совместима с международными стандартами «ОМС – это не оболочка и не очередной придуманный инструмент. ОМС – это двадцатилетний опыт работы, когда мы пришли к тому, что у нас получилось достаточно грамотно сложить все известные в мире программы.» (Круглый стол «ЭОР нового поколения») «ЭОР нового поколения на базе ОМС поддерживают полностью стандарт SCORM (Sharable Content Object Reference Model).» (Интернет-конференция «Школьная информатизация») Как можно классифицировать эти утверждения – как прямой обман или как недостаточную компетентность? От использования в ОМС части спецификаций SCORM RTE и CAM до «полной поддержки SCORM» – дистанция огромного размера. На самом деле, концепция ОМС абсолютно не совместима со SCORM-системами, поскольку основана на несовместимом с интернет формате и плеере контента. И это фатальный приговор – дальше обсуждать просто нечего. Некомпетентная монополизация вместо стандартизации Зачем же нужен этот нестандартный плеер, столь явно несовершенный как в задумке, так и в реализации, почему г-н Осин не пошел по традиционному пути и не использует в качестве «плеера» обычный интернет-браузер? Это, разумеется, не обеспечило бы автоматического соответствия международным стандартам – но хотя бы оставило потенциальную возможность развиваться в этом направлении (так, например, обстоят дела в проекте ИСО) и попутно позволило бы претендовать на интернет-активность и «коммуникативность». Убедительного ответа на этот вопрос нет. Невнятные аргументы, которые можно найти в документации, не выдерживают критики. «Решение задачи создания сетевых мультимедиа ЭОР потребовало разработки новой архитектуры, унификации структуры содержательных компонентов электронных образовательных продуктов и разработки единой программной среды функционирования.» «Программа-реализатор полноценного мультимедиа продукта. Во-первых, на экране монитора одновременно представляется множество мультимедиа компонентов (элементов контента), объединенных некоторой художественной композицией (назовем это «сценой»). Во-вторых, многие элементы контента интерактивны, т.е. реагируют на действия пользователя. В-третьих, контент может представлять достаточно сложные объекты и процессы, для описания которых требуется математическое или имитационное моделирование, реализуемое программами-моделерами. Таким образом, ПР должна одновременно воспроизводить связную комбинацию мультимедиа компонентов, что приводит к непригодности стандартных плееров.» (УТР) Утверждение абсолютно необоснованное. Возьмите стандартный браузер, html и JavaScript – возможности такой комбинации существенно больше, работать с ними легче, а результат воспроизводится надежнее чем при использовании ОМС-плеера – это вам подтвердит любой квалифицированный разработчик. Не говоря уж о том, что интерфейс стандартного интернет-браузера не только намного привычнее для пользователя, но и выполнен несравненно грамотнее с точки зрения юзабилити. Отвергая существующие стандарты, требуется решить четыре задачи: Нужно доказать, что имеющиеся стандарты плохи или недостаточны; Нужно разработать новый стандарт, который решает поставленные задачи лучше старых; Нужно убедить участников рынка, что следование новым стандартам принесет пользу всем; Нужно добиться административной обязательности нового стандарта для всех участников рынка. Впрочем, если с пунктами 1, 2 и 3 дела обстоят неважно, можно сосредоточиться только на пункте 4 – то есть стремиться навязать отрасли свои незрелые концепции в качестве обязательного стандарта. Именно по этому тернистому пути и двинулся г-н Осин. Стоит ли удивляться, что его инициативы вызывают в лучшем случае недоумение у профессиональных разработчиков. Разработкой универсальных плееров-браузеров позволяют себе заниматься очень немногие крупнейшие компании – Microsoft, Apple, Google, а теперь еще и г-н Осин. «Галантерейщик и кардинал – это сила!» Навязывая разработчикам никому не нужный ОМС-плеер г-н Осин представляет себя альтруистом – ведь этот плеер распространяется «совершенно бесплатно». Однако, это чистой воды лукавство. Большинство современных образовательных систем в качестве «плеера» используют свободно распространяемые браузеры, в том числе и выполненные в рамках технологи open-source. Интернет-совместимость – неотъемлемое требование спецификаций SCORM. Плеер ОМС не совместим с интернет, а значит, не совместим и с международными спецификациями. Кому же нужен такой плеер? Ответ прост – он нужен г-ну Осину, ведь это дает ему возможность извлекать из абсурдной ситуации все преимущества, которыми обладает монополист: В отличие от модулей, выполненных в соответствии с международными спецификациями, управлять oms-модулями может только нестандартная LMS, использовать готовые SCORM-системы невозможно. Угадайте – кому достанется соответствующий грант на разработку? Мало того, что вы должны делать модули в формате, навязываемом г-ном Осиным. Помимо этого, вы и всю функциональность внутри модуля должны строить средствами OST – внутренней технологии, разработанной в компании г-на Осина. Разумеется, в этой ситуации его организация получает преимущество – поэтому г-н Осин тщательно следит, чтобы другие разработчики не смогли сделать модуль каким-нибудь другим способом, даже абсолютно корректным с точки зрения требований УТР. Одновременно, ничуть не смущаясь, г-н Осин предлагает разработчиком купить у него средства разработки объектов в формате OST – а почему, собственно говоря, эти средства должны быть бесплатными? Такой вот нехитрый бизнес, вполне типичный для ситуации монополизма – все вынуждены покупать продукт, даже если он откровенно слабый. Таким образом, воспроизведя частичную поддержку спецификаций LOM, SCORM RTE и CAM, уже использованных в проекте ИСО, г-н Осин не только не продвинулся дальше, но и, напротив, остановил продвижение к международным стандартам и пытается направить российских производителей образовательного контента в тупик своих интернет-несовместимых решений. Читать дальше >>