WARHAWK_SOO_V2.docx

FAR 16.505(b) FAIR OPPORTUNITY PROCESS APPLIES

Tactical Air Control Party (TACP)

WARHAWK

Statement of objectives (soo)

04 June 2024

Air Force Life Cycle Management Center (AFLCMC) Intelligence, Surveillance, Reconnaissance & Special Operations Forces Directorate (ISR & SOF) Special Operations Forces/Personnel Recovery Division (SOF/PR) Battle Control Systems Branch (AFLCMC/HBDB) 11 Barksdale St., Bldg. 1614 Hanscom AFB, MA 01731-2100

Distribution Statement D: Distribution authorized to the Department of Defense and U.S. DoD Contractor only [CTI, Export Controlled] [26 April 2024]. Other requests for this document must be referred to [AFLCMC/HBD, 75 Vandenberg Dr. Bldg. 1630, Hanscom AFB, MA 01731].

WARNING - This document contains technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C., Sec 2751, et seq.) or the Export Control Reform Act of 2018 (Title 50, U.S.C., Chapter 58, Sec. 4801-4852). Violations of these export laws are subject to severe criminal penalties. Disseminate in accordance with provisions of DoD Directive 5230.25.

DESTRUCTION NOTICE: Destroy in accordance with Information Security Oversight Office (ISOO) CUI Notice 2019-03.

FAR 16.505(b) FAIR OPPORTUNITY PROCESS APPLIES

CUI

1. Overview

The Command and Control (C2) execution and Strike and Integration application titled WARHAWK is an agile software (S/W) development program managed by the United States Air Force (USAF). It represents the follow-on system to replace the previously developed Close Air Support System (CASS) software, targeted for the Air Support Operations Center (ASOC) and Tactical Operations Center (TOC). The ASOC’s primary mission is to control air operations forward of the Forward Line of Own Troops (FLOT) and short of the Fire Support Coordination Line (FSCL). Normally collocated with the senior Army fires element, the ASOC is directly subordinate to the Air Operations Center (AOC) and is responsible for coordinating and directing air support for land forces at the tactical level. WARHAWK also supports mounted/vehicular operations while on-the-move (OTM) and at-the-halt (ATH).

This document is intended to be a part of a formal Fair Opportunity Proposal Request (FOPR).

2. Objective

Develop an enterprise software solution for battlefield data communications, targeting, and battlespace awareness to support Tactical Air Control Party (TACP), TOC and ASOC digitally-aided Command and Control (C2) and Close Air Support (CAS) operations, as well as OTM and ATH mounted/vehicular Strike and Integration missions.

The solution will implement a Modular Open Systems Approach (MOSA) by designing the solution with highly cohesive, loosely coupled, and severable modules that utilize standards-based interfaces and can be competed separately and acquired from independent vendors. The initial focus of this effort was the ASOC portion of the enterprise solution. The solution provided a set of tools that assist the User executing the tactics, techniques, and procedures in a manner that expedites the process and reduces human error. Development continued to provide TOC and CAS operations.

The goal of this new software development effort is to enhance those previously developed TOC, ASOC, C2 and CAS capabilities. This development effort shall continue to implement a truly agile development process to mitigate problems way ahead of fielding.

The content of each Government approved S/W release will reflect emerging requirements, feedback from demonstration and testing activities, operational use and changes in technology balanced against resource constraints and risk.

3. Specific Objectives

3.1. Program Objectives

3.1.1. Meet the capabilities listed in the WARHAWK System Capabilities Document (SCD).

3.1.2. Solicit Continuous User Feedback - The development process will include continuous customer feedback sessions at the end of each sprint (retrospectives) as well as quarterly review meetings at the Pope Army Airfield (AAF), NC, User Engagement Site (UES) to solicit User Feedback during the development process. The goal of this software development effort is to improve user interaction and help TACP/JTAC (Joint Terminal Attack Controller) operators do their job instead of changing the way they do their job. The UES mimics an active ASOC with ASOC systems and personnel to help facilitate improvements by receiving active user feedback to create a truly agile development and help mitigate problems ahead of fielding.

3.1.3. Implement an agile development process.

3.1.4. Plan the development as a single DO with separate Contract Line Item Numbers (CLIN) for each 12-month development period. Software releases will be planned as quarterly events. As part of the plan, develop an Integrated Master Schedule (IMS) that includes all significant events and milestones.

3.1.5. Provide the support required to sustain and maintain the applications as they are developed, integrated, and fielded.

3.1.6. Establish a collaborative and efficient data management system.

