FO RFI Overview Questions_V1.docx
DOCX document 239 KB Posted
- Attached to
- RFI WARHAWK Follow-On
- Solicitation number
- Not on record
- Issued by
-
Department of the Air Force
About this file
This document is a Request for Information (RFI) issued by the Air Force Life Cycle Management Center (AFLCMC) for a software development contract. The objective is to continue developing an enterprise software solution for battlefield data communications, targeting, and battlespace awareness to support Tactical Air Control Party (TACP) Tactical Operation Center (TOC), and Air Support Operation Center (ASOC) digitally aided Command and Control (C2) and Close Air Support (CAS) operations. The RFI seeks information from industry to identify qualified, experienced, and interested sources. The RFI includes detailed questions for vendors related to their experience with relevant applications, network interfaces, and system interfaces, as well as their development methodology, team composition, and contract structure proposals. Responses to the RFI are due by September 3, 2024.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| WARHAWK_SOO_V2.docx | DOCX document |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Tactical Air Control Party (TACP)
WARHAWK
Request for information (rfi)
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
AFLCMC located at Hanscom AFB, MA requests information from industry to identify qualified, experienced, and interested sources for a software development contract. This RFI is for market research purposes only; this notice shall not be construed as commitment by the Government to issue either a competitive or a sole source award, nor does it restrict the Government to a particular acquisition approach. This notice is not a Request for Quotation (RFQ), a Request for Proposal (RFP), an Invitation for Bid (IFB), or any other commitment by AFLCMC to contract for items within this RFI. The Government will not reimburse any costs associated with responses to this RFI. With regard to industry responses, AFLCMC will not release to any firm, agency, or individual outside of the Government any information marked “PROPRIETARY” without written permission from the respondent.
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.
Objective:
Continue developing an enterprise software solution for battlefield data communications, targeting, and battlespace awareness to support Tactical Air Control Party (TACP) Tactical Operation Center (TOC), and Air Support Operation Center (ASOC) digitally aided Command and Control (C2) and Close Air Support (CAS) operations. The solution will also support executing CAS missions while the TACPs are operating At The Halt (ATH) or On The Move (OTM) from armored vehicles.
The current application implemented 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. Development continued to also provide Tactical Operation Center and Close Air Support operations. The solution provided a set of tools that assist the User executing the tactics, techniques, and procedures described in Air Force Tactics, Techniques, and Procedures (AFTTP) 3-3.ASOC, 4 April 2018 and AFTTP 3-3.JTAC (as revised 24 Oct 2012) in a manner that expedites the process and reduces human error.
The goal of this new software development effort is to enhance those previously developed TAC, ASOC, C2 and CAS capabilities. This development effort shall continue to implement a truly agile development process to mitigate problems way ahead of fielding.
Capability Requirements:
The seven (7) major capabilities required for the ASOC, TOC, and lower echelons are described in more detail in the WARHAWK System Capabilities Document (SCD). The Gateway/Comm. functional or capability area has already been procured as a separate solution and the remaining six (6) other areas have been developed as part of WARHAWK but will be continuously enhanced and improved. The requirements specified in the SCD are high level requirements. All new detailed level requirements shall be developed using the User feedback requirements process described in the Statement of Objectives.
Software (S/W) Architecture:
The current solution has implemented 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 objective software (S/W) architecture is shown in Figure 1. All S/W developed to meet the solution shall consist of three (3) major building blocks: Human Machine Interface/User Interface (HMI/UI), User applications, and Core Module services.
The Core Module Services (CMS) supports multiple programs with a single platform agnostic Core Module Services application programing interface (API). The goal of the Core Module Services is to provide an abstraction layer from the common capabilities, Military-Standard (MIL-STD) message processing, and specific device and peripheral interfaces for the User Applications. The service interfaces support sending and receiving any message type. This allows the user application developers to focus on User functionality and ease of operations. The service interfaces between the user applications and the Core Module Services shown in Figure 1 is platform and S/W language agnostic by implementing a structured data via TCP/IP configurable interface. This type of interface provides flexibility for user application design and installation location (same or separate hardware (H/W) platform). The Core Module Services is compatible with Android, Windows, and Linux (future) operating system environments. The CMS is designed so that any message type shown in Figure 1 can be encapsulated/deconstructed and transmitted/received with any of the network layer components shown in the diagram. For example, a K-series message could be transmitted out a TCP/IPv4/188-220 stack or a K-series message could be transmitted out a TCP/IPv4/802.3 stack. The CMS is designed so that new messages and new versions of messages can be easily added as MIL-STDs and User requirements change.
The WARHAWK application leverages the “Government owned” Windows Tactical Assault Kit (WINTAK) mapping and User Interface (UI) framework. The WARHAWK application is composed of a collection of individual functionality modules. Each functionality module is designed and developed as a WinTAK Plugin using the Model View Control (MVC) or other Government approved software design patterns.
The specific radios, peripherals and external interfaces are described in greater detail in the WARHAWK SCD.
Figure 1: WARHAWK S/W Architecture
CUI
Required Tasks for the S/W Development Effort:
1. Continue developing the capability areas listed below to provide an ASOC/TOC/Lower Echelon application providing features enabling the C2 functions as described in Air Force Tactics, Techniques, and Procedures (AFTTP) 3-3.ASOC (as revised 4 Apr 2018); Army Techniques Publication (ATP) 3-91.1/Air Force Tactics, Techniques, and Procedures (AFTTP) 3-2.86, The Joint Air Ground Integration Center (as revised Apr 2019) ; and Air Force Tactics, Techniques, and Procedures (AFTTP) 3-3.JTAC (as revised 24 Oct 2012).
a. Capability Areas
i. JTAR Mgt.
ii. Air Space Mgt.
iii. Fires De-confliction
iv. Common Tactical Picture
v. Collaboration
vi. Air Control
vii. Add new Capability Modules and features as requirements are received from the Users and the User Engagement Site (UES).
b. Core Module Service
i. Continue developing the Core Module Services abstraction layer to interface with any future devices or peripherals.
ii. Continue developing the Core Module Services abstraction layer that will support development of the Capability Modules listed above.
2. The developer will also be responsible for sustaining the entire WARHAWK application. Sustainment activities will include:
a. Develop service packs may include security updates, code maintenance, bug fixes, patches, or external interface updates as described in the WARHAWK SOO.
b. Support Government directed test events as described in the WARHAWK SOO.
c. Provide training for any new capabilities as described in the WARHAWK SOO.
d. Provide tier 2 Help Desk support as described in the WARHAWK SOO.
Development Methodology:
1. In order to expedite future expansion and minimize sustainment costs the following S/W design tenets and development techniques should be monitored and analyzed in an automated fashion for all developed S/W:
· Test Driven Development - All automated test code and test cases will be developed before any functionality code.
· Cyclomatic Complexity (CC) - Low cyclomatic complexity shall be the goal. Historically high CC correlates to a high bad fix probability.
· Cohesion (LCOM) - High cohesion shall be the goal. High cohesion promotes modularity and encapsulation. Each component should do one thing and do it well.
· Coupling (CBO) - High CBO is undesirable. Excessive coupling between object classes is detrimental to modular design and prevents reuse. Design should be to the interface not the component.
· Extensibility - The S/W components shall be designed for extensibility. Future enhancements should not include modifications only extensions.
· Static Code Analysis - Identify serious vulnerabilities that could lead to system failures, poor reliability, system breaches, or unsafe conditions.
2. The following principles should be followed:
· Satisfy the customer through early and continuous delivery of valuable software.
· Continuous User Feedback - The development process should include continuous customer feedback as well as monthly review meetings at the Pope AAF User Engagement Site (UES) to solicit User Feedback during the development process. The goal of this new software development effort is to avoid past failures and help TACP/JTAC Users do their job instead of changing the way they do their job. The pilot site mimics an active ASOC with ASOC systems and personnel to help facilitate receiving active user feedback to create a truly agile procurement and will help mitigate problems ahead of fielding.
· Welcome changing requirements, even late in development.
· Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
· Working software is the primary measure of progress.
· Promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
· At regular intervals, reflect on how to become more effective and adjust behavior accordingly.
Questions for Vendor:
1. Describe (paragraphs a-e) your teams experience for each of the following applications, network interfaces, and system interfaces: ASOC/TOC; WinTAK; VMF Networks (i.e. JARN, StrikeNet); JREAP-C Interface; TBMCS; GCCS-A; JADOCS; AFATDS; TAIS; MUOS Network; ANW2 Network; HF Wideband Network; TSM-X; and Link-16 (Platform-J).
a. Please describe the functionality of the applications or components used.
b. Please describe where these applications or components have been fielded.
c. If available for fielding please describe the data rights offered on existing components and any required third party products, including the specific costs/terms of any license.
d. Describe the software languages and the approximate size of the source code.
e. Describe in detail any Application Programming Interfaces (API) that are publicly accessible for extensibility by other developers and projects. How are the APIs currently or proposed to be documented? What methods are used to interface internal components of the software?
2. Describe the number, size, composition, and specific skillsets of team(s) you would propose to accomplish this work. Include in your answer how you would staff up each team and how quickly (from contract award) each team could be fully dedicated to this effort.
3. Which specific Agile and/or iterative development methodology would your team(s) be following for this project? How is your organization currently employing this method for other projects? How has your organization tailored or deviated from the published doctrine of the selected methodology?
4. Describe your current development tool chain and integration environment and how the items listed in paragraph 1 of the Design Methodologies section above would be implemented. Also please describe your project management toolset and how each tool will be used in this project.
5. How, where, and how often would your organization propose your development team(s) interact with:
a. The Government Subject Matter Experts (SME) within the program office.
b. Representative end users of the software.
c. Other development teams of interfacing software components.
6. Explain how each of your answers to questions 2 through 5 will enable your organization to successfully put in practice the 12 Principles of Agile.
7. What type of contract and fee structure would your organization propose for best facilitating this project for the mutual benefit of Government and Contractor? Describe any metrics you propose by which to measure success.
8. Describe your organization’s previous experiences with taking over development of an existing software code base similar in size and complexity to this WARHAWK Application. From those previous experiences and lessons learned, what are the challenges you expect to encounter in this project and how do you propose to overcome them.
Submission Instructions
1. Responses to the questions listed above should be no more than 10 one-sided pages. Covers, tab dividers, title pages, glossaries, and tables of contents are not required. Please note e-mails containing file types such as: .zip, .xslx, .docx, or other macro-enabled extensions, may not be delivered to the intended recipients, and may need to be sent by DoD SAFE.
2. The following offeror information must be provided
a. Company Name
b. CAGE Code and DUNS Number
c. Address
d. Telephone Number
e. Fax Number (If available)
f. Email Address
g. Point of Contact for clarification or questions
3. Questions or clarifications pertaining to the RFI are requested by 20 Aug 2024, to allow adequate time for the government to respond.
4. Email responses can be sent to Mr. Edwin Hernandez Mendez at: edwin.hernandez_mendez.2@us.af.mil, and Mr. Michael Dunford at: michael.dunford@us.af.mil.
5. Final Responses are requested no later than 03 Sep 2024 at 1600EST. If additional time is required, please contact the POCs provided below. Extensions will be granted on a case-by-case basis.
6. For any further information/clarification, please contact Mr. Edwin Hernandez Mendez Reeves at: edwin.hernandez_mendez.2@us.af.mil, Mr. Michael Dunford at: michael.dunford@ua.af.mil or Ms. Kaitlin Reed at kaitlin.reed.1@us.af.mil image1.emf
File details come from the government source that posted it. Updated .