Informal methods of validation and verification

Informal methods of validation and verification are some of the more frequently used in modeling and simulation. They are called informal because they are more qualitative than quantitative.^[1] While many methods of validation or verification rely on numerical results, informal methods tend to rely on the opinions of experts to draw a conclusion. While numerical results are not the primary focus, this does not mean that the numerical results are completely ignored. There are several reasons why an informal method might be chosen. In some cases, informal methods offer the convenience of quick testing to see if a model can be validated. In other instances, informal methods are simply the best available option. Informal methods are not less effective than formal methods and should be performed with the same discipline and structure that one would expect in "formal" methods. When executed properly, solid conclusions can be made.^[2]

In modeling and simulation, verification techniques are used to analyze the state of the model. Verification is completed by different methods with the focus of comparing different aspects of the executable model with the conceptual model. On the other hand, validation methods are the methods by which a model, either conceptual or executable is compared with the situation it is trying to model. Both are methods by which the model can be analyzed to help find defects in the modeling methods being used, or potential misrepresentations of the real-life situation.

Inspection[edit]

Inspection is a verification method that is used to compare how correctly the conceptual model matches the executable model. Teams of experts, developers, and testers will thoroughly scan the content (algorithms, programming code, documents, equations) in the original conceptual model and compare with the appropriate counterpart to verify how closely the executable model matches.^[1] One of the main purposes of this method of verification is to see what original goals have been overlooked. By doing an inspection check on the model, the team can not only see what issues might have been overlooked, but also catch any potential flaws that can become an issue later in the project.^[3]

Depending on the resources available, the members of the inspection team may or may not be part of the model production team. Preferably they would be separate groups, but when members are from the same group aspects may be overlooked since the group members have already spent time looking at the project from a production point of view. Inspections are also more flexible in that they may be ad hoc or highly structured, with members of an inspection team assigned specific roles such as moderator, reader, and recorder, and specific procedure steps used in the inspection. The inspectors' goal is to find and document flaws between the conceptual model and the executable model.^[1][4]

Face validation[edit]

One of the benefits of face validation is that it can effectively be used during a real-time virtual simulation where the interaction between the user and the simulation is of priority. It is effective during these type of simulations because these types of models require input or interaction from the user. The best way to validate that the model meets the criteria is by having users who have experienced the model situation in real life confirm that the model accurately represents the situation they are familiar with. Users who are familiar with the situation will notice necessary corrections that a developer may be unaware of. This type of validation is effective and most appropriate for virtual simulations and it is also used to validate models when there is a short timeframe scheduled for testing, or when it is difficult to produce quantitative results that can be analyzed. While quantitative results should be the preferred result, a solid account of validation from professionals is also acceptable.^[1]

Examples of face validation[edit]

• The accuracy of a flight simulator's response to control inputs can be evaluated by having an experienced pilot fly the simulator through a range of maneuvers.^[1]
• Analyzing the accuracy of a poker bot simulator's response to user input to verify that the A.I. is reacting in a logical manner. ^{[citation needed]}
• Having a soldier test a model that simulates a battle situation.^{[citation needed]}

Audit[edit]

An audit is used to establish how well a model matches the guidelines that are set in place. If an audit trail is in place, any error in the model should be able to be traced back to the original source to easily find and make corrections. An audit is conducted by meetings and following the audit trail to check for issues.^[5]

Examples of audit[edit]

The most common application of an audit can be seen when a citizen is "audited". While this does not have any direct application to the modeling and simulation methods discussed, it explains the process. ^{[citation needed]}

Walkthrough[edit]

A walkthrough is a scheduled meeting with the author in charge of the model or documents that are set to be reviewed. In addition to the authors, there is usually a group of senior technical staff and possibly business staff that help analyze the model. Typically, there is also a facilitator who is in charge of leading the meeting. Prior to the official meeting the author will review the document or model for any potential cosmetic errors. After this review it is passed on to the meeting audience so they may thoroughly review it for inconsistencies prior to the meeting. The audience will gather any questions or concerns based on their expertise in the field as well as their knowledge of the system. At the meeting, the author will present the document to the audience and explain the methods and findings. The facilitator is responsible for presenting questions from the audience at this time. In addition to leading the structure of the meeting, the facilitator takes notes of remaining issues to be reanalyzed later.^[3][4]

Examples of walkthrough[edit]

• Authors of a written work sitting down to review the content prior to submitting for publishing.^{[citation needed]}
• A software development team reviewing a product before the final product is sent for approval by the customer.^{[citation needed]}

Review[edit]

A review is similar to a walkthrough or inspection except review team also includes management. A review is an overview of the whole model process including coverage of the guidelines and specifications, with the goal to assure management that the simulation development includes all concept objectives. Because the focus is more than just a technical review, it is considered a high level method. Like the walkthrough process, the review process should have documents submitted prior to the meeting. ^{[citation needed]}

Key points are highlighted via the V&V Agent. Potential problems and recommendations are recorded during the meeting as a result of the review. With these results actions are taken to address the points made, deficiencies are handled, and recommendations are taken into consideration.^[4][6]

Desk checking[edit]

Desk checking consists of the author carefully stepping through the model in an attempt to catch any inconsistencies. It is the only technique where the main responsibility to verify is placed on the author of the model. The author thoroughly reads all original documents, notes, and goals and tries to verify that the completed product accurately and completely models everything that it set out to do. This is also the time when any incompleteness should be caught and corrected. While the responsibility does rest on the author, that does not mean the help of others is excluded. Desk checking is the least formal of the informal methods discussed, but is often a good first line of defense in catching errors, and attempting to verify and validate the model.^[3][7]

Examples of desk checking[edit]

Any programmer who develops software participates in the informal method of verification known as desk checking. Debugging software as it is being developed is a form of desk checking. The developer sets breakpoints or checks the output from the model to verify that it matches the algorithms developed in the conceptual model.^{[citation needed]}

Turing test[edit]

The Turing test is an informal validation method that was developed by the English mathematician Alan Turing in the 1950s, which at its roots is a specialized form of face validation because humans can be seen as "experts" on being able to analyze how other humans will respond in a given situation. Specifically, this model is best suited for modeling situations that attempt to model human behavior. Instead of trying to be heavily computational to account for the factors that affect human decision and the high variance between different people, this validation method focuses on how the model appears to other humans that are unaware of which source the output data comes from - other humans, or the model. The Turing test is based on comparing whether or not the output, at a rate more than chance, matches that which is the expected output for human behavior in the situation being modeled.^[1]

"When applied to the validation of human behavior models, the model is said to pass the Turing test and thus to be valid if expert observers cannot reliably distinguish between model-generated and human-generated behavior. Because the characteristic of the system-generated behavior being assessed is the degree to which it is indistinguishable from human-generated behavior, this test is clearly directly relevant to the assessment of the realism of algorithmically generated behavior, perhaps even more so than to intelligence as Turing originally proposed."^[1]

References[edit]