検証と検証の非公式な方法

検証と検証の非公式な方法は、モデリングとシミュレーションで頻繁に使用されるものの一部です。これらは定量的よりも定性的なものであるため、非公式と呼ばれます。[1] 検証または検証の多くの方法は数値結果に依存しますが、非公式な方法は結論を引き出すために専門家の意見に依存する傾向があります。数値結果は主な焦点ではありませんが、数値結果が完全に無視されるという意味ではありません。非公式な方法が選択される理由はいくつかあります。場合によっては、非公式の方法を使用すると、モデルが検証できるかどうかを確認するための迅速なテストが便利になります。非公式な方法が単に利用可能な最善の選択肢である場合もあります。非公式な方法は正式な方法よりも効果が低いわけではなく、「正式な」方法に期待されるのと同じ規律と構造で実行される必要があります。適切に実行すれば、確かな結論を導き出すことができます。[2]

モデリングとシミュレーションでは、モデルの状態を分析するために検証手法が使用されます。検証は、実行可能モデルのさまざまな側面と概念モデルを比較することに重点を置いて、さまざまな方法で完了します。一方、検証方法は、概念的なモデルまたは実行可能なモデルを、モデル化しようとしている状況と比較する方法です。どちらもモデルを分析して、使用されているモデリング方法の欠陥や現実の状況の潜在的な誤った表現を見つけるのに役立つ方法です。

検査

検査は、概念モデルが実行可能モデルとどの程度正確に一致しているかを比較するために使用される検証方法です。専門家、開発者、テスターのチームは、元の概念モデルの内容 (アルゴリズム、プログラミング コード、ドキュメント、方程式) を徹底的にスキャンし、適切な対応モデルと比較して、実行可能モデルがどの程度一致しているかを検証します。[1] この検証方法の主な目的の 1 つは、本来の目的が何を見落とされているかを確認することです。モデルの検査チェックを行うことで、チームはどのような問題が見落とされているかを確認できるだけでなく、プロジェクトの後半で問題になる可能性のある潜在的な欠陥を発見することもできます。[3]

利用可能なリソースに応じて、検査チームのメンバーがモデル制作チームの一部である場合とそうでない場合があります。できれば別々のグループであることが望ましいですが、メンバーが同じグループに属している場合、グループのメンバーはすでに制作の観点からプロジェクトを見て時間を費やしているため、側面が見落とされる可能性があります。また、検査チームのメンバーには、司会者、リーダー、記録者などの特定の役割が割り当てられ、検査で使用される特定の手順ステップが割り当てられるため、検査はその場限りの場合も高度に構造化された場合もあるという点でより柔軟です。検査官の目標は、概念モデルと実行可能モデルの間の欠陥を見つけて文書化することです。[1] [4]

顔認証

Flickr - 公式米国海軍画像 - MQ-8B ファイア スカウト フライト シミュレーターをメディアにデモンストレーションする船員。

顔検証の利点の 1 つは、ユーザーとシミュレーションの間の対話が優先されるリアルタイムの仮想シミュレーション中に効果的に使用できることです。これらのタイプのモデルではユーザーからの入力または対話が必要なため、このタイプのシミュレーション中に効果的です。モデルが基準を満たしていることを検証する最良の方法は、実際にモデルの状況を経験したユーザーに、そのモデルがよく知っている状況を正確に表していることを確認してもらうことです。状況に詳しいユーザーは、開発者が気づいていない必要な修正に気づくでしょう。このタイプの検証は、仮想シミュレーションに効果的かつ最も適しており、テストのスケジュールが短期間に設定されている場合、または分析可能な定量的な結果を生み出すことが難しい場合にモデルを検証するためにも使用されます。定量的な結果が望ましいですが、専門家による確かな検証の説明も許容されます。[1]

顔認証の例

  • 制御入力に対するフライト シミュレーターの応答の精度は、経験豊富なパイロットにさまざまな操縦を通じてシミュレーターを飛行させることで評価できます。[1]
  • ユーザー入力に対するポーカー ボット シミュレーターの応答の精度を分析し、AI が論理的な方法で反応していることを検証します。[要出典]
  • 兵士に戦闘状況をシミュレートするモデルをテストしてもらいます。[要出典]

監査

監査は、モデルが設定されたガイドラインにどの程度適合しているかを確認するために使用されます。監査証跡が整備されている場合は、モデル内のエラーを元のソースまで追跡して、簡単に見つけて修正できるようにする必要があります。監査は会議によって実施され、監査証跡をたどって問題がないか確認されます。[5]

監査の例

監査の最も一般的な適用例は、国民が「監査される」場合に見られます。これは、説明したモデリングおよびシミュレーション方法に直接適用されるものではありませんが、プロセスを説明します。[要出典]

ウォークスルー

