9.7.5. Testing in a Joint Operational Environment
The phrase ‘testing in a joint environment’ originated in the U.S. Department of Defense 2006-2011 Strategic Planning Guidance for Joint Testing in Force Transformation. It refers to testing military systems as participating elements in overarching joint SoS. This testing in a joint operational environment initiative supports the department’s long-term strategy to test as it fights. Joint operations have become the mainstay of Warfighting. Force transformation will require the T&E community to place a greater emphasis on testing joint war fighting capabilities developed in response to the JCIDS process. Future T&E must ensure combatant commanders can rely on equipment to operate together effectively without introducing problems to warfighters. For a detailed discussion of changes needed to bring about this vision of T&E, see the DepSecDef’s “Testing in a Joint Environment Roadmap,” dated November 12, 2004. The proposals in this roadmap provide important enablers for acquiring new systems created with joint and testing legacy equipment and systems that are made joint.
The Joint Mission Environment (JME) is defined as, "a subset of the joint operational environment composed of force and non-force entities; conditions, circumstances and influences within which forces employ capabilities to execute joint tasks to meet a specific mission objective". It describes the expected operating environment of the system (or system of systems) under test, and includes all of the elements that influence the required performance the new ‘capability’ must demonstrate. These include the particular mission requirements in which the system is being employed; physical factors such as the blue and opposing force structures; geographic and demographic aspects of the joint operating area, etc., as well as the interactions between these elements.
To be successful, testing in the JME cannot be a new step added at the end of operational T&E, nor can it replace current DT or OT. It does however represent a departure from the way DoD acquisition professionals plan and execute systems engineering, DT&E, and OT&E – indeed the entire acquisition process. Testing in a JME involves the appropriate combination of representative systems, forces, threats and environmental conditions to support evaluations. These representations can be LVC, or distributed combinations thereof.
Testing in a JME applies throughout the life cycle of the system. Identification of a joint issue/problem early in a system's life (including as early as the conceptual phase) will reduce costs and issues. This applies to evaluating system performance, or how well the system does what it is designed to do, as well as the system’s contribution to the joint mission, or how DoD employs the system to achieve the mission. A system’s interaction with the JME is evaluated along an evaluation continuum using constructive and virtual representations and live systems in various combinations.
The JME and associated joint capability requirements will be defined in the ICD, CDD, and the CPD. The evaluation plans for assessing these requirements will be articulated in the SEP and the TES at Milestone A. At the pre-EMD Review, evaluation plans for assessing these requirements will be articulated in the Pre-EMD draft documents (SEP, TEMP, and ISP). At Milestones B and C, they will be articulated in the SEP, TEMP, and ISP.. For each case, the selection of LVC systems that will be used to recreate the JME to support testing will depend on the purpose of the assessment and on the interactions the SUT will have with other elements in the JME.
This section also briefly addresses some additional areas as outlined in the ‘Testing in a Joint Environment Methods and Processes (M&P) Implementation Plan’ originally produced by the M&P Working Group that was formed during the summer of 2004 to address testing in a joint environment. The areas of concern outlined below are: (1) Description of Joint Mission Environments, (2) How to use the Joint Mission Environment, (3) Testing in a Joint Mission Environment Program Management Office Support, and (4) Important Acquisition Program Responsibilities.
9.7.5.1. Description of Joint Mission Environments
The JCIDS will create requirements for effects and capabilities at the joint mission level. This means JCIDS will identify desired mission level effects that are shortfalls. Shortfalls are addressed by materiel and non-materiel solutions. Materiel or possible system (for a new/modified system or SoS) KPPs are then proposed to provide the desired mission level effect(s). Because of this, systems development should not begin and testing cannot occur without definition(s) of the JME and a defined joint mission associated with a shortfall to be addressed by a system or systems.
With respect to obtaining information for selected joint missions, users of the joint environment can start with the universal joint planning process to break down missions, but it is a process that starts at the Universal Joint Task List (UJTL) level and extends down to the COCOM level to plan joint task force operations and/or training events. However, this level of "fidelity" may not be available at the JCIDS ICD/CDD/CPD level because it is mission specific at the COCOM or Joint Task Force level.
The joint mission descriptions should set the stage for evaluation of a system(s) within a joint mission area and provide the tester what they need to plan the test. There are essential elements of the joint mission description necessary to plan, execute, and analyze assessments and T&E throughout a system’s acquisition process.
Additionally, users of the joint environment determine and obtain representations for the threat, threat composition and disposition, and threat scheme of maneuver appropriate for the selected joint mission/task. The currently approved ‘Guidance for the Development of the Force (GDF)’ scenarios and/or the maturing ‘Defense Planning Scenarios’ will provide the source of this information. There is also a Threat Scenarios Group from the U.S. Army Test & Evaluation Office working threat scenarios. In addition, coordination with the Service intelligence agencies and the DIA is critical. The threat must be system specific (specific to the platform under examination) and also mission specific (specific to the joint mission examined). The next step (after identification of the threat scenarios) is to determine what should be used to represent the threat; which can be a LVC representation.
Different Services should be referred to depending on the type of model needed for test. As the Services have generally focused their modeling efforts based on their usual area of operations. The Army and/or the National Geospatial-Intelligence Agency are the best sources for all terrain models. The Navy is the best source for all oceanographic (surface and subsurface) models, and the Air Force is the best source for air and space models. DoD M&S responsibilities are delineated in DoDD 5000.59, “DoD Modeling and Simulation (M&S) Management,” dated August 8, 2007, and there are M&S Executive Agents with responsibilities defined by the DMSO. There should also be a standard set of environment/background models established for the JME.
9.7.5.2. How to use the Joint Mission Environment
Systems engineering and testing will require insertion of concepts and systems into the JME as a standard part of the acquisition process. Since this is a change of scope for previous assessments and tests, a process for how to use the joint mission environment needs established.
The ultimate goal for systems engineering and testing in a joint environment is the ability to insert any system into the applicable JME at any time during the life of a system. Two basic items will be examined through insertion into the JME. The first item is to ensure the systems to be acquired are interoperable with other systems. This includes not only how they interact and communicate as expected and required, but also understanding SoS dependencies. The second item goes beyond the system interaction and communications to examine what value the systems add to joint military capabilities. In other words, the second item is to assess the contribution of the system to the mission success.
Interoperability and contribution should be examined each time a system is inserted into the JME, including times when substantive changes or upgrades are made to an individual system. Users can determine which joint mission/task(s) to test for a system with a role in multiple missions.
Selection of the most stressing mission(s) and/or the mission(s) with the most interactions appears to be the most defensible approach. Test authorities must ensure that if another required mission involves a system interaction not included in the "most stressing" mission, the interaction is tested separately. Examining different joint missions as the system progresses through the acquisition process is also a good approach especially if there appear to be multiple stressing missions. Another option is to consult with the intended joint users (COCOM & Service Combatant) and have them define representative mission tasks.
With respect to the criteria/process to determine the appropriate representation (live, virtual, or constructive) of players in each engineering (DT or OT) event, the supporting players that constitute the family-of-systems for the joint mission will have to be determined on a case-by-case basis. The goal is for the system being inserted into the JME to be the most mature representation available. However, it will always be a live system for IOT&E.
9.7.5.3. Joint Mission Environment (JME) Program Management Office
Scheduling all of the assets in the JME, especially live assets participating in exercises, will prove a complex undertaking. A management and scheduling capability must exist, and it is assumed the PM will establish a JME PMO (or equivalent) for this purpose. The JME PMO will coordinate all LVC assets, and the script of events, which is the plan for the specific JME missions incorporating acquisition systems under test in accordance with their schedules. Note that acquisition systems tend to have fixed decision points where unplanned delays could severely impact production. Finally, with a complex facsimile of a mission environment in place and acquisition systems scheduled to perform missions within it, additional programs may ask to "join in" the scheduled events, for testing, training exercises, or other special events. This is encouraged, but the testing needs of the sponsoring program must of course take precedence over the needs of other participants, and their participation should not interference with the core purpose of the JME events.
DAG Tutorial 
