Data Verification and Validation (V&V) for New Simulations

Similar documents
Data Verification and Validation (V&V) for Legacy Simulations

What Is a Distributed Simulation (i.e., A Federation)?

Verification, Validation, and Accreditation of Army Models and Simulations

Modeling and Simulation Body of Knowledge (M&SBOK) - Index

10 Steps to Building an Architecture for Space Surveillance Projects. Eric A. Barnhart, M.S.

INFORMATION ASSURANCE DIRECTORATE

The Analysis and Proposed Modifications to ISO/IEC Software Engineering Software Quality Requirements and Evaluation Quality Requirements

BBK3253 Knowledge Management Prepared by Dr Khairul Anuar

Agile Accessibility. Presenters: Ensuring accessibility throughout the Agile development process

Advanced Security Tester Course Outline

The Accreditation and Verification Regulation - Verification report

High Level Architecture Federation Development and Execution Process (FEDEP) Model. Version 1.5

The descriptions of the elements and measures are based on Annex D of ISO/DIS Geographic information Data quality.

Business Analysis for Practitioners - Requirements Elicitation and Analysis (Domain 3)

LPD 17 PRA Testbed VV&A Database: A Disciplined Approach for VV&A. Vincent M. Ortiz AVW Technologies 9 March, 2006

STRATEGY ATIONAL. National Strategy. for Critical Infrastructure. Government

Standard Glossary of Terms used in Software Testing. Version 3.2. Foundation Extension - Usability Terms

INTERNATIONAL CIVIL AVIATION ORGANIZATION ASIA and PACIFIC OFFICE ASIA/PAC RECOMMENDED SECURITY CHECKLIST

The Modeling and Simulation Catalog for Discovery, Knowledge, and Reuse

DESIGN AND TECHNOLOGY

Cyber Security Incident Report

Higher National Unit specification: general information. Graded Unit 2

Shift Left: Putting the Process Into Action

Consultation questions

For presentation at the Fourth Software Engineering Institute (SEI) Software Architecture Technology User Network (SATURN) Workshop.

ISO/IEC INTERNATIONAL STANDARD

UNCLASSIFIED. FY 2016 Base FY 2016 OCO

SWEN 444 Human Centered Requirements and Design Project Breakdown

Sample Exam Syllabus

The Joint Live Virtual Constructive Data Translator Framework Interoperability for a Seamless Joint Training Environment

iii) Activity Definitions

19 March Assessment Policy for Qualifications and Part Qualifications on the Occupational Qualifications Sub-Framework (OQSF)

Computer Science and Software Engineering University of Wisconsin - Platteville 9-Software Testing, Verification and Validation

UNITED STATES OF AMERICA FEDERAL ENERGY REGULATORY COMMISSION NOTICE INVITING POST-TECHNICAL CONFERENCE COMMENTS. (June 3, 2016)

"Charting the Course... ITIL 2011 Managing Across the Lifecycle ( MALC ) Course Summary

Cybersecurity Testing

INFORMATION ASSURANCE DIRECTORATE

Rapid Bottleneck Identification A Better Way to do Load Testing. An Oracle White Paper June 2008

Reviewed by ADM(RS) in accordance with the Access to Information Act. Information UNCLASSIFIED.

DATA SHEET RSA NETWITNESS PLATFORM PROFESSIONAL SERVICES ACCELERATE TIME-TO-VALUE & MAXIMIZE ROI

The Accreditation and Verification Regulation - Sampling

ISTE SEAL OF ALIGNMENT REVIEW FINDINGS REPORT. Certiport IC3 Digital Literacy Certification

ISAO SO Product Outline

Report. Conceptual Framework for the DIAMONDS Project. SINTEF ICT Networked Systems and Services SINTEF A Unrestricted

ISO TC46/SC11 Archives/records management

DoD Strategy for Cyber Resilient Weapon Systems

Higher National Unit specification: general information. Graded Unit title: Computer Science: Graded Unit 2

Auditing in an Automated Environment: Appendix E: System Design, Development, and Maintenance

Testing! Prof. Leon Osterweil! CS 520/620! Spring 2013!

Diseño y Evaluación de Arquitecturas de Software. Architecture Based Design Method

Applying User Centered Design in the Development of Systems without User Interfaces

User Centered Design (UCD)

UPDM PLUGIN. version user guide

ASSURANCE CONTINUITY: CCRA REQUIREMENTS

