А. В. Осин Открытые образовательные модульные мультимедиа системы


Глава 4 Унифицированные требования



страница5/21
Дата24.11.2016
Размер3.84 Mb.
Просмотров4997
Скачиваний1
1   2   3   4   5   6   7   8   9   ...   21
Глава 4

Унифицированные требования

Создание электронных учебных модулей для открытой образовательной мультимедиа системы регламентируется унифицированными требованиями, определяющими архитектурные, программные и технологические решения, критерии оценки и допустимые значения параметров, характеризующих инновационные качества ЭУМ.

В данной главе приведены требования к электронным учебным модулям, выраженные в количественных показателях, поддающихся контролю, а также правила, по которым устанавливается соответствие критериям. При выполнении конкретных проектов по созданию ЭОР нового поколения заказчик вправе повысить значения показателей или отменить некоторые из них. Возможно также определение дополнительных требований. Однако Задание на выполнение работ ни в коем случае не может противоречить Унифицированным требованиям.

4.1. Требования к инновационным качествам

Уровень интерактивности

Уровень интерактивности электронного учебного модуля определяется используемыми формами взаимодействия пользователя с образовательным контентом. В случае, когда интерактив базируется на детерминированных формах, необходимым условием является использование в ЭУМ не менее четырёх различных форм взаимодействия, при этом:



  • ЭУМ относится к I уровню интерактивности, если в нем используется менее двух различных форм взаимодействия II-III уровней;

  • ЭУМ относится ко II уровню интерактивности, если в нем используется две и более различных форм взаимодействия II уровня, либо одна форма III уровня и одна или более – II уровня;

  • ЭУМ относится к III уровню интерактивности, если в нем используется две и более различных форм взаимодействия III уровня.

Использование в ЭУМ I-III уровней интерактивности менее четырёх различных форм взаимодействия пользователя с контентом не допускается.

В случае, когда интерактив ЭУМ основан на недетерминированных формах взаимодействия пользователя с контентом, критерием является выполнение необходимых и достаточных условий:



  • необходимым условием отнесения ЭУМ к IV уровню интерактивности является использование при функционировании модуля моделеров. Достаточным условием отнесения ЭУМ к IV уровню является недетерминированность действий пользователя при манипуляциях с элементами контента.

Оценка уровня интерактивности модуля исходит исключительно из взаимодействия пользователя с содержательными элементами контента, операции с манипуляторами не учитываются. Создание ЭУМ с неинтерактивным контентом, т.е. контентом, который нельзя отнести ни к одному из указанных уровней интерактивности, не допускается.

При разработке ЭОР нового поколения количественные соотношения ЭУМ различных уровней интерактивности существенно зависят от представляемой предметной области и уровня образования. Однако для любого проекта эти соотношения должны дифференцироваться по типам модулей и отвечать минимальным требованиям:



  • I уровень интерактивности допустим только для модулей И-типа, и в объеме не более 30% от общего количества ЭУМ И-типа;

  • модули П-типа должны иметь уровень интерактивности II и выше, причем модулей II уровня должно быть не более 40% от общего количества ЭУМ П-типа;

  • модули К-типа должны иметь уровень интерактивности II и выше, причем модулей II уровня должно быть не более 50% от общего количества ЭУМ К-типа.

Если проект состоит из нескольких этапов, указанные минимальные требования распространяются на результат каждого этапа. В случаях, когда Заданием на выполнение работ (Техническим заданием) по проекту устанавливаются более высокие требования, соотношения по уровням интерактивности ЭУМ, определенные в Задании, также должны выполняться на каждом этапе разработки.

Уровень мультимедийности

С точки зрения пользователя уровень мультимедийности контента – это разнообразие методов представления объектов и процессов предметной области, наличие статических и динамических, звуковых и визуальных компонентов контента.

В количественном выражении уровень мультимедийности контента ЭУМ – это число разных мультимедиа компонентов, используемых в модуле. В соответствии с таблицей 4.1 всего, с учетом разделения двухмерных и трехмерных анимаций, в распоряжении разработчика имеется шесть различных компонентов.



