Неформальные методы (валидация и верификация) - Informal Methods (Validation and Verification)

^[1]Подробнее о валидации и верификации см. Верификация и валидация.

Неформальные методы валидации и верификации являются одними из наиболее часто используемых в моделировании и симуляции. Их называют неформальными, потому что они более качественные, чем количественные.^[2] В то время как многие методы валидации или верификации основаны на численных результатах, неформальные методы, как правило, полагаются на мнение экспертов, чтобы сделать вывод. Хотя числовые результаты не являются основным объектом внимания, это не означает, что численные результаты полностью игнорируются. Есть несколько причин, по которым можно выбрать неформальный метод. В некоторых случаях неформальные методы предлагают удобство быстрого тестирования, чтобы увидеть, можно ли проверить модель. В других случаях неформальные методы являются лучшим вариантом. Во всех случаях, однако, важно отметить, что неформальный подход не означает, что это менее верный метод тестирования. Эти методы должны выполняться с той же дисциплиной и структурой, которые можно ожидать от «формальных» методов. При таком исполнении можно делать твердые выводы.^[3]

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

Осмотр

Обзор

Инспекция - это метод проверки, который используется для сравнения того, насколько истинна концептуальная модель соответствует исполняемой модели. Команды экспертов, разработчиков и тестировщиков тщательно просканируют содержимое (алгоритмы, программный код, документы, уравнения) в исходной концептуальной модели и сравнят его с соответствующим аналогом, чтобы проверить, насколько точно соответствует исполняемая модель.^[2] Одна из основных целей этого метода проверки - увидеть, какие изначальные цели были упущены. Выполняя инспекционную проверку модели, команда может не только увидеть, какие проблемы могли быть упущены из виду, но также выявить любые потенциальные недостатки, которые могут стать проблемой позже в проекте.^[1]

В зависимости от имеющихся ресурсов члены инспекционной группы могут быть или не входить в состав группы по производству модели. Желательно, чтобы они были отдельными группами. Когда они принадлежат к одной группе, вы потенциально можете столкнуться с проблемами, когда что-то упускается из виду, поскольку член группы уже потратил время на изучение проекта с производственной точки зрения. Инспекции также являются более гибкими в том смысле, что они могут быть разовыми или сильно структурированными, с членами группы инспекторов, которым назначены определенные роли, такие как модератор, читатель и регистратор, а также определенные этапы процедуры, используемые при инспекции. Задача инспекторов - найти и задокументировать недостатки между концептуальной моделью и исполняемой моделью.^[2][4]

Примеры проверки

• Рассмотрим следующий пример из [Schach, 1996].

Команда, проверяющая дизайн моделирования, может включать модератора; диктофон; читатель из команды разработчиков симуляторов, который объяснит процесс проектирования и ответит на вопросы о конструкции; представитель Разработчика, который будет переводить дизайн в исполняемую форму; МСП, знакомые с требованиями приложения, и агент V&V.

· Обзор - группа моделирования моделирования готовит синопсис проекта. Эта и сопутствующая документация (например, определение проблемы и цели, требования к модели и модели, повестка дня проверки) распространяется среди всех членов группы проверки.

· Подготовка. Члены инспекционной группы индивидуально проверяют всю предоставленную документацию. Успех инспекции во многом зависит от добросовестности членов команды при их подготовке.

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

· Доработка - группа разработчиков решает каждую проблему, указанную в отчете, документируя все ответы и исправления.

· Дальнейшие действия - модератор гарантирует, что все ошибки и проблемы устранены удовлетворительно. Все изменения следует тщательно изучить, чтобы убедиться, что в результате исправления не возникло никаких новых проблем.^[5]

Подтверждение лица

Обзор

Flickr - официальные изображения ВМС США - моряки демонстрируют средствам массовой информации имитатор полета MQ-8B Fire Scout.

Одним из преимуществ проверки лиц является то, что ее можно эффективно использовать во время виртуального моделирования в реальном времени, когда взаимодействие между пользователем и моделированием является приоритетным. Это эффективно во время симуляций такого типа, потому что эти типы моделей требуют ввода / взаимодействия со стороны пользователя. Лучший способ подтвердить, что модель соответствует критериям, - это попросить пользователей, испытавших модельную ситуацию в реальной жизни, подтвердить, что модель точно отражает ситуацию, с которой они знакомы. Пользователи, знакомые с ситуацией, заметят необходимые исправления, о существовании которых разработчик мог и не догадываться. Хотя этот тип проверки является эффективным и наиболее подходящим для виртуального моделирования, он также используется для проверки моделей, когда на тестирование отводится мало времени, или когда трудно получить количественные результаты, которые можно проанализировать. В то время как количественные результаты должны быть предпочтительным результатом, также приемлемы и надежные подтверждения профессионалов.^[2]

Примеры проверки лица

• Точность реакции имитатора полета на управляющие воздействия можно оценить, если опытный пилот выполнит на имитаторе ряд маневров.^[2]
• Анализ точности реакции симулятора покерного бота на ввод данных пользователем для проверки того, что A.I. реагирует логично.
• Поручить солдату протестировать модель, имитирующую боевую ситуацию.