Skill Category 6 - Summary Walkthroughs, Checkpoint Reviews and Inspections

The Success of the AMRAAM DBMS/DAS

Vocabulary-Driven Enterprise Architecture Development Guidelines for DoDAF AV-2: Design and Development of the Integrated Dictionary

ICAgile Learning Roadmap Agile Testing Track

9 March Assessment Policy for Qualifications and Part Qualifications on the Occupational Qualifications Sub-Framework (OQSF)

Strategy & Planning: Data Governance & Data Quality

Solutions Technology, Inc. (STI) Corporate Capability Brief

Bridge Course On Software Testing

GOVERNANCE, RISK MANAGEMENT AND COMPLIANCE TRENDS BY FCPAK ERIC KIMANI

CS SOFTWARE ENGINEERING QUESTION BANK SIXTEEN MARKS

for TOGAF Practitioners Hands-on training to deliver an Architecture Project using the TOGAF Architecture Development Method

Software Testing part II (white box) Lecturer: Giuseppe Santucci

Test and Evaluation Methodology and Principles for Cybersecurity

UPDM 2 PLUGIN. version user guide

2009 Winton. Simulation Models

2016 NCCA Standards Revisions Recap and Takeaways: What You Need to Know

Component-Based Software Engineering TIP

FDA 483 The Definitive Guide to Responding to FDA 483 and Warning Letters

DATA ITEM DESCRIPTION

ADVANCED AUDIT AND ASSURANCE

Avionics Cyber T&E Examples Testing Cyber Security Resilience to support Operations in the 3rd Offset Environment

Business Architecture Implementation Workshop

Higher National Unit specification: general information

UNDAF ACTION PLAN GUIDANCE NOTE. January 2010

Step: 9 Conduct Data Standardization

Accreditation Process. Trusted Digital Identity Framework February 2018, version 1.0

Topics in Software Testing

Audit of Information Technology Security: Roadmap Implementation

How AlienVault ICS SIEM Supports Compliance with CFATS

IBM Security AppScan Enterprise v9.0.1 Importing Issues from Third Party Scanners

The Bizarre Truth! Automating the Automation. Complicated & Confusing taxonomy of Model Based Testing approach A CONFORMIQ WHITEPAPER

Data Management & Test Scenarios Exercise

Course Information

APPLICATION PROCEDURES 17 May 2017

Improved Database Development using SQL Compare

Examination Questions Time allowed: 1 hour 15 minutes

Law Enforcement License Plate Readers: Lessons Learned in Policy and Practice

THE ESSENCE OF DATA GOVERNANCE ARTICLE

BPS Suite and the OCEG Capability Model. Mapping the OCEG Capability Model to the BPS Suite s product capability.

Module 3. Overview of TOGAF 9.1 Architecture Development Method (ADM)

Terms, Methodology, Preparation, Obstacles, and Pitfalls. Vulnerability Assessment Course

The requirements engineering process

ISTQB Advanced Level (CTAL)

Entergy Arkansas, Inc. Transition Plan Technical Conference #1

HITSP Standards Harmonization Process -- A report on progress

The IDN Variant TLD Program: Updated Program Plan 23 August 2012

Transcription:

Data Verification and Validation (V&V) for New Simulations RPG Special Topic 9/15/06 1 Table of Contents Introduction 1 Data V&V Activities During M&S Development 1 Determine M&S Requirements Phase 2 V&V Activity: Verify Requirements 3 Plan M&S Development Phase 3 V&V Activity: Develop V&V Plan 3 Develop Conceptual Model Phase 4 V&V Activity: Validate Conceptual Model 4 Develop M&S Design Phase 6 V&V Activity: Verify Design 7 Implement and Test Phase 8 V&V Activity: Verify Implementation 8 V&V Activity: Validate Results 9 Prepare M&S for Use Phase 10 References 10 External Links in this Document 11 RPG References in this Document 11 1 This document replaces the 8/15/01 version. It contains minor editorial and formatting changes. This document corresponds to the web version of the VV&A RPG Special Topic of the same name and date. It has been modified to make it suitable for printing.