Общим требованием к любому электронному учебному модулю является представление учебного контента не менее, чем тремя разными мультимедиа компонентами. Иными словами, уровень мультимедийности любого ЭУМ должен быть не ниже трёх. При этом уровень мультимедийности любой сцены ЭУМ, представляющей учебный контент, должен быть не ниже двух.

Технически уровень мультимедийности определяется путем анализа содержимого папки DATA/components из состава модуля (см. рис. 2.3). В этой папке хранятся медиаэлементы, медиакомбинации и содержательные файлы 3D-анимаций, составляющие мультимедиа композиции в процессе воспроизведения ЭУМ. Анализу подвергаются расширения имен файлов, которые группируются по мультимедиа компонентам в соответствии с табл. 4.1. Оценка уровней мультимедийности отдельных сцен проводится при воспроизведении модуля.

Таблица 4.1.

Таблица для определения уровня мультимедийности



п/п

Мультимедиа

компонент

Допустимые форматы

Рекомендуемые расширения имен файлов

1.

Символьная

информация



HTML

UNICODE


.htm

.txt


2.

Статический визуальный ряд

(реалистический/синтезированный)



JPEG

JPEG 2000

PNG


.jpg

.jpg2


.png

3.

Динамический

реалистический

визуальный рад


MPEG1

MPEG2


MPEG4

H.264 (AVC)



.mpg

.mpeg


.mp4, .avi

.mp4, .avi



4.

2D динамический

синтезированный

визуальный ряд


FLASH

GIF


.swf

.gif


5.

3D динамический

синтезированный

визуальный ряд


3D Studio

Cal 3D


COLLADA

.3ds

.cat/.cmf/.crn/.cfg

.dae/.xml


6.

Звуковой ряд


MP3

Vorbis


MOD

.mp3, .wav

.ogg


.mod

Сцены, не являющиеся учебными, т.е. не представляющие для изучения объекты/процессы предметной области, при определении уровня мультимедийности не рассматриваются. К таким сценам относятся, например, вводные (заставка, постановка задачи), финальные (демонстрация итоговых результатов, фиксация окончания сеанса с указанием очередных модулей) и другие вспомогательные сцены, не содержащие образовательного контента.

Использование рекомендованных в табл. 4.1 расширений имен файлов позволяет безошибочно оценить разнообразие мультимедиа компонентов, используемых в модуле. Не возбраняется применять иные расширения имен, однако оценка уровня мультимедийности ЭУМ в таком случае потребует существенных дополнительных усилий.

Категория модифицируемости

Принципиально важным свойством электронного учебного модуля является его модифицируемость – возможность внесения пользователем изменений и дополнений, обусловленная архитектурой и программными решениями в рамках технологии открытого сценария (OST).

Электронный учебный модуль в открытой образовательной модульной мультимедиа системе изначально построен как полностью модифицируемый учебный продукт. Однако при использовании автономных контентно-программных продуктов (АКП) сторонних производителей требуется дополнительный анализ уровня модифицируемости.

Понятно, что потеря модифицируемости связана с закрытыми программными решениями в scenario ЭУМ. Если компьютерный сценарий модуля написан на компилируемых языках программирования, говорить о модифицируемости не приходится: файл с расширением .exe, содержащий машинный код, изменить практически невозможно.

Не лучше обстоит дело и в случае, когда scenario ЭУМ содержит фрагменты, разработанные по технологиям сторонних производителей. Например, во Flash-технологиях исполняемый код в бинарном файле с расширением .swf также недоступен пользователю. Это означает, что изменить тип медиаэлемента или компоновку мультимедиа композиции, переопределить реакции на действия пользователя невозможно. Иными словами, контент и методы организации интерактива в данном случае модификации не поддаются.

Тем не менее, архитектура ОМС допускает применение программного окружения ОМС-плеера при воспроизведении ЭУМ. Чаще всего такая необходимость возникает, когда некоторый фрагмент электронного учебного модуля по существу является автономным контентно-программным продуктом, разработанным по технологиям сторонних производителей, в частности – Adobe (Macromedia) Flash. Как указывалось выше, такой АКП закрыт для модификаций.

