7.3.6.7. Information Support Plan (ISP) Content
7.3.6.7.1. Chapter 1. Introduction
7.3.6.7.2. Chapter 2. Analysis
7.3.6.7.3. Chapter 3. Issues
7.3.6.7.4. Information Support Plan (ISP) Appendices
7.3.6.7.1. Chapter 1. Introduction
Summarize the program's relationships to relevant Joint Operating Concepts (JOCs) and/or Joint Functional Concepts (JFCs) (e.g., focused logistics), as described in the program's JCIDS documents. Provide an OV-1 (High-Level Operational Concept Graphic) for the basic program and descriptive text. For programs not covered by JCIDS, analogous documentation may be used.
- Summarize the program's relationship to other programs.
- Provide a graphic that shows the major elements/subsystems that make up the system being acquired, and how they fit together. (Provide an Internal SV-1 (System Interface Description)/(e.g., a system block diagram)). Identify the Joint Capability Areas down to three tiers. Use OV-2s in sufficient detail to show each associated area.
- Analyze threat-specific information that will play a role in capability development, design, testing and operation. This information should be obtained from the appropriate JCIDS documents. Information Operations (IO) threats should be analyzed using the Information Operations Capstone Threat Capabilities Assessment, DI-1577-12-03, August 2003. This is the most comprehensive source available for IO-related threat information.
- For a weapon system, briefly describe the purpose, design objectives, warhead characteristics, sensors, guidance and control concept (as appropriate), command and control environment, general performance envelope, and primary IT, including NSS, interfaces.
- For a command and control system, describe the system's function, dependencies and interfaces with other IT (including NSS) systems.
- For an Automated Information System (AIS), describe the system's function, its mission criticality/essentiality, dependencies, interfaces with other IT (including NSS) systems and primary databases supported.
- Provide the following program data to help the reviewer understand the level of detail to be expected in the ISP:
- Program contact information (PM, address, telephone, email address, and ISP point of contact).
- Program acquisition category: Acquisition Category.
- List Milestone Decision Authority: Defense Acquisition Board, Information Technology Acquisition Board (or component Milestone Decision Authority) or other.
- Milestone covered by the specific ISP.
- Projected milestone date.
- Universal Identifier/DoD IT Portfolio Repository number.
- Document Type.
7.3.6.7.2. Chapter 2. Analysis
In analyzing a program's information needs and dependencies, the analysis must be considered in the context of the process that is critical to the capability being completed by the system. Look at the critical mission threads associated with the program and compare the operational architecture views to the system architecture views to make sure all information needs and dependencies that are critical to the capability being developed are met. Use in the architectures and consider the following in the analysis:
- Analysis of the qualitative and quantitative sufficiency of Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) support (e.g., hardware, software, processes, etc.) should be accomplished in terms of the operational/functional capabilities that are being enabled.
- An understanding of the operational/functional capabilities and the metrics that define whether they are being performed adequately.
- An understanding of what enabling functional capabilities must be performed in order to achieve a higher-level capability (C4ISR functions will almost always be enabling capabilities).
- An understanding of which players (nodes) will direct or perform the missions associated with delivering the capabilities.
- An understanding of DoD Information Policies.
- A definition of the Time Phase in which the analysis is to be accomplished. A user identifies the Time Phase, or Time Phases, the program operates within and defines the Time Phase Name (i.e., increment, block, spiral, et al.), Year, and a Description.
- The information-needs discovery process. For most systems, the steps that follow this list provide an information-needs discovery process that can be used to analyze the system under development. Other approaches for discovering information needs that apply to the intelligence information needs discovery process are:
- Using the stages of the intelligence cycle (collection, exploitation, dissemination, etc.).
- Life-cycle stages (Concept Refinement, Technology Development, System Development and Demonstration, etc.).
- The following steps (and notes) are based on using the Architecture developed in accordance with the DoDAF, during the JCIDS process.
Step 1: Identify the warfighting missions and/or business functions within the enterprise business domains that will be accomplished/enabled by the system being procured.
The Mission Threads are based on the last version of the Joint Capability Areas and allow a developer to bin a program's capabilities. A developer selects a Tier 1 Mission Thread in the Enhanced ISP and is then able to select the Tier 2 and Tier 3 mission threads that are children of the chosen Tier 1.
Note: Joint Capability Areas are found at: http://www.dtic.mil/futurejointwarfare/cap_areas.htm
Step 2: Identify information needed to enable operational/functional capabilities for each warfighting mission identified in Step 1 by performing functional capability decomposition.
Note: If a Command and Control capability is the top-level driver of the function breakdown, then the OV-4 (Command Relationships) will be a necessary product to help define the functional capabilities needed. The OV-4 will likely require several OV-5 (Activity Model) functional breakdowns to enable each of the command elements identified.
Note: The architecture product most useful in managing the discovery of enabling/enabled capability relationships for each operational/functional capability is the OV-5 (Operational Activity Model). The OV-5 can be used to show the subordinate capabilities that are necessary to achieve a higher-level operational or functional capability. Notice that the OV-5 focuses on "what" rather than "how." See Example Capability Breakdown, Figure 7.3.6.7.2.F1. This example illustrates specific items to consider for a weapon system that can be used to get the flavor of what is expected in step 2 for a program/system.
Step 2 Example: Clear Mines from Littoral Area
Figure 7.3.6.7.2.F1. Example Capability Breakdown
Note: The specific form of this information should capture key information from an OV-5 (Operational Activity Model) and/or other information source (e.g., an outline or hierarchical graph). The important point is that the capability relationships are understood and attributes are identified so that assessments can be made.
Note: Specific items to consider:
- For satellite systems include: (e.g. Satellite control).
- For communication systems include: (e.g. Net-management).
- For business process systems include: (e.g. information contained in databases, other information sources).
- For weapons systems include: (e.g. Collection Management Support, Threat or signature support, targeting support, Intelligence Preparation of the Battlefield).
- For sensor systems include: (e.g. Collection Management support, Threat or Signature support, Targeting support, Intelligence Preparation of the Battlefield, and Remote Operations).
- For platforms consisting of a mix of the above include: (e.g., Collection Management support, Threat or Signature support, Targeting support, Intelligence Preparation of the Battlefield.
Step 3: Determine the operational users and notional suppliers of the information needed.
Step 3.a: Provide an OV-2 to identify the operational nodes and elements that drive the communications needed to enable the functional capabilities. For large platforms/systems, this effort should identify the major operational nodes (information drivers) within the platform, as well as nodes that are external to the platform/system with which information will be shared.
Step 3a Example: Clear Mines from Littoral Area
Figure 7.3.6.7.2.F2. Example OV-2 Nodes for Mine Clearance
Step 3.b: Map these nodes (internal and external systems and people) and their activities to the functions identified in OV-5.
Step 4: Establish the quality of the data needed to enable the functions identified in OV-5 and performed by the operational nodes in OV-2 (Operational Node Connectivity).
Note: Establish performance measures and determine the level of satisfaction necessary to make the information useful. (Examples: decimal precision for numerical data, NIIRS for imagery, annotated versus raw data, etc.)
Note: When radio and other information transport systems are identified as providing support, establish transmission quality parameters and then assess whether the programs/systems intended to be used can meet these criteria.
Note: A factor in determining quality is the user (person or sub-system) (i.e., specifically how does the user intend to use the information).
Step 5: Determine if timeliness criteria exist for the information.
Note: To help establish timeliness, use OV-6C (Operational Event Trace Diagram) to establish event sequence. Considerations include:
- Order of arrival of information to enable transaction process(es) (for weapon systems) Latency of data due to speed of flight issues.
- Currency of data in databases to support operations.
Step 6: Determine/Estimate the quantity of information of each type that is needed.
Factors influencing quantity include:
- Frequency of request or transmittal.
- Size of the information requested (packet size, image size, file size etc.).
- Whether data is individual items or a data stream that is provided for a period of time.
- Whether data transmission is "bursty" or continuous over some period of time.
- Whether data transmission is random or occurs at some predictable interval.
- The anticipated spectrum of employment (e.g. Military Operations Other than War or Major Theater of War).
Note: Ultimately this analysis should help estimate the bandwidth needs and should provide an assessment as to whether adequate bandwidth is available. If bandwidth is limited, what actions can be taken to reduce demand or use the bandwidth more efficiently?
Step 7: Discuss the way information will be accessed or discovered.
If data links are involved, identify them and also the message sets that will be implemented.
If an Internet/Web-based (GIG compliant) means of searching for and retrieving posted data is to be used, describe the approach, including compliance with DoD Instruction 8410.01, "Internet Domain Name Use and Approval."
- Data stores must exist for your program.
- The type of searching capability needed.
Note: In many cases, this discussion will involve multiple levels of enabling systems. For example, maybe the enabling system is a Global Command and Control System (GCCS) application. GCCS rides on the Secret Internet Protocol Router Network (SIPRNET). So both levels of this support should be discussed.
Step 8: Assess the ability of supporting systems to supply the necessary information.
Identify the external connections to the system using the system views and identify any synchronization issues associated with schedule and/or availability of external systems.
Note: Supporting systems include collection platforms, databases, real time reports, messages, networked data repositories, annotated imagery, etc.
- Assess the ability to collect, store, and tag the information (to enable discovery and retrieval).
- Assess the ability of networks to provide a means to find and retrieve the necessary data.
- Assess the ability of the information transport systems to move the volume of data needed.
- Assess synchronization in time (i.e., years relative to other system milestones) with supporting programs.
- Whether the information will cross security domains.
Note: If systems will connect to the intelligence Top Secret (TS)/ Sensitive Compartmented Information (SCI) network, Joint Worldwide Intelligence Communications System, or utilize TS/SCI information, they will have to comply with Intelligence Community Directive (ICD) Number 503, "Intelligence Community Information Technology Systems Security Risk Management, Certification and Accreditation" and DCID 6/9, "Physical Security Standards for Sensitive Compartmented Information Facilities," 18 November 2002.
Note: The number of levels of analysis will depend on the detail required to identify the critical characteristics of the information needed to support the program. This should be accomplished for all phases of the acquisition life cycle.
Note: It is anticipated that other communities such as the intelligence community may have to assist in the determination and analysis of these information needs.
Step 9: Assess Radio Frequency (RF) Spectrum needs.
Note: DoD Instruction 4650.01 establishes spectrum management policy within the Department of Defense. DoD Instruction 4630.8 and CJCS Instruction 6212.01 require Spectrum Supportability (e.g., spectrum certification, reasonable assurance of the availability of operational frequencies, and consideration of Electromagnetic Environmental Effects) to be addressed in the ISP. The Services have additional spectrum management policies and procedures.
To support the Spectrum Supportability process, the ISP should document the following:
- Requirements for use of the electromagnetic spectrum including requirements for wide bandwidths.
- Description of the intended operational Electromagnetic Environment (Allows for realistic test and evaluation).
- Impact of the loss of a planned spectrum-dependent command, control, or communication link as a result of an unresolved spectrum supportability issue. (To be identified in the issue section of the ISP.)
Note: For platforms that employ RF emitters developed by a separate acquisition program, spectrum documentation for those emitters may be cited here as evidence of compliance with Spectrum Supportability regulations.
Step 10. Assess Net-Centricity.
Note: Consider individual Services net-centric policies and procedures that supplement DoD Net-centric policy.
Note: This is an emerging requirement in the analysis required for ISPs. When Net-Centric Enterprise Services (NCES)/Core Enterprise Services (CES) are available, programs will be expected to conduct a detailed analysis of compliance. Programs should be aware of this developing requirement, as it will become an essential part of determining net-centricity and compliance with the DoD Information Enterprise (IE).
Step 10a: Using the information provided as a result of Step 7, the PM should evaluate the program against measurement criteria from the DoD Information Enterprise Architecture (IEA).
Step 10b: Provide an analysis of compliance with the emerging Net-Centric Enterprise Services (NCES)/Core Enterprise Services (CES).
As the DoD IE CES develops, its specifications should be cross-walked with the ISP system's planned network service specifications. Identify the issues associated between the CES service specifications and those of the system that is the subject of the ISP. Compliance would mean that the system would connect seamlessly with the defined DoD-level enterprise services.
Step 10c: Assess use of the following:
Step 11: Discuss the program's inconsistencies with the DoD Enterprise Architecture and the program's strategy for getting into alignment.
Identify areas where the latest versions of the DoDAF and DoDIEA do not support information needs. (See also DoD Directive 8000.01.)
Step 12: Discuss the program's IA strategy. Also provide a reference to the Program Protection Plan, if applicable.
Step 13: Identify information support needs to enable development, testing, and training.
For development: Weapon systems include information about potential targets that are necessary to support system development. (Example: target signature data)
For testing: Include information support needs critical to testing (Example: Joint Distributed Engineering Plant (JDEP)). Do not duplicate Test and Evaluation Master Plan information except as needed to clarify the analysis. In addition, for information on software safety testing please refer to software test & evaluation.
For training: Include trainers and simulators that are not a part of the program being developed. Include:
- Separately funded training facilities your program intends to use.
- Network support that will be needed to meet the training needs of your program.
7.3.6.7.3. Chapter 3. Issues
- Identify risks and issues (as defined in DoD Instruction 4630.8) in a table similar to Table 7.3.6.7.3.T1 or in an outline containing the same data.
- Group operational risks and issues under the mission impacted, then under the impacted functional capability (for that mission).
- When risks or issues involve more than one mission, subsequent missions should be marked with the previous issue number and those fields that remain the same should be so marked.
- Include the following column (or outline) headings:
- Issue Number
- Supporting System
- Source Architectures (e.g., Command and Control (C2), Focused Logistics, Force Protection, Force Application, Battlespace Awareness, Space, etc.)
- Issue Description
- Risk/Issue Impact (Use the AT&L "Risk Management Guide for DoD Acquisition" for this assessment)
- Mitigation Strategy or Resolution Path
Table 7.3.6.7.3.T1. Sample Issue Table Format
|
Operational Issues
|
|
Mission
|
|
Functional Capabilities Impacted
|
|
Issue
Number
|
Supporting
System
|
Source
Architecture
|
Issue
Description
|
Issue
Impact
|
Mitigation Strategy/
Resolution Path
(and Time-Frame)
|
| |
|
|
|
|
|
| |
|
|
|
|
|
|
Development Issues
|
| |
|
|
|
|
|
| |
|
|
|
|
|
|
Testing Issues
|
| |
|
|
|
|
|
| |
|
|
|
|
|
|
Training Issues
|
| |
|
|
|
|
|
| |
|
|
|
|
|
Risks and issues considered critical to the program's success will be briefed by the PM at OIPT meetings. At a minimum, information risks and issues will be incorporated into the PM's risk management program and treated as any other type of program risk and issue.
7.3.6.7.4. Information Support Plan (ISP) Appendices
Appendix A. References. Include all references used in developing the ISP. Include Architectures; other relevant program documentation; relevant DoD, Joint Staff, and Service Directives, Instructions, and Memos; ISPs or ISPs from other programs; any applicable JCIDS documentation; and others as deemed necessary.
Appendix B. Systems Data Exchange Matrix (SV-6).
Appendix C. Interface Control Agreements. Identify documentation that indicates agreements made (and those required) between the subject program and those programs necessary for information support. For example, if System A is relying on information from System B, then this interface dependency must be documented. At a minimum, this dependency should be identified in the ISPs for both System A (the information recipient) and System B (the information provider).
Appendix D. Acronym List: Provide an Integrated Dictionary (AV-2).
Other Appendices. Provide supporting information, as required, not included in the body of the ISP or relevant JCIDS documents. Additional or more detailed information used to satisfy DoD Component-specific requirements should be included as an appendix and not incorporated in the body of the subject ISP. Additional architecture views used in the ISP analysis will be provided in a separate appendix and referenced in the main body of the ISP.
DAG Tutorial 
