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

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

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

Подход 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, используя принятые в ней обозначения:

 

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

 

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

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

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

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

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

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

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