Собственно факт наличия в программном окружении стороннего плеера может и не влиять на модифицируемость модуля. Например, Flash-анимацией нетрудно управлять с помощью программного фрагмента, разработанного на JavaScript и XML в полном соответствии с OST. Технология открытого сценария позволяет использовать и другие популярные решения без потери модифицируемости модуля. В рамках OST можно построить сколь угодно сложную интерактивную мультимедиа композицию на базе виртуальной панорамы, реализовать интерактивный видеофрагмент на материале многокамерной съемки и многое другое.

Электронный учебный модуль, как правило, содержит несколько мультимедиа сцен. Для детального анализа модифицируемости модуля рассматривается каждая учебная сцена, представляющая учебные объекты и изучаемые процессы.

Мультимедиа учебная сцена считается открытой для модификаций, если она полностью воспроизводится по scenario, выполненному на JavaScript/XML в строгом соответствии с OST. Согласно архитектуре ЭУМ такой компьютерный сценарий размещается в папках SCRIPT и DATA/scene.

Мультимедиа учебная сцена считается закрытой для модификаций, если при воспроизведении какого-либо ее фрагмента используется компьютерный сценарий, выполненный по технологиям сторонних производителей в формате, отличном от формата исходных текстов программных продуктов. Согласно архитектуре ЭУМ такой сценарий размещается в папке MODELERS независимо от того, является ли он полным сценарием воспроизведения модуля или фрагментом полного scenario ЭУМ.

С целью квалиметрической оценки потенциальных возможностей модернизации учебного контента ЭУМ вводится понятие категории модифицируемости. Различаются электронные учебные модули трех категорий:


  • открытый для модификаций модуль не содержит закрытых учебных сцен. Интерактив и компоновку сцен в открытом модуле определяет scenario, реализованный в строгом соответствии с OST;

  • частично открытый для модификаций это модуль, в котором на каждую закрытую учебную сцену приходится, по меньшей мере, одна открытая, воспроизводимая по scenario, реализованном в строгом соответствии с OST;

  • закрытый модуль содержит более 50% закрытых для модификации учебных сцен.

Преимущественным требованием к ЭУМ ОМС является обеспечение категории «открытый». Разработка ЭУМ категории «частично открытый» допускается в случаях, обоснованных оригинальными возможностями контента, и в объеме не более 50% от общего количества модулей по проекту. Создание ЭУМ категории «закрытый» не допускается. Если проект состоит из нескольких этапов, указанные требования распространяются на каждый этап.

Кроссплатформенность

Обеспечение полнофункциональной работоспособности электронных учебных модулей на различных программно-аппаратных платформах накладывает дополнительные требования на программные решения ЭУМ. Так, при рассмотрении вопросов, связанных с расширением программного окружения для воспроизведения ЭУМ, необходимым условием является кроссплатформенность соответствующей программы стороннего производителя.

Использование в составе scenario или моделеров ЭУМ фрагментов (в том числе – автономных), разработанных на компилируемых языках программирования, недопустимо.

Кроме того, в scenario и моделерах ЭУМ запрещается использование компонентов, специфичных для какой-либо платформы, и нарушающих таким образом кроссплатформенность модулей. К таким компонентам, в частности, относятся: browser, plugin, ActiveX и тому подобное.

Следует отметить, что для обнаружения недопустимых программных решений достаточно запустить ЭУМ для воспроизведения на какой-либо одной из возможных платформ. Работоспособность и полнофункциональность модуля, воспроизводимого кроссплатформенным ОМС-плеером, гарантирует выполнение требований кроссплатформенности в ЭУМ.

Стоит только предостеречь от вероятной ошибки: до 2010 г. в пакете «ОМС-клиент» первой версии использовался плеер 1.0 для операционной системы Windows. Обнаружить при воспроизведении этим плеером модули с нарушениями вышеуказанных требований кроссплатформенности не представляется возможным.

Еще одно важное замечание: выполнение требований кроссплатформенности отнюдь не освобождает разработчика от обязательств по технологической культуре производства. Так, известно, что в операционных системах семейства Linux имена объектов файловой системы являются регистрозависимыми. Поэтому элементарную небрежность в написании имени файла с использованием прописных и строчных букв, допустимую в Windows, Linux уже «не простит». Файлы с одинаковыми именами, набранными в разных регистрах, будут считаться разными, работоспособность ЭУМ нарушится.


4.2. Технологические требования



  • Унификация архитектуры