3.1.6.1. Integrated Digital Environment. The Contractor will implement an Integrated Digital Environment (IDE) in accordance with FAR subpart 227.7108 that provides the entire WARHAWK team (Contractor and Government) with real-time remote electronic controlled access to all unclassified and Controlled Unclassified Information (CUI) programmatic and technical information used to test, integrate, document, and manage this effort. The Contractor will maintain this environment for the life of the contract, ensure currency of data on the IDE, and ensure access to all personnel identified in writing by the Government contracting officer. The IDE will be searchable and file names will be comprised of document name and version number. All documents will be posted to IDE in a searchable format (e.g., Microsoft Office 360 format, searchable pdf, etc.). Contract Data Requirements List (CDRL) deliveries will adhere to the delivery instructions in Exhibit A.

3.1.6.2. The Contractor will use approved methods and procedures for handling, marking, storing, and transmitting (through secure electronic methods) classified material IAW AFI 31-401.

3.2. Development Process Objectives

3.2.1. S/W Development Objectives - Establish an approach that delivers biweekly sprint releases and Program Increment (PI) releases throughout the life of the contract. PI releases will consist of six sprint releases unless modified during PI planning. Implement an approach that facilitates requirements analysis sessions with users to develop detailed derived software requirements based on the Government provided high-level requirements provided in the SCD and this SOO. A detailed process for requirements management will be included as part of this approach. Implement an approach that sustains, maintains, and improves upon the WARHAWK application baseline. In order to expedite future expansion and minimize sustainment costs the following software development methods and design tenets will be followed:

(CDRL A002– Software Product Specification (SPS)) (CDRL A006– Interface Control Document) (CDRL A008– Software Development Plan)

3.2.1.1. Development Methods.

3.2.1.1.1. Agile Development Principles - Follow the four (4) Core Values and 12 Principles of the Agile Manifesto to improve the frequency of software delivery, better adapt to changing requirements, and improve customer satisfaction. Working software is the primary measure of progress.

3.2.1.1.2. Continuous User Feedback - The development process will include continuous customer feedback sessions as well as review meetings at the Pope AAF UES to solicit User Feedback during the development and requirements analysis processes.

3.2.1.1.2.1. The UES is a remote site at Pope AAF, NC that is located in the 818 OSS. The UES provides the Government an analysis of new software and hardware from operators in the field. The UES requests TACP operators from different Divisions to give a perspective on how the software/hardware should aid TACPs in the future fight. The TACP community gets to evaluate what the Program Management Office (PMO) and Major Command (MAJCOM) is possibly fielding; this allows operators a firsthand look to have changes made before it is disseminated across the community. The UES gives a voice to the operators; feedback from the operator is taken and sent directly to the PMO office to reach out to the Contractor and direct needed changes.

3.2.1.1.3. Test Driven Development - All automated test code and test cases will be developed before any functionality code.

3.2.1.2. Design Tenets

3.2.1.2.1. Extensibility - The software components will be designed for extensibility. Future enhancements will not include modifications, only extensions.

3.2.1.2.2. Cohesion (LCOM) - High cohesion will be the goal. High cohesion promotes modularity and encapsulation. Each component will do one thing and do it well.

3.2.1.2.3. Coupling (CBO) - High CBO is undesirable. Excessive coupling between object classes is detrimental to modular design and prevents reuse. Design will be to the interface not the component.

3.2.1.2.4. Cyclomatic Complexity (CC) - Low cyclomatic complexity will be the goal. Historically high CC correlates to a high bad fix (fix creates additional issues) probability.

3.2.1.2.5. Code Coverage - Complete unit test coverage will be the requirement. Proper code coverage can improve test quality and help refactor code more easily. There will be multiple test cases for each software path.

3.2.1.2.6. Static Code Analysis - Identify serious vulnerabilities that could lead to system failures, poor reliability, system breaches, or unsafe conditions.

3.2.1.3. Quality Assurance. The developer will use an automated Continuous Integration/Continuous Delivery (CI/CD) pipeline to build and test all developed software at each commit. For each commit of the developed software:

3.2.1.3.1. The CI/CD pipeline will perform all unit tests.

3.2.1.3.1.1. Unit tests will include negative tests to validate proper handling of error conditions.

3.2.1.3.1.2. Unit tests guarantee the functionality of classes and methods and will not rely on the availability of external systems such as Application Programming Interfaces (API) or databases.

3.2.1.3.1.3. The unit test code coverage will be computed.

3.2.1.3.2. The CI/CD pipeline will perform static code analysis using a tool to analyze software design to identify bad practices and risks.

