Мультимедиа в образовании: контекст информатизации (стр. 20 )

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

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

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

·  На втором этапе в разработку включается вся команда. Основным руководящим документом при этом является компонентный сценарий. Детализируется структура и содержание разделов продукта, вырабатываются основные идеи по методам представления предметной области в интерактивной мультимедиа среде. Описываются функциональные возможности продукта и действия пользователя. Детализируется структура интерфейсов («экран за экраном», «сцена с мизансценами» и другие способы описаний). Намечаются основные связи между цифровыми объектами и структура нелинейной навигации.

В соответствии с компонентным сценарием создаются все необходимые мультимедиа компоненты и моделирующие программы. Параллельно начинается работа над выходной документацией: инструкцией пользователя и методическими указаниями по применению продукта в учебном процессе.

·  Третий этап – сборка электронного продукта. Документальной основой этого этапа является рабочий сценарий. Рабочий сценарий в основном предназначен для программистов и их помощников. В нем детально описывается блок-схема продукта, уточняются все связи между цифровыми объектами в каждой сцене. Прописываются все элементы навигации, все возможные реакции на действия пользователя. Составляется перечень реализуемых сервисов (подсказки, справки, индивидуальные траектории и т. п.).

·  Четвертый этап посвящен подготовке к публикации (тиражированию на локальных носителях или установке на сетевой сервер). Прежде всего, это достаточно сложное и длительное тестирование и отладка. В процессе выходного тестирования анализируются как программные, так и содержательные компоненты продукта, а также проверяются все возможные связи, переходы и т. п. Устраняются все ошибки: дефекты программных модулей, технические и содержательные искажения аудиовизуальных компонентов и так далее, вплоть до опечаток в текстах.

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

·  Однако, завершение разработки не означает отделения продукта от создателей. Так же, как ребенок в течение всей жизни не расстается с родителями, электронное издание/ресурс требует сопровождения создателей. Это – пятый этап, этап жизненного цикла мультимедиа продукта.

Из теории программных систем известно, что в любой серьезной компьютерной программе всегда можно найти более или менее значительные ошибки. Содержание продукта нуждается в своевременном (неважно, частом или крайне редком) обновлении контента. Наконец, образовательные ЭИР должны соответствовать текущему уровню развития компьютерных технологий обучения. Все эти факторы определяют совокупность работ по сопровождению ЭИР. К ним добавляются еще заключения по результатам апробации, необходимой для всех новых образовательных продуктов (см. следующую главу).

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

Что касается сетевых продуктов, Internet решает вопросы связи с пользователями еще шире: возможен не только ответ на конкретный вопрос или учет замечаний, но и оперативное дополнение сопроводительной документации, а также быстрая модернизация контента.

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

Все было бы хорошо, если бы мы снимали кино. Там есть автор сценария, последовательность сцен с расписанными репликами, задача режиссера – творческая интерпретация. Понятно, что в творчестве не все так просто, иначе не было бы режиссеров гениальных и рядовых.

В случае интерактивной мультимедиа среды дело обстоит еще сложнее. Во-первых, нет и не может быть одного автора сценария – представить столь сложный проект способна только группа специалистов различных областей. Во-вторых, попытку переноса проекционных методов инженерной графики в область виртуальной реальности (три сценария) нельзя считать полностью удачной: интерактивная мультимедиа среда очевидно большей размерности. А человек многомерным мышлением попросту не обладает. В-третьих, многолетний опыт разработки мультимедиа продуктов приводит к убеждению, что это процесс в принципе рекурсивный. Действительно, имеется множество примеров, когда при сборке выясняется несовместимость (физическая, функциональная, художественная, эргономическая) мультимедиа компонентов. На практике это означает возврат к началу технологической цепочки, а зачастую – и существенные изменения в сценариях. Предусмотреть все заранее не удается по той же причине трехмерности (в лучшем случае) нашего мышления.

Попытка ухода от перечисленных проблем породила несколько иную схему разработки мультимедиа продуктов. В зарубежной литературе ее называют «схемой спирали». По существу, речь идет об итерационном процессе, только в математике итерации обычно приводят в точку (решения), а в данном случае, наоборот, расширяют мультимедиа среду.

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

Анализ прототипа дает исходные данные для следующего витка разработки. На каждом витке спирали продукт расширяется по объему, функциям, возможностям. Параллельно совершенствуются сценарные проработки, которые выполняют теперь экстраполяционные функции: на основе анализа накопленного материала формулируется предписание на шаг (виток) вперед.

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

Оглавление

Глава 4. Качество электронных образовательных продуктов

4.1. Подходы к оценке качества

Слово «качество» знакомо каждому человеку. Однако, именно широкое использование этого термина в обыденной жизни, наша уверенность в самостоятельной оценке товара, продукта, услуги при ближайшем рассмотрении оказывается недостаточно обоснованной. Выясняется, что претендовать на объективность (например, в споре с производителем) можно при выполнении, как минимум, двух условий: необходимо отчетливо представлять технологию анализа качества и иметь вполне конкретные критерии оценки на каждом этапе.

Очевидно, что технология и критерии оценки значительно зависят от предмета изучения. Нас интересует предметная область, лучше всего характеризуемая английским термином software. Важно разделить «software» на программные и содержательные (контентные) продукты. Последние, разумеется, функционируют на компьютере под управлением некоторого программного модуля (СУБД, программы-реализатора ЭИР и т. д.), но их главная функциональная нагрузка – представление пользователю содержания некоторой предметной области, в отличие, скажем, от управления (драйвер), или проектирования (САПР) некоего устройства, моделирования объекта или процесса (моделирующие программы).

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

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