Унифицированная архитектура электронного учебного модуля описана в разделе 2.3. Соблюдение архитектурных требований означает наличие и стандартное именование всех основных структурных составляющих – папок и файлов ЭУМ с содержимым, отвечающим установленному в разделе 2.3 функциональному назначению.

Допускается организация вложенных папок, именуемых по усмотрению разработчика, при этом характер содержащихся в них данных/программ должен соответствовать назначению папки верхнего уровня.

В таблице 4.2 перечислены папки и файлы, являющиеся стандартными структурными составляющими ЭУМ, с указанием характера содержащихся

данных/программ, отвечающих назначению папки/файла.

Таблица 4.2.

Архитектурные требования к ЭУМ



п/п



Наименование

стандартной папки/файла


Характеристика содержимого

1.

imsmanifest.xml

Данные. Стандартный (SCORM) файл манифеста – формализованное XML-описание ЭУМ.

2.

META-INF/manifest.xml

Данные. Метаданные ЭУМ, размещенные в XML-файле.

3.

META-INF/tech-data.xml

Данные. XML-описание размера поля вывода контента и указание «точки входа» − файла entry.xml.

4.

entry.xml

Программы. Инструкции на JavaScript, с которых начинается воспроизведение ЭУМ, размещенные в XML-файле.

5.

SCRIPT

Программы. Исполняемая часть scenario ЭУМ − инструкции на JavaScript, размещенные в XML-файлах.

6.

DATA/scene

Данные. Описательная часть scenario ЭУМ (компоновка и реакции объектов), размещенная в XML-файлах.

7.

DATA/components

Данные. Мультимедиа компоненты в допустимых форматах.

8.

DATA/skin

Данные. Мультимедиа компоненты в допустимых форматах и конфигурационные XML-файлы.

9.

MODELERS

Программы. Моделеры, реализованные на JavaScript/XML. Компилированные компьютерные сценарии и/или моделеры по технологиям сторонних производителей, либо соответствующие автономные контентно-программные продукты целиком.




  • Качество мультимедиа компонентов

В значительной части квалиметрия мультимедиа компонентов, определяемая гармонией, эстетикой, эргономикой, относится к области экспертных оценок. Тем не менее, можно выделить параметры, которые однозначно отрицательно влияют на качество компонентов как при создании, так и при последующей обработке. Существуют также рекомендации, следование которым в общем случае способствует созданию высококачественных электронных учебных материалов. Рассмотрим их по видам мультимедиа компонентов.

Для символьной информации недопустимы грамматические и орфографические ошибки, нарушения правил пунктуации, стилистические погрешности. Рекомендуется выбирать шрифты после тщательного анализа, особенно важного при разработке кроссплатформенных электронных учебных модулей.



Статический визуальный ряд характеризуется широким спектром требований к изображениям, полученным из разнообразных источников и имеющим разное назначение в контенте ЭУМ. Большую роль при этом играют плохо формализуемые художественные критерии, поэтому для мультимедиа компонентов этого вида разумно обозначить лишь неприемлемые варианты.

Недопустимы следующие дефекты:



  • искажение геометрии;

  • низкая четкость (потеря важных деталей изображения);

  • недосвеченность или пересвеченность фотоизображений;

  • посторонние цветные точки (цифровой шум), возникающие при недостаточной освещенности в цифровой фотосъемке;

  • нарушение цветового баланса, искажение цвета;

  • артефакты – посторонние детали, возникающие на изображении при чрезмерной компрессии;

  • муар, растровая сетка, кольца Ньютона (концентрические элементы), возникающие в результате некачественного сканирования полиграфических материалов.

Динамический визуальный ряд отличается разнообразием форм: реалистический, синтезированный (в том числе – трехмерный) визуальный ряд может использоваться в медиакомбинациях со звуком, а также составлять отдельную 3D-композицию.

Недопустимы следующие дефекты:



  • выпадение строк и срыв синхронизации;

  • черные и сбойные полосы по периметру изображения;

  • низкая четкость (потеря важных деталей изображения);

  • рывки в динамике движения (результат изменения частоты кадров исходного видео);

  • зубчатость границ деталей изображения (результат ошибок при изменении размера кадра);

  • недосвеченность или пересвеченность;

  • нарушение границ («смазы») цветовых переходов;

  • нарушение цветового баланса, искажение цвета;

  • недостаточная или чрезмерная цветовая насыщенность;

  • цифровой шум;

  • артефакты компрессии.