RPG Special Topic 1 Introduction Data verification and validation (V&V) activities are performed to ensure that data are appropriate for use in a particular simulation for a specific application. Data verification is conducted to ensure that the data selected are the most appropriate for the application and are properly prepared for the model. Data validation is conducted to ensure that the data accurately represent of the real world to be simulated. In simulation, it is virtually impossible to separately evaluate the model being executed from the data used because it is the interaction of data and code that produces simulation results, making both responsible for simulation credibility. This interdependent relationship between a simulation and its associated data dictates that data V&V activities be considered part of the overall M&S verification, validation and accreditation (VV&A) process [VV&C Tiger Team; IEEE 1278.4, 1997]. However, because of the specialized nature of data V&V, and particularly because of the large varieties of data subject areas, subject matter experts (SMEs), in particular the data producers themselves, are frequently called upon to assist in the data V&V process. Example: A military simulation will typically involve instance data describing the simulated natural environment, man-made obstacles, weather, force structure, system characteristics, system performance, behavior, command and control, etc. Regardless of who conducts data V&V activities, they should work closely with the Developers and those performing M&S V&V activities. Data V&V Activities During M&S Development The following sections discuss data-related activities and issues that should come up during the development and V&V assessment of a new model or simulation (M&S). A visual depiction of typical data V&V activities, overlaid on the V&V process for new M&S development, is provided in the figure shown below. Although data-related activities are each shown and discussed in connection with specific M&S development phases and V&V activities, these associations merely mark an appropriate opportunity for the data activity to take place. The sheer magnitude and complexity of data needed by a simulation suggest that data-related activities frequently begin earlier than recorded here and continue into later development phases in an iterative fashion. The approach recommended in this document is to discuss specific data activities as early as possible

RPG Special Topic 2 (e.g., when sufficient information is available to perform the specific activity) rather than to tie data activities to specific themes. This approach is taken to emphasize the importance of early action on data V&V. Develop New M&S Refine Refine M&S M&S Rqmts Rqmts Plan Plan M&S M&S ment Development Develop Conceptual Model Model Develop Design Implement & Test Test Prepare Prepare M&S M&S for for Use Use Verify Verify Rqmts Rqmts Verify Required Data Verify Data Sources & Availability Verify Metadata Adequacy Validate Data Transform Methods Verify Initialized Data V&V Process Develop Develop V&V V&V Plan Plan Plan Data V&V Validate Validate Conceptual Model Model Verify Input Databases Verify Output Characterizations Develop Validation Data Verify Verify Design Design Verify Transformed Instance Data Verify Hardwired Data Verify Verify Implementation Validate Hardwired Data Verify Output Validate Validate Results Results Validate Data Adjudicate Errors Data V&V for New M&S Refine M&S Requirements Phase Data should be an important consideration early in the development of a model or simulation. Once the requirements of the application have been determined, the developer, user, and program manager should work together to establish the M&S environment by identifying constraints based on the simulation development, such as resource availability, timelines, etc. refining requirements, including identification and definition of the data needs of the simulation for the given application, such as the data subject areas, the needed level of fidelity, the types of data to be collected during execution of the simulation, etc. Data subject matter experts (SMEs) may be needed to help identify and define these data needs. Example: One method used to capture data needs of the simulation is to prepare a Characteristics and Performance (C&P) Specification. The C&P Specification is a technical document that provides a complete description of needed data, including a set of sample instance data, and can be used for validation of the conceptual model.

RPG Special Topic 3 Once the data needs have been identified and defined, the User should begin locating appropriate authoritative sources and collecting candidate data and metadata [VV&C Tiger Team, 1998; IEEE 1278.4, 1997]. Like the M&S requirements, data needs are subject to refinement and change as plans are finalized and the conceptual model is developed. V&V Activity: Verify Requirements Verify Required Data As part of requirements verification, data needs should be reviewed to determine if the specified input data (as described by metadata) will support the M&S concept if the output data will support the needs of the application The V&V Agent or appropriate SMEs should carefully review the required data to ensure they are sufficient to support the application. The review should determine if the appropriate data varieties and levels of aggregation, accuracy, fidelity, and data quality have been identified to address the needs of the application. This assessment should begin as early as possible to avoid difficulties with planning and development of the conceptual model. Plan M&S Development Phase Data should be a major consideration when planning an M&S development. The types and quantities of output data to be collected can impact the design and implementation of the simulation. Input data availability, quality, and appropriateness for the application impact both the timeline and the cost of the overall program. Candidate input data sources should be identified as early as possible (e.g., as soon as the required data have been defined). When suitable data exist, they should be evaluated with respect to their compatibility with the simulation and their appropriateness for the application. If appropriate data do not exist, development planning should include additional time and resources for developing new data and the subsequent impact on development program milestones. V&V Activity: Develop V&V Plan Data V&V activities should be carefully planned to complement the different M&S development phases and M&S V&V activities. Early detection of data problems (e.g., nonavailability, inappropriate fidelity) can have a large impact on the model design. During V&V planning, the V&V Agent should work closely with the Accreditation Agent

