Рисунок 1.3. Пример карты операций
Игровой сценарий позволяет описать активный ресурс (АР). Активный ресурс представляет собой игрового «бота», способного изменять игровые ресурсы на основании заранее заданных правил поведения [14]. «Активный ресурс» используется для создания нестандартных игровых ситуаций.
«Активный ресурс» представляет собой автомат с конечным набором состояний [14]. В зависимости от поступающей команды, «активный ресурс» выполняет определённый набор действий, симулируя поведение исполнителя бизнес-процесса. Симуляция бизнес-процесса, выполняемого активным ресурсом, обеспечивается за счёт интерпретации автоматной модели (АМ), поступающей на вход [11, 14].
1.3 Обзор подходов в имитационном моделировании
1.3.1 Принципы продвижения времени
Процесс моделирования осуществляется путём изменения состояния имитационной модели с течением времени [15, 16]. Время можно разделить на несколько категорий:
1. Физическое время - время в реальной системе.
2. Модельное время - представление физического времени в модели.
3. Процессорное время - время выполнения программы-симулятора на компьютере. Если процессорное время синхронизируется с модельным, говорят о моделировании в реальном времени.
Ключевой задачей имитационной системы является продвижение системы из одного устойчивого состояния в другое [17]. Продвижение модели выполняется по определённым правилам, которые определяют, как состояние изменяется за шаг модельного времени.
В процессе продвижения времени в модели, игра проходит множество игровых циклов. Продвижение времени может быть реализовано следующими способами:
1) фиксированный шаг,
2) от события к событию.
В первом случае изменение состояния происходит через моделирование фиксированных шагов игрового времени [16, 17]. Имитационная система продвигает игровое время вперёд на размер «шага». При продвижении системы на один «шаг», в системе может возникнуть ряд событий, которые произошли в момент выполнения «шага». К концу шага, все события считаются сработавшими на конец «шага».
Во втором случае моделирование происходит до момента наступления следующего события [16, 17]. Сначала происходит расчёт времени наступления событий, затем происходит поиск события, время наступления которого является самым меньшим. После того, как это событие было найдено, система переходит в новое состояние - на момент времени наступления найденного события.
1.3.2 Обзор подходов к моделированию систем
В имитационном моделировании существует несколько подходов к моделированию систем в зависимости от типа объекта, на основании которого оно осуществляется. Существует 4 подхода к моделированию систем [17]:
1) событийно-ориентированное,
2) процессно-ориентированное,
3) объектно-ориентированное,
4) агенто-ориентированное.
Каждый подход имеет в основе какой-либо объект. Событийно-ориентированное моделирование моделирует систему относительно последовательности событий. Аналогично, в остальных подходах моделирование времени зависит от объекта, процесса или агента.
Для реализации имитационной системы необходимо выбрать один из подходов к моделированию систем, который будет использоваться в подсистеме проведения (табл. 1.1). Выбор подхода происходил на основании объекта, который будет вносить изменения в систему в процессе моделирования.
Таблица 1.1 Сравнительный анализ подходов в имитационном моделировании
|
Название подхода |
Ключевые характеристики |
|
|
Событийно-ориентированное |
· обеспечивает моделирование ситуаций, в которых необходимо генерировать поток событий, время наступления которых заранее неизвестно. |
|
|
Процессно-ориентированное |
· позволяет осуществить моделирование процессов, в которых время не является дискретным. |
|
|
Объектно-ориентированное |
· моделирует поведение объектов, · позволяет разрабатывать имитационные системы высокой сложности, · обеспечивает гибкость за счёт лёгкости изменения поведения объектов, · подходит для любой предметной области. |
|
|
Агенто-ориентированное |
· позволяет получить представление о принципах работы системы на основании поведения отдельных агентов. |
Для представленной системы был выбран агенто-ориентированный подход, так как он рекомендуется создателями AnyLogic для моделирования бизнес-процессов [15]. При использовании этого подхода исполнитель бизнес-процесса рассматривается в качестве игрового агента.
Агент представляет собой автономный объект, имеющий собственный набор правил поведения, согласно которым он функционирует в системе [18, 19]. Агентное моделирование подразумевает, что конечное состояние системы зависит от поведения агентов [15, 17, 19]. В процессе симуляции агенто-ориентированной модели, каждый из агентов способен изменить состояние системы.
При агентном моделировании имеет место управляющая система («контроллер») [16], которая управляет продвижением времени в имитационной системе (см. рис. 1.4). Управляющая система имеет собственные часы, обозначающие игровое время.
Рисунок 1.4. Взаимодействие агентов и управляющей системы
Продвижение времени осуществляется путём вызова метода продвижения времени у каждого из агентов, каждый из которых имеет свои часы [16]. В конце каждого шага времени управляющей системы, происходит синхронизация времени часов агентов и часов управляющей системы. Правила игрового агента, с помощью которых он влияет на состояние системы, запускаются в момент продвижения времени.
1.4 Вывод
На данный момент получаемый от подсистемы проектирования игровой сценарий не включает в себя информацию о временном аспекте бизнес-процессов и поведении его исполнителей. Для решения этой проблемы необходимо разработать новую схему игрового сценария на основании заранее выбранного бизнес-процесса. Кроме того, необходимо реализовать модуль интеграции с подсистемой проектирования для того, чтобы загружать из неё игровой сценарий.
Чтобы моделировать поведение исполнителей бизнес-процесса по новому сценарию, необходимо разработать имитационную систему с использованием агентного моделирования с фиксированным шагом игрового времени. В качестве игрового агента необходимо использовать модель «активного ресурса», разработанную в «СКДИ», которая представляет собой модель поведения исполнителя бизнес-процесса. Архитектура имитационной системы должна быть разработана с использованием «контроллера».
Глава 2. Проектирование подсистемы проведения
В этой главе представлено описание этапа проектирования подсистемы проведения, позволяющей исполнять игровой сценарий. В главу включены пункты, описывающие процесс создания игрового сценария на основании бизнес-процесса, проектирование архитектуры имитационной системы и демонстрационного приложения.
2.1. Описание бизнес-процесса
Было принято решение создать деловую игру на основании бизнес-процесса «Управление командой разработки ПО». Этот БП описывает процесс управления командой разработки ПО в IT организации.
Игрок выступает в роли менеджера команды. Игрок принимает управленческое решение - составить план итерации проекта и распределить задачи в команде. На рис. 2.1 показана IDEF0 диаграмма рассматриваемого бизнес-процесса. Остальные уровни детализации показаны в приложении A.
Рисунок 2.1. IDEF0 диаграмма бизнес-процесса «Управление командой разработки ПО»
Проектируемая деловая игра позволит игроку участвовать в процессе управления проектом. Игра будет симулировать бизнес-процесс «исполнение итерации проекта» (рис. 2.1), который выполняется проектной командой. Проектная команда состоит из: аналитиков, разработчиков, тестировщиков и менеджера команды. Исполнителей каждой категории (кроме менеджера, который является игроком) может быть множество.
Проектная команда работает по плану проекта, назначенным менеджером. Скорость и качество выполнения процесса будет зависеть от навыков сотрудника, которого менеджер включил в план итерации проекта. Таким образом, результаты симуляции БП «Исполнение итерации проекта» (рис 2.2) будут зависеть от выбора игрока.
Рисунок 2.2. Третий уровень декомпозиции БП «Управление командой разработки ПО». Процесс «Исполнение итерации проекта».
Представленный бизнес-процесс «Управление командой разработки ПО» будет использоваться для создания игрового сценария, а также в качестве демонстрационного примера в прототипе подсистемы проведения.
2.2. Проектирование игрового сценария
В этом пунке описывается процесс трансформации бизнес-процесса в игровой сценарий в соответствии с алгоритмами трансформации, разработанными в «СКДИ». Полученный игровой сценарий будет использоваться для создания деловой игры.
2.2.1 Трансформация бизнес-процесса
Для симуляции бизнес-процесса его необходимо трансформировать в игровой сценарий [11]. Подсистема проектирования производит трансформацию автоматически, но в данной работе процесс трансформации будет описан вручную, чтобы учесть временной аспект, который ещё не учитывается подсистемой проектирования. Трансформация БП в игровой сценарий состоит из нескольких этапов:
1) построение исходного бизнес-процесса,
2) трансформация в рабочий бизнес-процесс (РБП),
3) трансформация в унифицированный учебный БП (УУБП),
4) трансформация в карту операций,
5) построение ЛСА и заполнение базы данных.
Схему игрового сценария можно представить в виде рабочего бизнес-процесса (РБП) (рис. 2.3). Представленный рабочий бизнес-процесс позволяет описать алгоритм выполнения операций и бизнес-условия, способные изменить ход игры.
Рисунок 2.3. Рабочий БП «Управление командой разработки ПО»
Построенный РБП начинается с операции «выбрать план итерации проекта». Следующие три операции раскрывают БП «исполнение итерации проекта» (рис. 2.3). После этого в схему добавляется бизнес-условие, определяющее, осталось ли время на исполнение проекта. Бизнес-условие осуществляет проверку в конце каждой итерации. Игра завершается, когда время на исполнение проекта заканчивается.
В зависимости от того, как игрок установил план, игра моделирует исполнение задачи выбранным игроком сотрудником. Цикл повторяется до тех пор, пока время на исполнение проекта не закончится. После того, как завершится моделирование исполнения задач, игрок сможет увидеть результаты симуляции. Состояние и параметры задач изменятся.
Третий этап трансформации - в учебный унифицированный бизнес-процесс (УУБП). УУБП рассматриваемого бизнес-процесса представлен на рис. 2.4.
Рисунок 2.4. Алгоритм учебного унифицированного БП (УУБП) «Управление командой разработки ПО»
На этом этапе добавляется информация об исполнителях операций бизнес-процесса. Исполнители БП обозначаются как «активные ресурсы». На рис. 2.4 они обозначены как «АР», что значит «Активный ресурс».
Включение активных ресурсов, т.е. исполнителей бизнес-процесса, в УУБП позволит связать исполнителей бизнес-процесса с набором выполняемых им операции. Это также подготовит бизнес-процесс к следующей трансформации.
Четвертый этап трансформации - в карту операций. Карта операции является последним этапом трансформации перед формированием итогового сценария. Чтобы учесть аспект времени, в карту операций были добавлены следующие данные (рис. 2.5):
1) время выполнения операции,
2) затраты на исполнение операции,
3) код процесса,
4) код исполнителя бизнес-процесса.
Рисунок 2.5. Карта операций для БП «Управление командой разработки ПО»
Новые данные позволяют задать, сколько времени будет работать исполнитель, и какую часть бюджета будет тратить каждый из них. Код исполнителя бизнес-процесса позволит указывать не только тип исполнителя, но и его «экземпляр». В частности, это позволит закрепить несколько исполнителей одного типа (например, аналитиков) за разными операциями.
Каждый исполнитель бизнес-процесса в дальнейшем будет рассматриваться в качестве игрового агента. Агентное моделирование подразумевает, что игровые агенты изменяют игровые ресурсы с течением времени [15]. Так как в карту операций была включена информация о длительности операций и финансовых затратах, осуществляемых игровыми агентами, имитационная система будет иметь достаточно данных для симуляции бизнес-процесса.
2.2.2 Описание игрового сценария
Карта операций является неполным описанием игрового сценария. Чтобы полностью описать игровой сценарий, необходимо указать используемые в бизнес-процессе ресурсы и его исполнителей. На основании бизнес-процесса (см. рис. 2.1 - 2.2) и карты операций (см. рис. 2.5) был составлен список игровых ресурсов (табл. 2.1) и игровых агентов (экземпляров активных ресурсов) (табл. 2.2).