Moodle, как платформа организации eLearning и дистанционного обучения

в 20:21, , рубрики: elearning, moodle, дистанционное образование, дистанционное обучение, метки: , , ,

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

  • Репетиторы и преподаватели, привыкшие к классно-урочной системе, чаще всего имеют в виду вебинары — им хочется просто делать то же самое, что они привыкли, только через интернет.
  • Издатели учебников и преподаватели, не планирующие покидать offline, обычно грезят об электронных учебниках для самостоятельного обучения учеников или для демонстрации на очных уроках.
  • Руководители небольших ВУЗов иногда воображают «магический черный ящик», куда можно загрузить учеников первого курса и вспомнить о них на выдаче диплома. Желательно, чтобы в «ящике» уже «лежали» все учебные материалы и алгоритмы по их применению.
  • В более крупных ВУЗах чаще нуждаются в централизованной системе тестирования, сбора и рецензирования письменных работ с автоматической проверкой их на плагиат.
  • Иногда eLearning представляют «серебряной пулей» решающей все проблемы ВУЗа. Стоит внедрить «eLearning» и всё сразу станет как надо: появятся учебные программы и сами-собой сертифицируются по образовательным стандартам третьего поколения, внедрится болонская система и модульное обучение, откуда-ни-возьмись вырастет ветвистое дерево компетенций, на котором зацветут привязанные к ним учебные материалы и творческие задания, преподаватели перестанут брать взятки, помолодеют и осовременятся, ученики перестанут «сдавать» и начнут «изучать». Достаточно выбрать правильный «eLearning» в красивой коробочке, купить и нажать кнопочку «Установить», а лучше попросить студента «за зачет» бесплатно скачать в интернете и поставить на старенькой машине с Windows 98 в лаборатории.
  • К сожалению, довольно распространена категория заказчиков, которым выделили деньги на eLearning и им нужно их потратить как-нибудь. Как ни странно, для IT-шника это одна из самых проблемных категорий, так как они часто исходят не из целесообразности, а из своих представлений о солидности и престижности тех или иных технологий и терминов.
  • Владельцы языковых школ хотят систему биллинга, учета и контроля видеоконференций, интегрированную с системами оплаты. Нечто, похожее на агентства-таксопарки, только с учителями в видеоконференции вместо таксистов.
  • Кадровые службы нуждаются в инструменте хранения истории повышения квалификации и организации дистанционного обучения и аттестации без отрыва от производства.
  • Новое веяние — электронные журналы и дневники, добровольно-принудительно внедряемые во всех школах, в лице нескольких продуктов-фаворитов, продвигаемых коммерческими компаниями или региональными госучреждениями, обычно — центрами при департаментах образовани. Объединены одной общей чертой: организованы на подобии сервисов сдачи налоговой отчетности online — заполняются вручную, без связи с обучением, в параллель к бумажным журналам. То есть бумажный журнал online, иногда erp/crm (распределение ресурсов, коммуникация с «клиентом»), но образовательной функции либо совсем нет, либо она не пригодна к применению.
  • Существуют и гораздо более экзотические варианты, включающие обучение в виртуальных вселенных, работу с виртуальными моделями и лабораториями и др.


В действительности, понятие eLearning шире всего перечисленного — это прежде всего новая модель учебного процесса, а не просто перенос в online привычных практик, вместе с отсканированными методичками, набитыми на скорую руку тестами и добавлением функции интернет-магазина.
С точки зрения IT, eLearning это прежде всего инфраструктура, обеспечивающая базовые и дополнительные сервисы:

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

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

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

Этим требованиям в полной мере соответствует Moodle — Модульная Объектно-Ориентированная Дистанционная Учебная Среда. Сравнение Moodle с закрытыми и открытыми аналогами не является темой данной статьи. Скажу лишь относительно внутренней или заказной разработки: приберегите эти ресурсы для действительно специфических задач, таких как разработка хороших учебных ресурсов, симуляций, а также разработку или кастомизацию системы управления учебным процессом. Изобретая собственный велосипед вы всё-равно не догоните команду разработчиков, работающую с 2002 года на полный рабочий день: ядро команды разработчиков свободного ПО Moodle являются штатными сотрудниками фонда Moodle в Австралии, который финансируется региональными партнерами и грантами.

Moodle хорош именно как интеграционная платформа: достаточно стабилен, если не ставить экспериментальные версии (больше 60 тысяч инсталляций выявляют большинство проблем раньше, чем вы их заметите), масштабируем (имеются инсталляции более чем с 1 миллионом пользователей), а модульность и поддержка открытых протоколов интеграции с самого начала были приоритетом разработчиков. Помимо этого, в нём на достаточно высоком уровне реализована поддержка всех типов учебной активности, которую можно было реализовать на используемых технологиях. К сожалению, вебинары требуют сервера потокового вещания, который на LAMP-хостинге не живёт, но большинство открытых или коммерческих продуктов этой категории уже имеют готовые модули интеграции в Moodle.