3.2.1.3.2.1. The CI/CD pipeline will perform Static Analysis Security Testing (SAST) using a tool to identify security vulnerabilities and risks and perform dependency checks.

3.2.1.3.2.2. A failure at any step in the CI/CD pipeline will halt the pipeline execution for that software build.

3.2.1.3.3. CI/CD pipeline results and testing metrics, including those in Section 3.2.1.2, will be monitored and captured in an automated fashion for all developed software.

3.2.1.3.4. The developer will perform additional tests appropriate to the software for all quarterly operational software releases. Automation of these tests will be implemented where feasible:

3.2.1.3.4.1. Integration tests with external systems such as databases or APIs will be performed for any system with a reliance on external software.

3.2.1.3.4.2. User Interface (UI) functionality will be verified for any software with a UI component.

3.2.1.3.4.3. Dynamic Analysis Security Testing (DAST) will be performed on any software with an API or UI that can be accessed remotely.

3.2.1.3.5. Access to all reporting output or a digital copy of the reports will be provided to the Government via the IDE.

3.2.1.4. Productivity. The developer will use the following productivity metrics to ensure a flow of value from the organization to its customers and to eliminate wasteful activities.

3.2.1.4.1. The Sprint Burndown metric measures how many story points have been completed during the sprint and how many remain and helps forecast if the sprint scope will be completed on time.

3.2.1.4.2. The Velocity metric measures how many story points were completed by a team, on average, over the past few sprints. It helps predict the team’s output in the upcoming sprints.

3.2.1.4.3. The Lead Time metric measures the total time from the moment a story enters the system (in the backlog), until it is completed as part of a sprint, or released to customers. It measures the total time for a requirement to be realized and start earning value.

3.2.1.4.4. Access to all reporting output or a digital copy of the reports will be provided to the Government via the IDE.

3.2.2. Establish a process to ensure each quarterly Operational Release achieves integration, certification, accreditation, and fielding. The Contractor will meet all requirements for security, testing, and lifecycle support for the system up to a SECRET security classification.

3.2.2.1. The Contractor will support the Government in meeting the Command and Control Platform Information Technology (C2 PIT) Certification and Accreditation Process in development of the software program, as described below. The Contractor will reference C2 PIT Certification and Accreditation Process Guidelines, NIST SP 800-37, and AFPD 33-202 for Cybersecurity process guidance; and use NIST SP 800-53 as governing Cybersecurity requirements where applicable to the WARHAWK Software.

3.2.2.2. The Contractor will provide written confirmation that the software complies with the current NIST SP 800-53 Risk Management Framework controls identified in the Authority to Operate (ATO) and/or Interim Authorization to Test (IATT) submitted as part of the Cybersecurity Report via the IDE.

3.2.2.3. The Contractor will run a DoD-approved source code evaluation tool on all developed/reused software to assure no malicious code or security issues are present. The Contractor will protect and demonstrate/verify all COTS software and software of unknown pedigree (i.e., software from sources buried in the supply chain).

3.2.2.4. The Contractor will provide software architectural, software design, and software development process information in the Cybersecurity Report to support Cybersecurity compliance via the IDE. (reference 1.d on https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/850001_2014.pdf).

3.2.2.5. The Contractor will provide in-person Cybersecurity technical support to the Government to support the WARHAWK application formal Cybersecurity test events including preparation for IATT, Interim Authority to Operate (IATO), and ATO.

3.2.2.6. The Contractor will support and participate in the Government Cybersecurity Working Group meetings as required. The Contractor will provide responses to assigned action items for issues identified at the Cybersecurity Working Group meetings. For planning purposes assume the meetings will happen monthly.

3.2.2.7. Perform analysis and risk mitigation assessments of Government Security Test Reports and Penetration Evaluation Reports. All results will be provided via the IDE. For planning purposes assume the analysis will be required quarterly.

3.2.2.8. The Contractor will implement a Vulnerability Management approach. As a part of the automated build, integration, and test process (CI/CD pipeline), the Contractor will integrate Fortify Static Code Analyzer and the CppDepend and NDepend static code analysis tools as security and vulnerability scanning tools. When items of a configurable threshold are detected by the tools, the Contractor will stop the build process with errors, sending all reports generated from the failed build to developers for review. The Contractor developers will address the flagged items and commit updates to source control for inclusion in the next build iteration to ensure that unsecure code cannot result in an unsecure software build. The Contractor will conduct Assured Compliance Assessment Solution and Security Technical Implementation Guide scans and deliver all scan reports (native format and human readable) to the Government. Should the Contractor require any change(s) be made to the Vulnerability Management approach, the Contractor will receive Government approval prior to implementation.

