Issues in the Validation of Battle Models Presented at 19 ISMOR David Frankis ‘The Barbican’, East Street, Farnham, Surrey GU9 7TB 01252 738500 www.Advantage-Business.co.ukwww.Advantage-Business.co.ukAugust.

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

Supporting further and higher education Future Activities Sarah Knight Helen Beetham.
Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition.
Sharif University of Technology Session # 2.  Contents  Structured analysis and design  Information system development  Systems Analysis and Design.
DEVELOP A COHESIVE SIZE ORGANIZATION. PURPOSE To provide information on how to develop a platoon-size organazation by establishing and executing a plan.
OASIS Reference Model for Service Oriented Architecture 1.0
Lecture 13 Revision IMS Systems Analysis and Design.
Task analysis 1 © Copyright De Montfort University 1998 All Rights Reserved Task Analysis Preece et al Chapter 7.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
Slide 1 Test Assurance – Ensuring Stakeholders get What They Want Paul Gerrard Gerrard Consulting PO Box 347 Maidenhead Berkshire SL6 2GU UK e:
Introduction to Computer Technology
Release & Deployment ITIL Version 3
What is Business Analysis Planning & Monitoring?
Decision Making Dr Vasuprada Kartic NAC Batch IX PGDCPM.
Sense of Initiative and Entrepreneurship This project has been funded with support from the European Commission. This [publication] communication reflects.
1 Module 4: Designing Performance Indicators for Environmental Compliance and Enforcement Programs.
COMPGZ07 Project Management Presentations Graham Collins, UCL
Chapter 9 Database Planning, Design, and Administration Sungchul Hong.
Database System Development Lifecycle © Pearson Education Limited 1995, 2005.
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
1 Shawlands Academy Higher Computing Software Development Unit.
Chapter 2 The process Process, Methods, and Tools
1 Validation & Verification Chapter VALIDATION & VERIFICATION Very Difficult Very Important Conceptually distinct, but performed simultaneously.
Advantage Business Group ‘The Barbican’, East Street, Farnham, Surrey GU9 7TB
1 REQUIREMENT ENGINEERING Chapter 7. 2 REQUIREMENT ENGINEERING Definition Establishing what the customer requires from a software system. OR It helps.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Business Analysis and Essential Competencies
T. Dawson, TASC 9/11/13 Use of a Technical Reference in NASA IV&V.
Towards Appropriate Selection of Analysis Tools and Methods.
INTERNATIONAL LABOUR ORGANIZATION Conditions of Work and Employment Programme (TRAVAIL) 2012 Module 13: Assessing Maternity Protection in practice Maternity.
Creating a Shared Vision Model. What is a Shared Vision Model? A “Shared Vision” model is a collective view of a water resources system developed by managers.
1 The Software Development Process  Systems analysis  Systems design  Implementation  Testing  Documentation  Evaluation  Maintenance.
1 Chapter 5 Software Engineering Practice. 2 What is “Practice”? Practice is a broad array of concepts, principles, methods, and tools that you must consider.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
ISM 5316 Week 3 Learning Objectives You should be able to: u Define and list issues and steps in Project Integration u List and describe the components.
© 2001 Change Function Ltd USER ACCEPTANCE TESTING Is user acceptance testing of technology and / or processes a task within the project? If ‘Yes’: Will.
Project Outline City of Mountain View – need image !
RAINS Review Review of the RAINS Integrated Assessment Model Contract with CAFE Dec Sept 2004 Presentation 27 Sep 2004.
Software Engineering Saeed Akhtar The University of Lahore Lecture 6 Originally shared for: mashhoood.webs.com.
RAINS Review Review of the RAINS Integrated Assessment Model Contract with CAFE Dec Sept 2004.
GLOBAL SCHOOL OF PROJECT MANAGEMENT UNIVERSITY FOR INTERNATIONAL COOPERATION Ing. Osvaldo A. Martínez Gómez, MAP, MSc. Essential Topics - Project Management.
Develop Project Charter
Project quality management. Introduction Project quality management includes the process required to ensure that the project satisfies the needs for which.
Meeting Management/Planning. Today Go over basics of meeting management Introduce key elements of creating a plan.
The Software Development Process
1.  Interpretation refers to the task of drawing inferences from the collected facts after an analytical and/or experimental study.  The task of interpretation.
Chapter 8 Lecture 1 Software Testing. Program testing Testing is intended to show that a program does what it is intended to do and to discover program.
Component 8 Installation and Maintenance of Health IT Systems Unit 10 Developing a Test Strategy and Test Plan This material was developed by Duke University,
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
IAEA International Atomic Energy Agency Methodology and Responsibilities for Periodic Safety Review for Research Reactors William Kennedy Research Reactor.
WISE User Workshops Three user workshops held in 2012 Introduction and context Hands on exploring the tool Quantifying scenarios and exploring results.
Phases of Curriculum Design: Evaluation Stufflebeam’s CIPP Model Dr. Katherine Korkidis April 19, 2009.
International Atomic Energy Agency Regulatory Review of Safety Cases for Radioactive Waste Disposal Facilities David G Bennett 7 April 2014.
10. STEP 1: DEFINE & SCOPE Essential EAFM Date Place 10. Step 1: Define and scope the FMU Version 1.
Optimising Networking in Air Defence Dstl/CP12250 ISMOR 21, September 2004 Jackie Offord - C4/ISTAR Team Policy and Capability Studies
ANALYSIS PHASE OF BUSINESS SYSTEM DEVELOPMENT METHODOLOGY.
Unit – I Presentation. Unit – 1 (Introduction to Software Project management) Definition:-  Software project management is the art and science of planning.
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 Click to edit Master title style What is Business Analysis Body of Knowledge?
1 The Software Development Process ► Systems analysis ► Systems design ► Implementation ► Testing ► Documentation ► Evaluation ► Maintenance.
SCOPE DEFINITION,VERIFICATION AND CONTROL Ashima Wadhwa.
BSBPMG501A Manage Project Integrative Processes Manage Project Integrative Processes Project Integration Processes – Part 2 Diploma of Project Management.
Value 4 Golf is formed by a group of professionals who have been all their life linked to the world of golf, and actively participating.
Gathering a credible evidence base
CASE Tools and Joint and Rapid Application Development
The Project Management Framework
Gary Hughes, South Oakleigh College
Systems Analysis and Design
Review of the RAINS Integrated Assessment Model
Chapter 10 Verification and Validation of Simulation Models
Verification and Validation Unit Testing
Presentation transcript:

Issues in the Validation of Battle Models Presented at 19 ISMOR David Frankis ‘The Barbican’, East Street, Farnham, Surrey GU9 7TB

Acknowledgements  Dstl  This work was carried out under contract to Dstl by Advantage Technical Consulting  RMCS

Today’s Presentation  Why validation  CLARION  What was done  Issues raised  Questions

Why Validation?  UK Government decision-making must pass the test of independent scrutiny  Making a logical case based on credible information is key to this  OA claims to be able to support this by quantifying key aspects, objectively  The validity of this quantification is therefore crucial  A new version of CLARION required an update to its validation status

CLARION General  A Land-Air campaign model  Object Oriented C++ implementation  Functionality is based on the concept of missions:  Each entity (e.g. a division) has a mission  Subordinate units are tasked with missions based on the superior’s mission  Defined set of mission types  Generally Brigade level and above

CLARION Functionality  Movement and Attrition  Command  Communications  Sensing  Close combat, Arty, Recce, Helo  Some Air aspects  CBW  EW  No logistics in version examined (V3.0)

What is Validation?  The model is realistic?  The representation of internal processes is correct?  Known effects are covered?  Sufficient detail is included?  The results are plausible?  Conclusions drawn are substantiated?

Other Validation Issues  Scope of validation  Model only, or ancillary tools  Status of any comparison  Danger of mutually-supporting invalid models

Validation Activities  Prioritisation of Requirement  Selection of Comparison Method  Generation of Scenario  Comparison Activity  Analysis and Reporting

Prioritisation  CLARION has wide scope of functions and contexts  Key stakeholders were consulted for their views  Formal method used to prioritise  Main outcome: focus on mainstream uses, not functions less used (Air, EW, CBW)

Selection of method  Possible comparison approaches  Historical Analysis  Trials and Exercises  Other models  Military (and analytical) Judgement  Wargame  These are not mutually exclusive  Wargame was selected as best approach at a workshop  Dstl staff selected most appropriate (commercial) game

Scenario Generation  Workshop held with scientific and military analysts  Fictitious scenario overlaid on a map  Outline scheme of manoeuvre developed

Comparison and Analysis  Scenario entered in CLARION  Adjusted with military input  Then into wargame and played  Further CLARION adjustment to reflect military intentions in wargame  Comparison of outputs  Some practical difficulties arising from wargame limitations

Findings  Validation as part of study process  Data adjustment  User interface issues  Extraneous effects

Validation as Part of Study Process  Ideally, the data and the way the model is used requires (re-)validation on each study  Validation is an iterative process  How much?  What if the iteration doesn’t converge?  In exceptional cases, could have independent teams of analysts

Process Elements Selection of Scenario Scheme of manoeuvre CLARION input Exercise in CLARION Interpret outputs Study conclusions Wargame validate

User Interface Issues  If the user interface is unfriendly or unintuitive, analysts will lack confidence  Longer learning curve for new analysts and scrutineers  Resulting loss of confidence in results through uncertainty and reduced effective validation effort

Data Adjustment  In order to capture effects not explicit in the model, analysts adjust the input data  Acceptable as long as analysts doing the adjustment are doing the reporting  Legacy effects  Unpredictable interactions when done more than once

Extraneous Effects  CLARION scenarios are acknowledged to develop much more quickly than reality  As long as all processes (movement, attrition, communication) are accelerated the same for both sides, does not matter for many study purposes  BUT study results are easy to rubbish because they seem to have low credibility

Conclusions: General  Model unlikely to be the limiting factor on confidence in study results  The use of a good model cannot compensate for a poor process or the use of insufficiently skilled analysts  Where studies focus on scenarios, they, and their data, should be validated for that study  Consider use of a wargame tool to support the development of a scheme of manoeuvre in campaign studies

Conclusions: Process Elements  Treat input data collection and refinement as integral to the study, not a necessary evil  Iterate the review of input data, output results, and the use of adjunct tools to converge on a ‘valid enough’ solution  Ensure the military plan remains valid when conducting sensitivity excursions  For major studies, consider some parallel working  Use different experts at different stages to ensure freshness of perspective