Если динамический визуальный ряд реализован в медиакомбинации со звуковым, недопустимо несовпадение звука с изображением.

Общей рекомендацией является использование частоты воспроизведения 25 кадров в секунду. Снижение частоты воспроизведения допускается только при малой динамике отображаемых событий. Кроме того, для 2D/3D синтезированного визуального ряда рекомендуется:



  • при выборе размера кадра руководствоваться смысловым содержанием, во избежание «мигания» использовать не менее трех промежуточных состояний;

  • при намеренном использовании режима мигания элементов частоту задавать в пределах 1-3 Гц;

  • тщательно контролировать качество текстур для 3D изображений.

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

В звуковых фрагментах ЭУМ недопустимыми являются следующие дефекты:



  • фоновый шум, гул, реверберация, скрипы и стуки, щелчки и другие посторонние звуки;

  • эффект «перегрузки» сигнала (clip) в результате ошибок обработки или записи;

  • неравномерный спектр – преобладание низких или высоких частот в конечной записи;

  • прямые дефекты дикторской речи (картавость, шепелявость, заикание и т.п.);

  • слишком широкий динамический диапазон – большая разность уровней громкости между тихим и громким фрагментами речи.

Общие рекомендации заключаются в следующем:

  • необходимо применять нормализацию – выравнивать уровень громкости всех звуковых фрагментов модуля;

  • предпочтительно использование единого формата сжатия;

  • предпочтительно использование исходных фонограмм в цифровом виде;

  • при оцифровке звукового фрагмента с аналогового носителя должна применяться прямая коммутация, рекомендуемый пиковый уровень записи от -6dB до -3dB.

  • Результирующие данные

Под результирующими данными электронного учебного модуля понимается набор параметров, отражающих результаты работы пользователя с ЭУМ. Все результирующие данные, генерируемые в процессе воспроизведения модулей, должны иметь одинаковый смысл и вписываться в определенные для всех ЭУМ рамки. Таким образом, необходимо унифицировать перечень и диапазон значений параметров, отражающих результаты работы с электронными учебными модулями.

В основу унификации положена спецификация SCORM 2004. Раздел спецификации, регулирующий вопросы интерпретации результатов работы учащегося, называется SCORM Run-Time Environment (SCORM RTE). Основными компонентами SCORM RTE являются Data Model (модель данных) и Application Program Interface (API, прикладной интерфейс программирования).

SCORM RTE API – это интерфейс, обеспечивающий двусторонний обмен данными между внешними системами и ЭУМ. Обмен между ЭУМ и ОМС-плеером реализован через глобальный объект «API_1484_11»:

Пример

Фрагмент scenario ЭУМ




Модель данных SCORM RTE основана на стандарте образовательных технологий IEEE 1484.11.1, определяющем набор элементов для обмена информацией следующего характера:



  • об учащемся;

  • конечная цель изучения ЭУМ;

  • операции, проведенные с контентом ЭУМ;

  • степень успешности;

  • степень завершения.

Для обмена информацией между ЭУМ и внешними системами из модели данных SCORM RTE отобрано 13 элементов, представленных в таблице 4.3.

Таблица 4.3.



Элементы модели данных SCORM RTE, используемые в ЭУМ

N

п/п

Идентификатор

Смысловое определение

Режим использования



cmi._version

Версия модели данных

чтение



cmi.completion_status

Статус завершения

чтение/запись



cmi.completion_threshold

Порог завершения

чтение



cmi.exit

Статус выхода

запись



cmi.learner_id

Идентификатор учащегося

чтение



cmi.learner_name

Имя учащегося

чтение



cmi.max_time_allowed

Максимально допустимое время

чтение



cmi.progress_measure

Мера прогресса

чтение/запись



cmi.session_time

Время сеанса

запись



cmi.success_status

Статус успешности

чтение/запись



cmi.time_limit_action

Действия по истечении лимита времени

чтение



cmi.total_time

Общее время

чтение



cmi.score.scaled

Оценка

чтение/запись


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   ...   21


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал