Download
1 / 13
130 likes | 499 Views
OneSAF Validation & Verification. Ha Ly Section 6.2. Capability Development Process. RIB Requirements. Version X . Y. PLRS. A&I Baseline. Systems Engineering. Change Request. Conceptual Modeling Knowledge Engineering. Implementation Software Development. Integration & Test.
E N D
OneSAF Validation & Verification Ha Ly Section 6.2
Capability Development Process RIB Requirements Version X.Y PLRS A&I Baseline Systems Engineering Change Request Conceptual Modeling Knowledge Engineering Implementation Software Development Integration & Test Integration & Test Build 1 Build 2 Build 3
Conceptual Modeling Knowledge Engineering RA 2 Weeks Design 2 Weeks CUT 3 Weeks SWIT 3 Weeks Integration & Test Implementation Build Cycle 10 Week Builds - CDD - DBD • PKAD • RIB • Code • Composites • Update ID • CUT Review • Test Thread • Test Thread Scenarios • SWIT Review • Update Documentation • Built baseline tar-ball - Update CDD • SRS-PLRS Mapping • RA Review - Implementation Document • UML Diagrams • GUI Mock-ups • Peer Design Review • TPO Design Review
Conceptual Modeling &Knowledge Engineering Process For behaviors, there are two main products: o Capability Description Document (CDD) o Domain Behavior Description (DBD) Activities Review refined CDD + DBD Publish draft DBD Publish refined CDD + DBD Review draft DBD SE/CM/KE kickoff Build (k-2) Build (k-1) Build k 10 4 5 9 10 Build week
DA Pam 5-11 • Verification: the process of determining that an M&S accurately represents the developer's conceptual description and specifications. • Validation: the process of determining the extent to which an M&S is an accurate representation of the real world from the perspective of the intended use of the M&S. • Accreditation: the official determination that a model, simulation, or federation of M&S is acceptable for use for a specific purpose.
OneSAF V&V • Behavior Validation is the process of ensuring that the correct things are modeled. • Behavior Verification determines if a behavior’s implementation performs as intended. For OneSAF, “performs as intended” means runtime performance matches the KAKE artifacts. • During FY06, TRAC-MTRY attempted to verify several OneSAF Pre 1.0 composite behaviors (e.g., MoveTactically and TailgateResupply)
Combat Physical Model Verification Testing Process “Continuous Physical Model Verification Testing” Physical Model Verification Methods Import MDVT output to MS Excel Verification Spreadsheet. Execute Model Development Verification Test Tool (MDVT) NO Proceed to next test case. Problems Detected? Analyze results with DCST output, logger statements, or debugging tool. YES Execute Vignette “online” Analysis Perform Java code review. Summary • Numerous scenarios/entity combinations were tested for each physical model to ensure complete coverage. • Version 1.0 of OneSAF included all the tools used in this process to verify the combat physical models. • OneSAF v1.0 Combat Physical Model Verification Testing document published by AMSAA in Summer 2007. Create detailed Problem Trouble Report (PTR) with recommended fix. OneSAF v1.0 Combat Physical Model Verification Testing Spring 2007 Update physical model status to include crosswalk with test threads.
Combat Physical Model Thread Test Relationships • Test threads tended to be general in their testing of effects • Threads did NOT test the specific functionality of the physical models • AMSAA developed crosswalk --- References all combat physical models used to support each test thread PM OneSAF expressed interest in making AMSAA crosswalk a standard OneSAF program metric. Sample Data from Test Thread/Physical Model Crosswalk
Implementation Design Description Capabilities Description Document Design Domain Behavior Description Source Code Behavior Data Tables Compositions Verification Tests Behavior Artifacts Component Development Domain Analysis
Methodology Courtesy of TRAC-Monterey