Процесс установки максимально автоматизирован: пошаговый мастер выполняет большую часть работы, от диагностики сервера до создания структуры базы данных. Главное не в пасть в заблуждение — лучше эту работу выполнять опытному веб-мастеру, понимающему, как устроен Internet, как работает Apache, как управлять правами доступа в Linux, что такое Cron, как ходит почта из веб-приложения и как уменьшить вероятность её попадания в спам. Установить Moodle можно и без этого, в конце-концов, есть Денвер, вот только за дальнейшую судьбу такого внедрения и стабильность работы я бы не поручился. Если такого специалиста нет, дешевле и надёжнее привлечь стороннего, чем брать в штат и учить своего: на полный день работы по обслуживанию Moodle от одной системы не наберётся, а загруженность разнотипными задачами снижает качество и мотивацию.

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

  • Регистрация, обновление и удаление пользователей: кто и когда это будет делать, чем обеспечена достоверность и актуальность данных, удалять или не удалять выпускников и академщиков, как избежать замусоривание реестра пользователей, если данные вносятся в несколько систем — какая из них будет первичной и каков будет механизм интеграции.
  • Назначение и отмена полномочий, в том числе подписка и отписка от курсов: проблемы примерно те же, что и при регистрации. Важно иметь продуманную политику безопасности, и четко ей следовать, в её отсутствие проявляются тенденции к неуправляемому накоплению и расширению полномочий всеми пользователями, в конце-концов все пользователи будут администраторами и вы свою систему не узнаете. Особенно трудно с этим бороться, если полномочий требует высшее руководство. Попробуйте переименовать роль администратора в «мойщика полов в серверой», а администратором назовите роль с правами просмотра и редактирования контента, возможно списка пользователей, но без прав настройки системы и ролей.
  • Наполнение учебными материалами — важнейший вопрос, от которого зависит, будет ли существовать eLearning у вас или это будет просто продвинутая коммуникационная платформа. Об этом процессе нужно знать три вещи: это очень сложно, очень дорого и очень долго. Это нужно понять, смириться и действовать в соответствии с этим. Не бывает бесплатного наполнения контентом. Хорошие учебные материалы, на которые можно смотреть без слёз, не пишутся на энтузиазме, в библиотечный день и т.п. Максимум, преподаватели выложат отсканированные методички с плагиатом из чужих книг и ссылки на википедию. Контент нужно либо покупать, за «живые деньги», не факт, что он будет качественным и будет подходить, зато это быстро. Либо организовывать процесс его разработки, который, как в книгоиздании, помимо авторов предполагает привлечение корректоров, стилистических и научных редакторов, иллюстраторов. Разработка мультимедийного контента требует тех же специалистов, что и съемка фильма или разработка видеоигры. Страшно? Вот почему все так любят вебинары — засунул «говорящую голову профессора Доуэля» в монитор и вот уже «eLearning» готов.
  • Регламенты коммуникации между участниками: какие работы должны сдаваться через систему, когда преподаватель должен их проверить, должен ли написать рецензию и что она должна в себя включать. В какой форме преподаватели консультируют студентов в системе, как скоро и насколько подробно должны отвечать. Это палочка-выручалочка, которая позволяет почти сразу же начать использование системы в учебном процесс, если денег на разработку или покупку учебных материалов нет. Долгострой опасен быстрым угасанием энтузиазма руководства, поэтому нужно стремиться, чтобы система становилась обязательной к использованию в каких-то аспектах как можно скорее.
  • Политики оценивания работ: шкалы, критерии, правила вычисления итогов, выгрузка оценок во внешние системы, их статус и использование (для самоконтроля, для сведения преподавателя, окончательная оценка).
  • Обучение разработчиков курсов и тьюторов работе с системой. Вводный инструктаж для студентов нужен, в основном, если контингент не умеет пользоваться хотя бы вКонтакте, но во-избежание претензий, хотя бы скринкаст или просто инструкцию со скриншотами лучше сделать.
  • Техническая поддержка пользователей. При большом их количестве лучше разделить на первую линию — ответы на типовые вопросы можно поручить любому лаборанту, и вторую линию, чаще всего, вопросы связанные с тонкостями работы Moodle и возможные ошибки, перенаправлять собственному или привлеченному эксперту по Moodle.
  • На обслуживании системы подробно останавливаться не буду, критерии и процедуры везде одинаковые — мониторинг, резервное копировани, своевременное обновление версий.

Если планируются собственные доработки, важно с самого начала поставить строгое условие — никаких правок в ядре, никаких патчей и хаков, только модули, работающие через API, предусмотренное разработчиками. Этим вы избавите себя от массы проблем, самая страшная из которых — потеря простоты обновления и совместимости с базовой версией, а как следствие, вынужденное принятие на поддержку собственными силами всего кода Moodle, а не только нескольких небольших плагинов.

P.S. В следующей статье, планирую написать обзор типов плагинов и открытых интерфейсов Moodle. Подробное описание процесса установки, на мой взгляд, не тема для аудитории Хабра, но если интересно — пишите.

Автор: alexdjachenko


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js