ウォークスルーとは、レビュー対象のモデルまたはドキュメントを担当する作成者とのスケジュールされた会議です。通常、著者に加えて、モデルの分析を支援する上級技術スタッフ、場合によってはビジネス スタッフのグループが存在します。通常、会議の進行を担当するファシリテーターもいます。公式会議の前に、作成者は文書またはモデルに表面的な誤りがないかレビューします。このレビューの後、それは会議の参加者に渡され、会議の前に矛盾がないか徹底的にレビューすることができます。聴衆は、システムに関する知識だけでなく、その分野の専門知識に基づいて、質問や懸念事項を集めます。会議では、著者が聴衆に文書を提示し、方法と調査結果を説明します。ファシリテーターはこの時点で聴衆からの質問を提示する責任があります。ファシリテーターは、会議の構成を主導することに加えて、後で再分析するために残っている問題をメモします。[3] [4]

ウォークスルーの例

  • 執筆された作品の著者は、出版のために提出する前に、座って内容を確認します。[要出典]
  • 最終製品が顧客の承認のために送信される前に製品をレビューするソフトウェア開発チーム。[要出典]

レビュー

レビューは、レビュー チームに経営陣も含まれる点を除けば、ウォークスルーまたは検査に似ています。レビューは、ガイドラインと仕様の範囲を含むモデルプロセス全体の概要であり、シミュレーション開発にすべてのコンセプト目標が含まれていることを管理者に保証することを目的としています。焦点は単なる技術的なレビューではないため、高度な手法とみなされます。ウォークスルー プロセスと同様に、レビュー プロセスでも会議の前に文書を提出する必要があります。[要出典]

重要なポイントは V&V エージェントを通じて強調表示されます。潜在的な問題と推奨事項は、レビューの結果として会議中に記録されます。これらの結果に基づいて、指摘事項に対処するための措置が取られ、不備が処理され、推奨事項が考慮されます。[4] [6]

デスクチェック

机上チェックでは、作成者がモデルを注意深くステップ実行して矛盾を見つけようとします。これは、検証の主な責任がモデルの作成者に課される唯一の手法です。作成者は、すべての元の文書、メモ、目標を徹底的に読み、完成した製品が意図したすべてのことを正確かつ完全にモデル化していることを確認しようとします。この時期は、不完全な点を見つけて修正する必要がある時期でもあります。責任は作者にありますが、それは他の人の助けが排除されるという意味ではありません。デスク チェックは、ここで説明した非公式な方法の中で最も形式的ではありませんが、多くの場合、エラーを検出し、モデルの検証と検証を試みる場合に優れた防御の第一線となります。[3] [7]

机上チェックの例

ソフトウェアを開発するプログラマーは誰でも、デスクチェックとして知られる非公式な検証方法に参加します。開発中のソフトウェアをデバッグすることは、机上チェックの一種です。開発者は、ブレークポイントを設定するか、モデルからの出力をチェックして、概念モデルで開発されたアルゴリズムと一致することを確認します。[要出典]

チューリングテスト

チューリングテストは、1950 年代に英国の数学者アラン チューリングによって開発された非公式の検証方法です。人間は、他の人間がどのように反応するかを分析できる「専門家」とみなされるため、その根幹は顔検証の特殊な形式です。与えられた状況で反応する。特に、このモデルは、人間の行動をモデル化しようとする状況のモデル化に最適です。この検証方法は、人間の意思決定に影響を与える要因や異なる人々の間の大きな差異を説明するために大量の計算を行うのではなく、出力データがどのソースから来たのかを知らない他の人間、つまり他の人間にモデルがどのように見えるかに焦点を当てています。 、またはモデル。チューリング テストは、出力が、モデル化されている状況における人間の行動の予想出力と一致するかどうかを比較することに基づいています。[1]

「人間の行動モデルの検証に適用すると、そのモデルはチューリング テストに合格するため、専門の観察者がモデルによって生成された行動と人間によって生成された行動を確実に区別できない場合には有効であると言われます。評価されるのは人間が生成した行動とどの程度区別できないかであるが、このテストは明らかにアルゴリズムによって生成された行動の現実性の評価に直接関連しており、おそらくチューリングが最初に提案した知能よりもさらに重要である。」[1]

参考文献

  1. ^ abcdefg ジョン・ソコロフスキー; バンクス、キャサリン。編集(2010)モデリングとシミュレーションの基礎: 理論的基礎と実践的領域。ワイリー。p. 340-345。ISBN  978-0-470-48674-0
  2. ^ オスマン、バルシ ; (1997)シミュレーション モデルの検証、検証、および認定1997 年冬季シミュレーション会議議事録
  3. ^ abc ジェラルド・D・エヴェレット、レイモンド・マクロード・ジュニア (2007)。ソフトウェア テスト: ソフトウェア開発ライフ サイクル全体にわたるテスト。ジョン・ワイリー・アンド・サンズ。p. 80-99。
  4. ^ abc リチャーズ、エイドリアン; ブランスタッド、マーサ。チェルヴニアスキー、ジョン。(2007)。コンピュータ ソフトウェアの検証、検証、テストに関するコンピューティング調査、Vol 14、No 2、1982 年 6 月
  5. ^ Perry, W.、ソフトウェア テストの効果的な方法、John Wiley & Sons、ニューヨーク州、1995 年。
  6. ^ 「検証と検証」. 国防総省。2012 年 9 月 5 日のオリジナルからアーカイブされました。
  7. ^ フネス、アナ; アリスティデス、ダッソ。編集(2007)。ソフトウェアエンジニアリングにおける検証、検証、テスト。イギ。p. 150~170。