RPG Special Topic 4 to identify data-related assessment priorities and appropriate acceptability criteria. This work facilitates the selection of data V&V activities most suited for providing evidence to support the accreditation decision. Plan Data V&V Activities Data Verification. The affinity between model algorithms and their associated data should be of primary concern because of the direct impact such affinity has on simulation credibility; however, appropriateness and sufficiency of all data associated with the simulation -- reference, hard-wired, and instance -- should be considered in verification planning. Data Validation. Planning the data validation effort includes identifying appropriate validation activities and expected outcomes as well as identifying and evaluating appropriate validation to be used in the results validation. In addition, validation planning should address the impact of obtaining and evaluating validation data on development program timelines and resources. Develop Conceptual Model Phase The conceptual model serves as a vehicle for transforming requirements into functional and behavioral capabilities and provides a crucial traceability link between the M&S requirements and the design implementation. Many data selection decisions take place during the development of the conceptual model. As the conceptual model is being built, the Developer should identify what input instance data are needed for specific individual algorithms, functions, and behaviors which input data should be hard-wired instead of used dynamically what specific data are needed to support the desired levels of fidelity for the application what output instance data need to be collected to support the application Candidate data sources and databases for the input instance data and candidate sources for the hard-wired data. Once appropriate data have been found, their descriptions should be included in the conceptual model. V&V Activity: Validate Conceptual Model The conceptual model is validated to ensure that it adequately specifies both physical and behavioral aspects of the problem domain and appropriately traces operational requirements in the emerging design. Data availability and data appropriateness are key considerations during this phase because of their impact on model design. Several

RPG Special Topic 5 data-related tasks that can be done during this phase are described in the following paragraphs. Verify Data Sources and Availability As soon as data source candidates are identified, data source metadata should be reviewed to ensure the sources are authoritative, appropriate for the application, and able to provide the required data in a timely manner. Examples: The authoritative source for helicopter data may be different depending on whether the simulation will be used by the Army or the Navy. The authoritative source for tank data may be different depending on whether the simulation is to be used in an unclassified training exercise or in a classified, forceon-force combat analysis. Verify Adequacy of Metadata Once a data source has been verified (i.e., shown to be appropriate and available), the metadata should be reviewed to ensure that they provide the information needed to satisfactorily characterize the data for the given application (e.g., they should be reviewed for data currency and availability, quality assessment history, usage in similar applications, fidelity, and other quality characteristics). Verify Input Databases The input databases (i.e., aggregated sets of all the input instance data) should be reviewed to ensure that they are adequate and complete and mapped to the algorithms, models, or simulation components in which they are to be used to confirm that they are appropriate for the application. Example: For a combat simulation, the input databases should be checked to make sure that attrition data are available for all possible weapon system/target combinations used in the application, that terrain maps include all features specified in the application, that systems characteristics are available for all systems, etc. A sample input database might be generated to prove that the data producer can provide appropriate data in the proper formats and within the required timeline of the application. If data or data source problems are discovered, the User may need to decide whether to modify requirements (and adjust the conceptual model), use available data that are not totally appropriate (i.e., accept the risk of reduced credibility), or undertake a data production effort to fill the void. The earlier such a decision is made the better. Once