3.2.2.9. The Contractor will comply with the TACP-M Security Classification Guide (SCG) to avoid spillage. All vulnerability assessment reports containing vulnerabilities may be classified per the SCG.

3.2.3. Establish an approach for collaboration with the Government to plan, coordinate, and execute Government test activities, including incorporating support from Contractor and governmental development and operational test organizations. The test program will identify testing techniques and procedures permitting an Integrated Test Team (ITT) approach through Contractor Testing (CT), Development Testing (DT), and Operational Testing (OT). The Contractor will support Government testing during DT, OT, interoperability certification tests, or other interoperability events as required. Implement an approach to collect and analyze data, a plan to reduce and resolve deficiencies found in testing, and a method to prevent rework during DT and OT.

(CDRL A009– Test Plan) (CDRL A010– Test Report)

3.2.3.1. Plan, develop, and conduct automated capability-based scenarios, and incorporate them in requirements verification and test at the appropriate level to ensure operationally relevant contractor testing.

3.2.3.2. Participate as a member of the ITT and related Integrated Product Teams (IPT) as needed to include any necessary Test & Evaluation Teams’ Meetings/Reviews.

3.2.3.3. Provide program event and review schedules permitting Government attendance and insight throughout the program.

3.2.3.4. Support all Test Readiness Reviews (TRR) and Pre-TRRs with the Government serving as the chair of the reviews.

3.2.3.5. Develop integrated test approach and procedures working with the ITT to verify the software meets performance requirements derived as part of the detailed requirements development process. These tests will be automated wherever possible. Collect and analyze data and provide reports for these tests via the IDE.

3.2.3.6. During test execution, the Contractor will assist the Lead Developmental Test and Evaluation Organization (LDTO), and Operational Test & Evaluation organization (e.g. AFOTEC, 605 TES, MAJCOM) test team members in identifying and documenting deficiencies in accordance with the deficiency report process outlined in T.O. 00-35D-54, USAF Deficiency Reporting, Investigation, and Resolution (DRI&R); dated 1 November 2011. The LDTO will use the 605 TES TDCS to manage and track Test Problem Reports during all operational evaluations. The Contractor’s Discrepancy Review (DR) system will be a standalone system but provide at least a structured export of the data (e.g. comma-separated) to the Government for import into the Government’s DR system upon request.

3.2.3.7. Determine and identify equipment, test, data, and instrumentation requirements required for Government support and Government Furnished Property (GFP), if any, required to conduct contractor testing.

3.2.4. Establish Configuration Management (CM) process to establish and maintain Configuration Management for the fielded systems to include incremental deliveries and associated patches.

3.2.4.1. The Contractor will implement CM processes, procedures, and systems to ensure that all configurations are properly planned, identified, documented, maintained, and controlled. The Contractor will use MIL-HDBK-61A and ANSI/EIA-649B as guidance.

3.2.4.2. For each operational software release, the Contractor will establish its functional baseline based on the derived detailed requirements established during the incremental development cycles and will provide written certification, to the Government, that the functional requirements have been met during the testing activities via the IDE.

3.2.4.3. The Contractor will provide all supporting CM documentation for each S/W Release (Includes service pack and patch releases) to define the software baseline. All associated configuration control documentation will be provided to the Government in support of all system level testing, certification, and accreditation.

(CDRL A002– SPS)

(CDRL A005– Configuration Management Plan)

3.2.4.4. The Contractor will support and participate in all IPT meetings, Technical Interchange Meetings (TIM) relating to configuration control, as required by the Government. For planning purposes assume the meetings will happen quarterly.

3.2.5. Implement a Performance Analysis process. The Contractor will determine and quantify performance for all WARHAWK fielded configurations to include limiting factors and optimum configurations. The performance analysis methodology will evolve throughout the performance of this contract. Results of performance analyses will be presented, posted on the IDE, and updated at periodic TIMs. The Contractor will develop alternatives to increase performance within existing hardware constraints (e.g., configuration changes).

3.2.6. The Contractor shall support the Government integrator (NSWC Crane) in building and documenting a "universal" WARHAWK System Install Disk (SID) that is applicable to all TACP-M systems using WARHAWK.

3.3. Program/Technical Management Objectives

3.3.1. Establish a program management process that provides Government visibility and open communications for cost, schedule, and performance issues.

3.3.2. Implement a risk management process that identifies the critical technical, program, cost, and schedule risks, assesses the likelihood and impact of risks, prioritizes risks, demonstrates how risks will be mitigated and monitors and manages the risk mitigation process.

