Использование количественных методов для валидации

компонентов модели [2]

Каждый раз, когда возможна проверка валидности различных компонентов всей

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

примеры таких методов.

Если данные наблюдения имеют какое-либо теоретическое распределение

вероятностей (например, экспоненциальное или нормальное), то адекватность их

представления может быть оценена с помощью графика и критерия согласия.

Как обсуждается ниже, для построения модели важно использовать

соответствующие данные. Однако также важно и тщательно структурировать эти данные.

Например, для исследования нескольких наборов данных на однородность распределения

при их объединении можно использовать тест Крускала-Валиса на однородность

популяции. Если наборы данных однородны, то их можно объединить и объединенные

набор данных можно использовать для построения имитационной модели.

Пример 3. Рассмотрим производственную систему. Предположим для нее были

собраны данные об отказах и восстановлении системы после отказов для двух

«идентичных» машин одного производителя. Тем не менее, тест Крускала-Валиса

показал, что распределения этих двух наборов данных различны. Поэтому в

имитационной модели для этих машин были использованы разные законы

распределения.

5.4.5. Документирование концептуальной модели [2]

Основной причиной некорректных допущений в модели является ошибки при

проведении интервью. Документация концепций, допущений, алгоритмов и кратких

данных может уменьшить эту проблему, а так же увеличит надежность системы. Модель

(концептуальная) не должна быть точным описанием работы системы. Она должна

описывать работу системы относительно решаемых моделью задач. Это описание

является основной документацией модели. Оно должно быть понятным для аналитика,

эксперта в данной предметной области и технического директора. В концептуальную

модель должно входить следующее:

− Обзор обсуждаемых целей проекта, специфичных задач, решаемых

моделью, и основные критерии.

− Диаграммы операций и схема системы

− Подробное описание всех подсистемы (в виде списка для наглядности) и их

взаимодействия

− Какие упрощения были сделаны и почему

− Краткое описание входных данных модели (для того, чтобы упростить

чтение модели лицом, принимающим решение, технический анализ следует

поместить в приложение)

− Источники важных или спорных данных

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

имитационной программы (на шаге 4).

5.4.6. Структурированный просмотр концептуальной модели [3]

Как говорилось выше, аналитику необходимо собирать данные от разных экспертов.

Кроме того, эксперты обычно очень заняты своей непосредственной работой. Вследствие

чего они не уделяют требуемого внимания вопросам, поставленным аналитиком. В

результате существует большая вероятность того, что аналитик не получит полного и

корректного описания системы. Эффективным способом решения этих потенциальных

проблем является проведение структурированного просмотра концептуальной модели в

присутствие экспертов и лиц, принимающих решения. С помощью проектора аналитик

представляет концептуальную модель по пунктам. При этом аналитик не переходит к

следующему пункту, пока все присутствующие не убедятся в правильности данного

пункта на выбранном уровне детализации. Структурированный просмотр увеличивает и

валидность, и надежность имитационной модели. (Как уже говорилось выше, этот этап

называется валидацией концептуальной модели.)

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

(например, в конференц-зале отеля), так чтобы участники могли полностью

сосредоточиться на рассматриваемой проблеме. Более того, если во время просмотра не

были рассмотрены основные вопросы, то просмотр должен проводится до начала этапа

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

модели всем участникам просмотра с последующим получением их комментариев.

Однако, не предполагается, что это заменяет сам структурный просмотр, так как у

участников может не быть времени и стимулов самостоятельно тщательно просматривать

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

совещания.

Пример 4. Во время структурного просмотра транспортной системы, по мнению

экспертов, оказались неверными основные процентные соотношения,

предоставленные спонсорами. (Из-за удаленности главных офисов спонсоров и

экспертов, эксперты не могли присутствовать на организационном совещании по

проекту.) В результате для сбора данных о различных частях системы были выбраны

разные люди. Собранные данные были использованы для обновления

концептуальной модели. После чего второй просмотр был удачным.

Дата добавления: 2014-12-24