RPG Special Topic 6 the simulation is designed and built, changes to resolve data problems become much more costly and time-consuming. Verify Output Data Characterizations The algorithms and models identified for use in the simulation should be examined to ensure they can provide output data to support the needs of the application. This review should include data characterization (e.g., fidelity, format, completeness) as well as methods of collection and preparation. Example: For an application concerned with missile lethality, the missile fly-out model selected for use in the simulation should be able to produce outputs for probability of kill (Pk) values as well as the probabilities of detection, track, engage, and closest point of approach. Develop Validation Data Because results validation normally involves comparison of the results of a simulation to a referent (a codified body of knowledge about the thing being simulated based on M&S requirements), data describing the referent should be identified and collected or developed. Real-world empirical data are best (e.g., physical measurements, test range results, historical records) when available. However, when real-world data are not available, appropriate test scenarios should be developed and SMEs asked to provide reasonable, expected outcomes for the scenarios or use cases to be executed in the simulation [Rothenberg et al., 1997]. These validation data, both empirical and expected outcome, will be compared to the actual output instance data of the simulation during results validation. For more information on referents and results validation, see the special topic Validation. Develop M&S Design Phase During the design phase of the M&S development, the Developer uses information and relationships articulated in the conceptual model to determine how to implement them in code. Often this is done iteratively. The preliminary design allocates the requirements derived from the conceptual model in hardware and software configuration items. This design then evolves into a more detailed design that includes the allocation of requirements to software components, the identification of the specific data sets and elements to be used, and the definition of interfaces among components and external systems. Although data identification and selection processes should be initiated as early in the development process as possible (e.g., during conceptual model development), they

RPG Special Topic 7 can continue throughout this phase. Additional considerations focus on how to prepare the selected data for use. For hard-wired data, considerations include selecting an appropriate format (e.g., floating or integer) and degree of accuracy (e.g., should π (pi) be represented by 3.14, 3.1416 or 3.141592?) to meet the needs of the simulation and then documenting the rationale. For input instance data, a major concern is determining what form the data are available in, what form the model needs the data to be in, and the best way to make the transformations. In most situations, instance data will have to be transformed from their original state. Examples: Converting all rates of speed to kilometers per hour, all ranges to kilometers Converting the probabilities of acquisition, shot, hit, and kill into a single-shot kill probability Aggregating kills of individual classes of targets by individual classes of weapon systems over time into a overall kill probability Appropriate transformation techniques should be selected (or developed) and validated. For output instance data, a major concern is ensuring the design (i.e., algorithms, code, interfaces) can produce, collect, and store the desired output data. In many situations, output data have to be transformed (e.g., aggregated, combined) to produce usable results. Whether data collection occurs external to the model or not, appropriate transformation techniques should be selected (or developed) and validated during design to make sure that proper collection is possible. V&V Activity: Verify Design The focus of design verification is to ensure that all features, functions, behaviors, and interactions defined in the design can be traced back to the requirements expressed in the conceptual model and that all requirements expressed in the conceptual model are articulated in the design. The primary data-related V&V activities associated with design verification are described in the paragraphs below. Validate Data Transformation Methods The techniques used to prepare data for use are examined to ensure the data maintain their accuracy, fidelity, and integrity. Algorithms and techniques used to prepare each input instance database should be assessed to ensure that the transformation occurs correctly. Similarly, the methods used to collect and prepare output instance data, whether internal to the model or not, should be assessed to ensure that they can collect

RPG Special Topic 8 and transform data properly. Generally, this activity does not investigate the validity of the output instance data; rather, it focuses on the validity of what has been done to the data. Verify Transformed Input Instance Data This activity assures that transformed input instance data correspond to the original intent and are in appropriate form for use in the simulation. The producers of the original input instance data may serve as SMEs during this activity. Transformed output instance data should be traced to their origins to ensure they have been properly collected. Their characterizations should be verified to ensure that they provide appropriate, usable results. Verify Hard-wired Data Hard-wired data are considered separately because typically they are independent, single instances of data or fixed constants to be used in specific algorithms. They should be verified in conjunction with the algorithms in which they are placed. Specific tasks include ensuring that the data have been obtained from an authoritative source verifying that the data, when transformed into the form required for use in the simulation, are appropriate for their intended purpose ensuring that any deviations from the required data are corrected or at least documented Implement and Test Phase During this phase, the M&S design is realized in code using the actual hardware and data. The components or modules are built, tested, and integrated. The actual input instance data sets are initialized and tested. V&V Activity: Verify Implementation Requirements are traced to the implemented software components, individual algorithms and components are tested to ensure that they perform as designed, and data/code relationships are reviewed for appropriate operation. Verify Initialized Data The initialized data sets (i.e., the aggregated sets of transformed input instance data, in their initialized or start-up state) are checked to ensure that they continue to correspond