3.3.3. Identify critical decision points in the technical design, development, and risk-mitigation processes and the cost-performance trade-offs to be made at those points to support the designation of measurable milestones in the development process.

3.3.4. Identify and schedule TIMs for the definition and improvement of the internal design and interoperation with other programs and systems.

3.3.5. Identify and schedule technical and programmatic reviews to provide Government visibility into the development process and to meet integration requirements.

3.3.6. Implement the process for identifying, accepting, tracking, and processing deficiency reports and baseline change requests.

3.3.7. Post on the IDE a Difference Briefing detailing all of the new, modified or removed capabilities and system behavior that is updated with each increment and operational release.

3.3.8. Collaborate with the PMO in the creation of the detailed Integrated Master Schedule, providing the PMO with advance notice of all schedule changes. Inputs will include the incremental development cycles, PI demonstrations, operational software releases, contractor system level testing, Government testing, documentation creation, training material creation, and when the Software Development Kit (SDK) or API updating are completed.

3.3.9. Implement an approach for detailed cost reporting that provides the Government information to labor category level within the Work Breakdown Structure (WBS). Travel and Other Direct Costs will be listed separately. The approach must also correlate the S/W productivity metrics to the amount of labor hours expended.

(CDRL A001– Contract Funds Status Report) (CDRL A003– Cost and Hour Report (Flexfile)) (CDRL A004– Software Resources Data Reporting) (CDRL A007– Contractor's Billing Voucher) (CDRL A012– Fund Man-Hour Expenditure Report)

3.3.10. Establish an approach to communicate and coordinate with the Government Program Office on all aspects of development, integration, deliverables, sustainment, training, testing, and fielding.

3.4. Fielding/Sustainment Objectives: Implement a sustainment strategy throughout the lifecycle of WARHAWK to meet its mission requirements by establishing user support systems such as user and system administration training, a tier 3 help desk, UES, and software maintenance.

3.4.1. Training/Subject Matter Expert (SME) Field Support – Implement a modern training approach that focuses on enhancing user/operator/system administrator proficiency. The Contractors will implement an approach that utilizes their existing Software and Systems Engineering SMEs as much as possible.

3.4.2. Create, Update, and post on the IDE all User, System Installation, and System Administration documentation as required by S/W modifications, field requests or test event redlines. The Documentation will support all the System configurations defined in the SCD.

(CDRL A002– SPS)

(CDRL A011– Software User’s Manual)

3.4.3. Tier 3 Help Desk - The Contractor will provide Tier 3 Help Desk with five (5) days a week/8-hour support to the TACP-M Help Desk at Crane, IN. This help desk will include technical expertise and assistance on questions/issues related to the WARHAWK application up to a SECRET security classification. The Contractor will maintain the problem report tracking system and processes that are established as part of the WARHAWK program. The Contractor will track and record all contacts/resolutions from the TACP-M Help Desk and assist with the writing, tracking, and/or analysis of Software Problem Reports (SPRs) and Baseline Change Requests (BCRs). The help desk tickets, problem reports, and change requests will be provided via the IDE in a Comma Separated Value (CSV) format. The Contractors will implement an approach that utilizes their existing Software and Systems Engineering SMEs as much as possible. Comment by JONATHAN: I think we are calling the contractor support tier 2?

3.4.4. Commercial Off-the-shelf (COTS) Software Management - The Contractor will manage COTS maintenance for all necessary COTS software licenses and maintenance agreements for the WARHAWK operational and support sites. This will include all currently fielded locations as well as future locations to be identified by the program office. The sustainment Contractor will be responsible for license management, data rights, and warranties associated with the fielded systems.

3.4.5. Software duplication and distribution - The Contractor will be responsible for software reproduction and distribution of all Development and Operational software releases to the Program Office, System Integrator (Crane), UES, DT, and OT locations. The System Integrator will be responsible for software distribution to the operational locations. The Contractor will be responsible for integration or distribution of Operational software releases through other government software distribution channels as directed.

(CDRL A002– SPS)

3.4.6. Software Maintenance - The Contractor will provide technical support for software maintenance activities associated with each software version released. The Contractor will continually conduct analysis to recommend enhancements for each S/W release to improve the usability, sustainability, and Cybersecurity posture of the S/W.

3.4.7. COTS Manuals and Supplemental Data - The Contractor will provide documentation for all systems services delivered under this Task Order. The Contractor will provide COTS manuals, supplemental data for COTS manuals, and documentation in accordance with best commercial practices for each PI release. This documentation will include users’ manuals, operators’ manuals, maintenance manuals and network and application interfaces if specified in the task order.

(CDRL A011– Software User’s Manual)