Аудит

Обзор

Аудит - это метод проверки, выполняемый на протяжении всего жизненного цикла разработки новой модели или симуляции или во время модификации унаследованных моделей и симуляций. Аудит - это кадровая функция, которая служит «глазами и ушами руководства». Аудит используется для определения того, насколько модель соответствует установленным руководящим принципам. Если имеется контрольный журнал, любую ошибку в модели можно проследить до исходного источника, чтобы было легче найти и внести исправления. Аудит проводится собраниями и отслеживанием контрольного журнала для выявления проблем.^[6]

Примеры аудита

• Наиболее распространенное применение аудита можно увидеть, когда гражданин проходит «аудит». Хотя это не имеет прямого отношения к обсуждаемым методам моделирования и симуляции, оно объясняет обсуждаемый процесс.

Прохождение

Обзор

Пошаговые руководства - самый трудоемкий и самый формальный из неформальных методов. Хотя они требуют больше всего времени, они также являются наиболее эффективными при выявлении проблем с моделью. Пошаговое руководство - это запланированная встреча с автором / авторами, отвечающими за модель, или с документами, которые должны быть проверены. Помимо авторов, обычно есть группа старших технических и, возможно, бизнес-сотрудников, которые анализируют модель. Наконец, есть фасилитатор, который ведет собрание. Перед официальной встречей автор / авторы рассмотрят документ / модель на предмет возможных косметических ошибок. Когда это было проверено, оно передается аудитории собрания, чтобы у них была возможность тщательно изучить его на предмет несоответствий до собрания. Аудитория соберет любые вопросы или опасения, которые могут у них возникнуть, исходя из их опыта в данной области, а также их знания системы. На встрече автор представит документ аудитории, объясняя изложенные методы и выводы. Фасилитатор отвечает за ответы на вопросы аудитории и не представляет угрозы для них. Помимо руководства структурой встречи, фасилитатор записывает вопросы, которые еще остаются, чтобы их можно было распространить и повторно проанализировать позже.^[1][4]

Примеры прохождения

• Авторы статьи / книги просматривают контент перед отправкой в ​​публикацию.
• Группа разработчиков программного обеспечения проверяет продукт перед отправкой конечного продукта на утверждение заказчику.

Рассмотрение

Обзор

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

Индикаторы обзора:

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

Ключевые моменты выделяются агентом V&V. События встречи, включая потенциальные проблемы и рекомендации, записываются в результате проверки. На основании этих результатов принимаются меры для решения поставленных задач. Устранены недостатки и приняты во внимание рекомендации.^[4][7]

Проверка стола

Обзор

Несмотря на то, что это не лучший метод проверки и проверки, кабинетная проверка может быть полезной. Это единственный метод, при котором основная ответственность за проверку возлагается на автора модели. Лабораторная проверка заключается в том, что автор тщательно просматривает модель, пытаясь уловить любые несоответствия. Автор внимательно прочитает все исходные документы, примечания и цели и попытается убедиться, что готовый продукт точно и полностью смоделировал все, что он намеревался сделать. Это также время, когда необходимо выявлять и исправлять любую неполноту. Хотя ответственность лежит на авторе, это не означает, что обращение за помощью к другим экспертам исключено. Ясно, что кабинетная проверка является наименее формальным из обсуждаемых неформальных методов, но часто является хорошей первой линией защиты при обнаружении ошибок и попытках проверить и подтвердить модель.^[1][8]

Примеры кабинетной проверки

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

Тест Тьюринга

Обзор

В Тест Тьюринга - это неформальный метод проверки, разработанный английским математиком Аланом Тьюрингом в 1950-х годах, который по своей сути является специализированной формой проверки лица. Причина, по которой это подгруппа проверки лиц, состоит в том, что всех людей можно рассматривать как «экспертов» в том, что касается способности анализировать, как другие люди будут реагировать в данной ситуации. В частности, эта модель лучше всего подходит для моделирования ситуаций, в которых много попыток моделирования поведения человека. Можно видеть, что модель, которая так сильно полагается на такую ​​сложную тему, может вызвать проблемы. Вместо того, чтобы пытаться быть в значительной степени вычислительным для учета факторов, влияющих на человеческое решение и высокой дисперсии между разными людьми, этот метод проверки фокусируется на том, как модель выглядит для других людей, которые не знают, из какого источника поступают выходные данные - других людей. , или модель. Модель теста Тьюринга основана на сравнении того, совпадает ли результат с большей вероятностью с ожидаемым результатом поведения человека в моделируемой ситуации.^[2]

«Применительно к проверке моделей поведения человека считается, что модель проходит тест Тьюринга и, таким образом, является действительной, если наблюдатели-эксперты не могут надежно различить поведение, созданное моделью, и поведение, созданное человеком. Поскольку характеристика поведения, созданного системой будучи оцененным - это степень, в которой он неотличим от поведения, созданного человеком, этот тест явно имеет прямое отношение к оценке реализма алгоритмически генерируемого поведения, возможно, даже в большей степени, чем к интеллекту, как первоначально предлагал Тьюринг ».^[2]

Примеры теста Тьюринга

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

Рекомендации