RPG Special Topic 9 to the original data, have been transformed as intended, and have maintained the accuracy, fidelity, and integrity required for the intended use. Validate Hard-Wired Data Hard-wired data are evaluated separately because they typically consist of individual fixed constants used in specific algorithms or formulas. They should be validated along with the algorithms into which they are placed. Hard-wired data can be checked by executing the associated individual algorithms to ensure that they execute properly and provide appropriate output when compared with validation data (i.e., the expected output). Any deviations should be assessed to determine the cause (i.e., statement or execution of the algorithm, hard-wired data, or validation data) and recommendations made to resolve the problem. Verify Output Data The code implementing individual algorithms and models should be examined to ensure that these algorithms and models provide output data to support the needs of the application. This review should include data characterization (e.g., fidelity, format, completeness) as well as methods of collection and preparation. Example: For an application concerned with missile lethality, the missile fly-out model used in the simulation should be executed and the output examined to ensure that it includes the necessary data categories (Pk, closest point of approach, etc.) and that the values produced for each category are accurate and usable. V&V Activity: Validate Results Results validation is conducted to determine the extent to which the simulation addresses the requirements of the application. Because the data and the simulation are inextricably intertwined (i.e., if one is not valid, then the validity of the other cannot be demonstrated), their validations are usually conducted in concert. It is perhaps better to think of the simulation as being calibrated - its performance observed, known, and understood within the range of data values under which it is intended to operate. This activity examines the extent to which the simulation, driven by valid input instance data, can provide appropriate responses when exercised in the context of the application. Beginning in the implementation phase, individual components or modules are executed to ensure appropriate performance and output. Additional testing is done as the components are integrated. Ultimately, the complete simulation is executed and the resulting data are compared to the validation data to determine if the simulation is producing credible, appropriate answers. Validate Data

RPG Special Topic 10 Also beginning in the M&S implementation phase, the impact of the input data on the performance of individual components and on the integrated simulation is assessed. For each model validation test, key data elements should be tracked to ensure appropriate output. Sensitivity excursions can be run to test boundary conditions on key data elements to assess the impact of data ranges on model output. Data validation can also be conducted incrementally. For example, the terrain database for a battle simulation can be validated before battle entities and objects are added. Data validation is performed to ensure that input data are appropriate for use in a particular simulation for a specific application. All data used to drive a model are subject to validation; however, the sheer quantity of data may make this impractical given cost and schedule constraints. Careful planning is needed to identify and prioritize key data components -- those data that most directly impact the performance of the model for the application. Adjudicate Errors Discrepancies between simulation outputs and the validation data are examined to determine probable cause. Errors can result from problems with the code, input data, output data, validation data, or a combination of any of these factors, and it is important to determine the cause. The divergent output should be retraced through the code, key algorithms, and input data. Sensitivity excursions may be needed to isolate the error. When the culprit has been identified, the information is recorded and recommendations made to eliminate the problem. Prepare M&S for Use Phase When all errors identified during testing are adjudicated and/or eliminated, the User accredits the simulation. At this point, the integrated model is ready for its intended use. References DoD Data Administration, DoD Modeling and Simulation (M&S) Data Administration Strategic Plan (DASP), DMSO, April 1996. IEEE 1278.4: Recommended Practice for Distributed Interactive Simulation -- Verification, Validation, and Accreditation, Annex C, Data Verification, Validation, and Certification, 1997. Rothenberg, Jeff; Walter Stanley; George Hanna; Mark Ralston, Rand Project Memorandum PM-710-DMSO, August 1997. This report offers an outstanding theoretical foundation for data verification and validation. It includes a data VV&C (verification, validation and certification; i.e., data V&V) process model

RPG Special Topic 11 and lists considerations for structuring individual data V&V efforts with different kinds of data. It also provides a guide for planning both producer and user V&V activities. RPG Links in this Document: RPG Diagram: Data V&V for New M&S RPG Reference Document: Data V&V Concepts and Terms RPG Reference Document: White Paper: Report of Verification, Validation, and Certification (VV&C) Tiger Team RPG Special Topic: Conceptual Model Development and Validation RPG Special Topic: Requirements RPG Special Topic: Subject Matter Experts and VV&A RPG Special Topic: Validation RPG Template: Data Quality Templates The appearance of hyperlinks does not constitute endorsement by the DoD, DMSO, the administrators of this website, or the information, products or services contained therein. For other than authorized activities such as military exchanges and Morale, Welfare and Recreation sites, the DoD does not exercise any editorial control over the information you may find at these locations. Such links are provided consistent with the stated purpose of this DMSO website.