5.4. Методы повышения валидации и доверия к модели

Существует шесть классов методов повышения валидации и прав­доподобия имитационной модели:

1. сбор высококачественной информации и данных о системе;

2. регулярное взаимодействие с менеджером;

3. документальная поддержка предположений и структурированный критический анализ;

4. валидация компонентов модели количественными методами;

5. валидация выходных данных всей имитационной модели;

6. анимация.

Рассмотрим отдельные из этих методов более подробно.

Сбор высококачественной информации и данных о системе

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

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

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

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

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

• разработчикам моделей необходимо убедиться, что требования к данным (тип, формат, количество, указание, зачем нужны эти данные, и т. д.) точно заданы лицам, которые должны их предоставить;

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

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

Результаты, полученные в ходе моделирования подобных систем. Если разрабатывается имитационная модель, подобные которой создавались уже много раз (допустим, модель наземных боев), следует отыскать результаты изуче­ния подобных систем посредством имитационного моделирования и по возмож­ности их применить.

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

Регулярное взаимодействие с менеджером

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

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

2. Сотрудничество разработчика с менеджером поддерживает у менеджера инте­рес к проекту и ощущение сопричастности к нему.

3. Знание менеджером системы способствует созданию модели, полностью аде­кватной системе.

4. Модель будет более правдоподобной, когда менеджер понимает и поддержи­вает допущения, принятые в модели. Действительно, очень важно согласовать принятые в модели ключевые допущения с менеджером (и другими специали­стами). Таким образом, можно заставить его поверить, что разрабатываемая модель будет подходящей, поскольку он сам помог в ее разработке.

Документальная поддержка предположений и структурированный критический анализ

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

• обзорный раздел, в котором сформулированы общие цели проекта, конкрет­ные проблемы, которые будут рассматриваться при изучении системы по­средством моделирования, и рабочие показатели для вычислений;

• подробное описание каждой подсистемы в предварительном формате и опи­сание взаимодействия этих систем (предварительный формат, как на этой странице, облегчает просмотр документа о допущениях и структурный раз­бор концептуальной модели, который будет описан далее);

• какие упрощения были сделаны и почему (помните, что имитационная мо­дель, как предполагается, является упрощением или абстракцией действи­тельности);

• краткое изложение данных, таких как выборочное среднее значение и гис­тограмма набора данных; действительное распределение вероятностей, ко­торое лучше всего подходит к набору данных, или другие тех­нические сведения (их лучше поместить в приложении к отчету);

• источники важной или противоречивой информации.

При составлении отчета надо помнить о том, что он должен быть понятен ме­неджерам.

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

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

Лучше всего проводить структурный разбор в каком-либо удаленном от рабо­чих мест всех участников помещении (например, в зале для встреч гостиницы), чтобы присутствующие могли полностью посвятить свое внимание совещанию. Кроме того, его нужно организовать до начала программирования, если главные проблемы раскрываются на встрече. Документ о допущениях следует разослать участникам перед совещанием, и от них должны быть получены комментарии. Однако эти действия нельзя считать заменой структурированного критического анализа, поскольку людям может не хватить времени или мотивации для тщатель­ного самостоятельного изучения документа.

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

Валидация компонентов модели и выходных данных всей имитационной модели количественными методами

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

О роли анимации в имитационном моделировании речь шла в разделе 5.3 (см. пример 5.6).