Поиск: 
Ресурсы Обсуждения События Сервисы Опросы Сообщество
RSS-лента мобильная
версия
 
Главная страница :: Статьи :: Моделирование предметной области электронного курса

Елена Локтева

Моделирование предметной области электронного курса

22 марта 2014 г.

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

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

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

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

Подход 2. Глаголы-существительные. Если предметная область новая, организация незнакомая, то необходимо провести предварительный сбор информации: интервью с сотрудниками, анализ документов, процессов и т.п. Анализируя собранную информацию, особое внимание уделяется существительным и глаголам. Существительные кандидаты на концептуальные классы модели, глаголы на связи между ними.

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

Описание кейса

В компанию «Пилюлькин-А»  новых сотрудников отбирает отдел рекрутинга. Руководитель отдела, в который попадает сотрудник, составляет план работ на испытательный срок и закрепляет за ним наставника из своего же отдела. Наставник помогает сотруднику адаптироваться во время испытательного срока, устраняет пробелы в знаниях, корректирует поведение. При этом за одним наставником, согласно стандартам компании, нельзя закреплять более 7 новичков.

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

Компания стремительно растет, новых сотрудников приходит все больше. Наставников тоже нужно все больше. Управление персоналом принимает решение о разработке электронного курса для подготовки наставников. Подразумевается, что курс будет опубликован  на корпоративном учебном портале. Разработкой курсов в компании занимается отдел обучения.

Для этого один из опытных наставников был выбран в качестве автора курса. Его задача подготовить материалы курса. Этот материал будет обработан и согласован сотрудниками управления персонала. Затем на основе материала разрабатывается сам электронный курс.

Шаг 1. Выделим основные бизнес-сущности

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

  • Отдел рекрутинга
  • Отдел обучения
  • Руководитель (отдела-нанимателя)
  • Наставник
  • Новичок
  • План на испытательный срок
  • Отчет новичка
  • Отчет наставника
  • Бонус наставнику
  • Учебный портал
  • Электронный курс

ВАЖНО! На этапе построения модели предметной области мы еще не приняли решения о том, в каком виде будет разработан электронный курс слайды, игры, серия вебинаров, коллекция видеороликов или что-то еще. Речь пока идет именно об анализе бизнес-ситуации, поиске и анализе проблем, выявлении бизнес-логики. Но не о конкретном решении!  

Шаг 2. Устанавливаем связи (ассоциации)

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

Запишем несколько примеров ассоциаций, которые существуют между выделенными нами сущностями:

  • Руководитель СОСТАВЛЯЕТ План на испытательный срок
  • Отдел обучения РАЗРАБАТЫВАЕТ Электронный курс
  • Новичок СОСТАВЛЯЕТ Отчет новичка
  • Руководитель ОПРЕДЕЛЯЕТ Бонус наставника

Заметьте, связи между сущностями представляют собой глаголы действия, которые можно легко найти в описании кейса. Разумеется, перечислить подобным образом все связи задача емкая. Особенно если учесть, что связей между двумя сущностями может быть больше, чем одна; например:

  • Руководитель НАЗНАЧАЕТ Наставник;
  • Руководитель ПРЕМИРУЕТ Наставник.

Шаг 3. Установить кратность ассоциаций

Кратность определяет, сколько экземпляров класса А со сколькими экземплярами класса Б может быть ассоциировано. Например:

Кратность

Описание

Примеры

*

0 или больше

 У Наставника может быть, а может и не быть обученных Новичков

1..*

Один или больше

У Электронного курса есть хотя бы один Учебный модуль

1..n

От 1 до n

У одного Наставника может быть одновременно от 1 до n Новичков на обучении

m

Ровно m

У Отдела-нанимателя ровно 1 руководитель

0..1

Ноль или один

У Новичка либо есть Наставник, либо нет

0..k

От 0 до k

Один Сотрудник может быть назначен не более, чем на k Электронных курсов

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

Шаг 4. Установить тип ассоциаций

Выделим следующие типы ассоциаций:

  • простая один класс находится на одном концептуальном уровне с другим классом, и ни один из них не является более важным; например, классы Решение руководителя и Бонус наставнику классы одного концептуального уровня;
  • обобщение один класс является частным случаем другого класса; например, мы могли бы выделить класс Сотрудник, расширениями которого являлись бы уже выделенные нами классы Руководитель отдела, Наставник и Новичок;
  • агрегация используется, чтобы показать, что один класс является частью другого класса; например, классы Руководитель, Наставник и Новичок являются частью класса Отдел-наниматель;
  • композиция более строгая агрегация; один класс является частью другого класса и не может существовать без него; например, между классами Учебный портал и Электронный курс может быть установлена ассоциация композиции: при удалении учебного портала все опубликованные на нем курсы перестанут существовать.

Шаг 5. Составить модель

Для составления модели используем диаграмму классов в нотации UML, используя принятые в ней обозначения:

Условные обозначения в нотации UML
 

В качестве инструмента моделирования я возьму бесплатное приложение draw.io, которое можно подключить к Google Disk.

Диаграмма концептуальных классов
 

Обратите внимание, как обозначаются на диаграмме ассоциации и их кратность.

Бывает, что связь на диаграмме получается неоднозначной. Например, на рисунке выше непонятно, кто перед кем отчитывается: руководитель перед отделом рекрутинга или наоборот? Для повышения читаемости можно в таких случаях добавлять стрелки, задающие направление чтения диаграммы.

Указание направления чтения диаграммы

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

  1. Наставник как правило, действующий сотрудник, у которого есть своя работа. Параллельно с работой он может обучаться на учебном портале компании (и не только на нем!). При этом он одновременно контролирует до 7 новичков. Есть вероятность, что все новички находятся на разных стадиях испытательного срока. Таким образом, будет правильно, если мы предложим ему в рамках курса несколько кейсов и упражнение по выстраиванию коммуникаций с новичками.
  2. При этом наставник может проходить обучение по другим электронным курсам на портале, на которые он подписался ранее. Это может повлиять на сроки, в течение которых он будет проходить обучение по разрабатываемому нами курсу. Отсюда может вырасти несколько возможных решений: короткие модули курса, выделение более длинного срока на изучение курса и т.п.
  3. Наставник должен уметь работать с планом испытательного срока, принятым в компании. Такие планы могут содержать как типовые мероприятия для всех сотрудников, так и индивидуальные (это, кстати, тоже стоило бы показать на диаграмме). Значит, необходимо обучить его контролю и оценке типовых мероприятий, а заодно дать несколько кейсов на возможные индивидуальные задачи. Другим решением по индивидуальным задачам может быть создание специальной темы на форуме по курсу, где можно будет приводить задачи и разбирать их с коллегами.
  4. Наставник также должен уметь составлять Отчет наставника и контролировать составление Отчета новичка. Значит, нам необходимо предложить ему задание с формой отчета и научить его заполнять этот отчет. Также будет смысл рассказать, какие типичные ошибки допускаются при заполнении отчетов, объяснить процедуру передачи отчета руководителю.

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

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

Таким образом, моделирование предметной области в ловких руках может стать хорошим подспорьем для разработчиков электронных курсов. Удачи и хороших проектов всем разработчикам курсов от авторов до «технарей»!




Комментарии
 

Цитатник

Всего 0 цитат из статьи и её обсуждения.
 

©  www.e-learning.by
: el-info (at) e-learning by Пишите письма!: el-info (at) e-learning by