23-30042 PWS.pdf

UNCLASSIFIED

Contr FD2060-23-30042 PWS REV: 0 i Distribution Statement: D

Performance Work Statement for

AN/ALM 280 Enhanced Automated Special Test Equipment (EASTE) Support, AN/ALQ-161A Subsystem Software Configuration, Engineering, Qualification and

Field Test Support for Preprocessor Flight Software (PFS), Integrated Facility for Avionics Testing (IFAST) and Engineering Support in the Electronic Warfare and Avionics

Integration Support Facility (EWAISF) for Electronic Warfare Integrated Reprogramming (EWIR)

Contract PR #: Robins-FD2060-23-30042

Revision 0 DATE: 14 October 2022

PREPARED BY: AFLCMC/WNY

236 Milledgeville St, Ste F30 Robins AFB GA 31098

DISTRIBUTION STATEMENT D: Distribution authorized to Department of Defense and U.S. DOD contractors only (Critical Technical) (3 April 2023). Other requests for this document shall be referred to AFLCMC/WNY B-1B DAS IPT PM, Robins AFB, GA 31098. Questions concerning the technical content should be directed to EW+A Program Office (PO).

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 Administration Act 1979, as amended (Title 50, U.S.C., App. 2401 et seq.). Violators of these export laws are subject to severe criminal penalties.

HANDLING AND DESTRUCTION NOTICE: Comply with distribution statement and destroy by any method that will prevent disclosure of the contents or reconstruction of the document.

Contract PR FD2060-23-30042 PWS REV: 0 1

Description of Services

1.1 Objective(s)

This Performance Work Statement (PWS) describes the services required to support the B-1B Defensive Avionics Subsystem (DAS) ALQ-161A System. These services include:

1. Acquire engineering support services for the AN/ALM-280, Enhanced Automated Special Test Equipment (EASTE).

2. Acquire engineering support for the AN/ALQ-161A system software qualification and test for all ongoing and future AN/ALQ-161A deficiency analyses, technical inquiries, Preprocessor Flight Software (PFS) block cycle change programs, and laboratory maintenance/upgrade efforts.

3. Acquire engineering support and configuration management support for the B-1B DAS sustainment efforts along with maintaining the Electronic Warfare Avionics Integrated Support Facility (EWAISF) and Integration Facility for Avionics System Testing (IFAST) in order to accomplish Electronic Warfare Integrated Reprogramming (EWIR) hardware in the loop (HITL) test and evaluation including Ops Recce. The overall mission goal is to maintain and sustain the AN/ALQ-161A system, EASTE, EWAISF, and IFAST.

The contractor's primary responsibility is to support planning, development, execution, post-test analysis, and, reporting of lab testing, including software configuration management functions.

The contractor services include support of AFLCMC/WNY, the Product Group Manager (PGM) for the AN/ALQ-161A and AN/ALM-280 system, by participating in all phases of the multi-year sustainment efforts. The end goal is to provide cost-efficient, quality software solutions that can be fielded in a timely manner and support the USAF mission. AFLCMC/WNY is the overall system technical authority and has Operational Safety, Suitability, and Effectiveness (OSS&E) responsibility. AFLCMC/WNY has program management responsibilities for all AN/ALQ- 161A and AN/ALM-280 projects. AFLCMC/WN has overall technical authority for the AN/ALM-280 core hardware and AN/ALM-280 core software.

The contractor services include providing engineering test support for other software system products which are directly impacted by or related to the PFS in accordance with the PWS/task description. These software products may include, but are not limited to, Emitter Identification Data (EID), Emitter Reprogramming Software (ERS), AN/ALM-280 EASTE software, Common Aircraft Portable Reprograming Equipment (CAPRE) software, Line Replaceable Unit (LRU) firmware, and system lab and data analysis tools. AFLCMC/WNY requests for contractor participation in software development phases and technical review of documents to identify and resolve deficiencies in technical content, including specific attributes such as accuracy, adequacy, lack of ambiguity, completeness, and the degree of technical quality.

The contractor services include performing all technical efforts in compliance with the applicable software development processes specified in each program's Project Requirements Specification (PRS), Software Development Plan (SDP) and organizational software Operating Instructions

(OI).

1.2 Benefit to United States Air Force (USAF)

Contract PR FD2060-23-30042 PWS REV: 0 2

This acquisition will benefit the United States Air Force (USAF) by providing maintainability and sustainability of the B-1B DAS EWAISF, EASTE, IFAST and software updates for testing of B-1B DAS, Engineering test support and Field testing to meet EWIR mission requirements.

1.3 Background

The AN/ALQ-161A system is a Low Density, High Demand system, and highly specialized due to the complexity of the AN/ALQ-161A system and the exceptionally large number of LRU’s (108). The AN/ALQ-161A system is the defensive integrated Radio Frequency Electronic Countermeasures (RFS/ECMS) system designed specifically for the B-1B bomber aircraft. The ALQ-161A system is designed to detect and counter all modes of radar-based weapon systems;

this includes detecting and jamming ground based, and airborne threats. It also provides a Tail Warning Function (TWF) to detect and countermeasures to defeat incoming missiles from the aft sector. The ALQ-161A system not only protects the B-1B but other aircraft in its flight formation. The complexity of the ALQ-161A system requires a specialized skill set to meet the sustainment requirements.

The AN/ALQ-161A is a highly specialized system with 12,000+ sub-assemblies. The system, which was initially delivered in the 1980’s, has been sustained through a series of Operational Flight Program (OFP) block cycle upgrades and hardware upgrades to incorporate modifications necessary to detect and counter the ever-changing threat. The system was transferred to AFLCMC/WNY without a complete set of documentation. A complete replacement of the AN/ALQ-161A was attempted 1992-2002 as Block F of the aircraft Conventional Munitions Upgrade Program (CMUP). However, technical difficulties resulted in multiple cost and schedule breaches and the program was terminated in Dec 2002. A planned competitive ACAT III level program, titled Enhanced Tracker Unit (ETU), was submitted for the FY17 POM to replace eight of the AN/ALQ-161A LRUs to provide improved aircraft situational awareness.

An additional planned competitive ACAT III level program, titled Jamming Technique Hardware, was submitted for the FY17 POM to replace three of the AN/ALQ-161A LRUs to provide improved aircraft self-protection. Since then, those three LRUs have been activated and are working in the field as of January 2020. The ETU and Jamming Technique Hardware programs have been merged into the Defensive Avionics System (DAS) Supportability Update (DSU)]. The program task is to upgrade the DRFM hardware to allow for more DRFM jamming channels as well as to use a portion of the hardware as an additional receiver. Multiple contractors have been activated to develop software and hardware updates in order to field this capability by FY 25. The AN/ALQ-161A is estimated to remain on the B-1B until 2040.

Services Summary

Performance Objective PWS Reference

Performance Threshold

The contractor shall respond to technical inquiries from AFLCMC/WNY and the B-1B user community.

4.1 The contractor shall provide response within five (5)

business days to all technical inquiries.

Contract PR FD2060-23-30042 PWS REV: 0 3

Performance Threshold

The contractor shall submit a report to document the results of the deficiency analysis.

4.2 4.4

4.4.2 4.4.8 4.4.9 4.4.10 4.4.12 4.4.13 4.4.14 4.4.15 4.5.4 4.5.5 4.5.6 4.11

Reports shall be technically accurate. The contractor shall report the status of each analysis investigation in the monthly status report. Following receipt of all comments, reports shall require no more than one (1) revision per report after the initial submittal.

The contractor shall technically manage contractor work efforts and B-1B DAS test programs.

4.4.16 Formal test cycles (FQT, FET, C&I, aircraft) shall

incur zero (0) schedule slips due to poor planning or execution of test activities by the contractor test manager. Formal tests shall miss zero (0) test objectives due to poor planning and/or executing of test activities by the contractor test manager.

The contractor shall provide accurate engineering support for

AN/ALQ-161A

modification programs.

4.2 4.4

4.4.8 4.4.9 4.4.10 4.5.4 4.5.5 4.5.6

Engineering documentation submitted by the contractor shall be technically accurate, requiring no more than one (1) revision per document after the initial submission due to technical inaccuracies.

The contractor shall provide quality technical reviews of documentation generated during the development phase.

4.4.5 4.4.6 4.5.1 4.5.2 4.5.3

The contractor shall be allowed zero (0) EPRs per contract PoP attributed to a system or software requirement’s characteristics of ambiguity, validity, accuracy, completeness, and verifiability after completion of the design phase.

The contractor shall submit problems detected during testing and data analysis in the form of EPRs or WRPRs as decided by the TSC/TRB process.

4.4.11 4.8.2 4.8.4 4.8.5 4.20

The contractor shall provide initial investigation on 100% of EPRs discovered during IFAST testing.

The contractor shall provide red-lines of documentation changes via the DAL.

4.4.5 4.4.9 4.4.14 4.11

Red-lined documents shall be technically accurate, and, following receipt of all comments shall require no more than one (1) revision per document after the initial submission.

Contract PR FD2060-23-30042 PWS REV: 0 4

Performance Threshold

The contractor shall verify that work products sent to the TSC are reviewed by the contractor.

4.4.5 4.4.6 4.4.7 4.4.8 4.5.1 4.5.2 4.6.1

The contractor shall verify, via documentation, that 100% of work products sent to the TSC are reviewed by the contractor, The contractor shall provide initial investigations for AISF generated EPRs.

4.4.9 4.4.10 4.4.11 4.5.5 4.5.6

The contractor shall provide initial investigation on 100% of EPRs discovered during EWAISF testing.

The contractor shall provide timely support of the PFS sustainment cycles.

4.4.1 4.4.2 4.4.3 4.8.4 4.20

The contractor shall incur zero (0) business days schedule slip to formal test phases due to poor planning or execution of test activities by the contractor.

TSC/TRB process 4.4.11 4.8.2 4.8.4 4.8.5 4.20

The contractor shall provide initial investigation on 100% of EPRs discovered during IFAST testing.

The contractor shall maintain program schedules and information in Program Status Notebooks.

4.8.2

The contractor shall not be the cause of more than three (3) technical or schedule defects per book per week.

The contractor shall maintain EPR and WRPR databases.

4.4.1 4.8.5 4.8.6 4.8.7

The contractor shall incorporate all database updates within one (1) business day (8 hrs.) of receipt of EPR/WRPR updates. EPR/WRPR updates requiring TSC approval shall be incorporated within one (1) business day of the TSC approval.

The contractor shall accomplish efforts in accordance with project schedules.

4.2 4.4.3 4.4.4 4.4.8 4.4.9 4.4.10 4.4.11 4.4.16 4.4.17

4.5 4.5.4 4.5.5 4.8.2 4.8.3 4.8.4 4.8.7

The contractor shall be allowed less than 10% schedule variance against project schedules for development, testing, investigations, and document support. This metric will be calculated quarterly.

Contract PR FD2060-23-30042 PWS REV: 0 5

Performance Threshold

4.10.3 4.15.2 4.15.6 4.21 5.5.5 5.9

The contractor shall conduct acceptable Contractor Safety Program.

5.5.6 On base work: no more than two (2) Class C mishaps

per contract year. Zero (0) Class A or B mishaps.

The contractor shall comply with USAF wide and local security procedures.

4.8.9 4.8.11

5.2 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.2.6 5.2.7 5.2.8 5.2.9 5.5.5

The contractor shall be allowed zero (0) reportable security violations within a contract period of performance, as determined by the B-1B Security Classification Guide (SCG) and organizational procedures

Mishap Notification and Reporting

5.5.2 No more than one (1) instance of late mishap

notification per contract year.

Receipt of CDRL deliverable

4.10.2 4.10.3

5.8

There shall be no more than one (1) late submission(s) of deliverables per quarter. The Contractor shall notify the Government if the delivery of any data/document will not meet the scheduled delivery date and negotiate a revised delivery date. The data/document shall be delivered by the revised delivery date acceptable to the Government.

Quality of CDRL deliverable

4.10.1 There shall be no more than a total of five (5)

rejection(s) of deliverables per quarter. The Government will reject a deliverable if any technical errors or five (5) or more minor errors are found within the deliverable.

A technical error is defined as the format not being in accordance with the CDRL or the content not being accurate and complete in accordance with the CDRL, PWS or contract. A minor error is exemplified by a typographical error, a grammatical error, etc. The rejected deliverable shall be corrected and resubmitted within five (5) business days of notification of Government rejection.

Contract PR FD2060-23-30042 PWS REV: 0 6

Performance Threshold

Adherence to Contractor the Quality Management System (QMS)

5.9 Prior to contract/order award, the Contractor shall

submit a QMS, including a QCP, for acceptance by the Government MFT. 100% compliance with the QMS is required.

Sub-Contractor Participation and Utilize Ability One in performance of CDRL deliveries

4.8.14 4.8.14.1

4.14 4.14.1

The Contractor shall deliver a Sub-Contractor Participation Report annually on all task orders no later than 30 calendar days after basic contract anniversary date.

Government Property

Government property includes Government Furnished Property (GFP), Government Furnished Material (GFM), Government Furnished Equipment (GFE), special tooling, special test equipment, etc. GFP does include assets furnished for repair, maintenance, overhaul or modification.

3.1 Contractor Responsibility

The Contractor shall be responsible for Government property in their possession in accordance with the Federal Acquisition Regulation (FAR) and all other applicable Government regulations.

The FAR and applicable supplements can be accessed at the site. https://www.acquisition.gov/.

3.2 Government Property to be Provided

Government property to be provided includes Base Support.

3.2.1 Robins Air Force Base Support

The Government will furnish property incidental to the place of performance including office space and equipment, i.e., computer equipment, software, output device(s), phone/phone line, facsimile equipment, reproduction equipment and office supplies.

AFLCMC/WNY will provide current intelligence information to the Contractor as available. In addition, the EWAISF facility at Robins Air Force Base (AFB), the Integrated Facility for Avionics Testing (IFAST) facility at Edwards AFB, the Reprogrammable Electronic Warfare System Test (REWST) facility at Eglin AFB, and the Defensive Avionics System Laboratory (DASL) at a Contractor’s location will be made available for accomplishing this work effort on a noninterference basis. The Government will also arrange for Contractor access to aircraft, aircraft equipment, Main Operating Base (MOB) areas and personnel as necessary.

3.2.2 Reporting of Government Property

The Contractor shall have a system of internal controls to manage (control, use, preserve, protect, repair, and maintain) Government property in its possession in accordance with FAR 52.245-1, Contract PR FD2060-23-30042 PWS REV: 0 7 and its property management system shall be adequate to satisfy the requirements of this clause.

In accordance with the OUSD(A&S)/DPC Memorandum, Implementation of the Government Furnished Property Module, the contractor shall record receipt and return of all Government Furnished Property (GFP), as well as the reporting of shipment, consumption, disposal, or transfer to another contract, in the GFP Module in Procurement Integrated Enterprise Environment (PIEE), https://piee.eb.mil. This reporting requirement does not change any liability provisions or other reporting requirements that may exist under the contract. GFP training and guidance is located at the DoD Procurement Toolbox at https://dodprocurementtoolbox.com/.

Loss of Government Property

3.3.1 Definition of Loss of Government Property

“Loss of Government property” means unintended loss of or damage to Government property including property that cannot be found after a reasonable search, loss due to inadequate storage, loss due to lack of security, theft, damage requiring repair to restore the item to usable condition, or damage that renders the property useless for its intended purpose or Beyond Economical Repair (BER). Loss of Government property does not include manufacturing defects, obsolescence, normal wear and tear, or purposeful destructive testing. Unless otherwise stated in the contract/order, loss of Government property does not include normal and reasonable inventory adjustments, i.e., losses of low priority consumable material, such as common hardware, as agreed to by the Contractor and the Government Property Administrator.

3.3.2 Reporting Loss of Government Property

In accordance with DFARS 52.245-7002, Reporting Loss of Government Property, the Contractor shall report loss of Government property in the GFP Module in PIEE, https://piee.eb.mil/.

3.4 Return or Retention of Government Property

All property provided by the Government remains the property of the Government and shall be returned to the Government as directed, but no later than completion of the contract/order, unless the Procuring Contracting Officer (PCO) directs the Contractor to retain the property for continued use under a successor contract. All Government property shall be returned to the Government in the condition provided unless approved in advance by the PCO. All material generated under the contract/order becomes the property of the Government and shall be returned to the Government as directed, but no later than completion of the contract/order, unless the PCO directs the Contractor to retain the material for continued use under a successor contract. All Contract Data Requirement List (CDRL) deliverables become the property of the Government and shall be delivered to the Government as indicated by CDRL instructions.

3.5 System Access

The Government will provide Contractor personnel access to systems necessary to perform tasks under the contract/order.

https://piee.eb.mil/ https://dodprocurementtoolbox.com/ https://piee.eb.mil/

Contract PR FD2060-23-30042 PWS REV: 0 8

Technical Requirements

The AN/ALM-280 EASTE is a ruggedized test system used as the primary tool during end-to-end tests and fault diagnostics on the B-1B DAS including the AN/ALQ-161A. The DAS software, commonly known as the PFS, is routinely updated through software maintenance activities.

4.1 PFS/EASTE/EWAISF Technical Inquiries

The contractor shall respond to technical inquiries from AFLCMC/WNY and/or AFLCMC/WNK within five (5) business days. The contractor shall notify AFLCMC/WNY Contracting Officer Representative (COR) of any inquiry requiring more than 16 hours work effort.

The contractor shall support anomaly investigations at the discretion of AFLCMC/WNY as problems arise and are deemed sufficiently complex to warrant an analysis. Technical inquiries include the contractor’s support during software-related technical meetings.

All inquiries shall be documented in the monthly status reports, citing the inquiry subject and type of support provided (documentation, telephone, or technical meeting). The contractor shall include a summary total of the number of inquiries for the entire contract in each monthly status report.

CDRL DID Title Sub Title(if applicable) DID A006 Status Report Monthly Status Report DI-MGMT-80368A/T

A007 Scientific and Technical Report Summary

Deficiency Analysis Plan/Report DI-MISC-80048/T

4.2 PFS/EASTE/EWAISF Deficiency Analysis

Deficiency Analysis is a software sustainment risk reduction effort typically focused on analyzing prioritized software candidates scheduled for inclusion in upcoming block cycles. The contractor shall support and conduct deficiency analysis investigations in accordance with the PWS/task description. The contractor shall document each deficiency analysis investigation in accordance with the PWS/task description in a deficiency analysis plan and the results of each deficiency analysis.

The contractor shall report the status of each analysis investigation in the monthly status report, citing the subject, performing design analysis, developing the prototype solutions, testing the prototype solutions, performing re-work, and documenting the effort. The contractor shall include a summary total of the number of analyses for the entire contract in each monthly status report. Reports shall be technically accurate. Following receipt of all comments, reports shall require no more than one (1) revision per report after the initial submittal.

Contract PR FD2060-23-30042 PWS REV: 0 9

A007 Scientific and Technical Report Summary

4.3 EASTE Hardware/Software Development Cycle Support

The contractor shall support the following EASTE development cycles in accordance with the PWS/task description. The contractor shall conduct all development activities in accordance with the Level 3 or higher requirements of CMU/SEI-2010- TR-033, Software Engineering Institute Capability Maturity Model for Development, Version 1.3. The contractor shall capture all data generated within the following subtasks in the DAL. The contractor shall report the status of the following subtasks and per software candidate, where appropriate, in the monthly status report.

The contractor shall include a summary total of all candidates for the entire contract in each monthly status report.

The contractor shall support the hardware/software block cycle planning process, whereby they shall be required to assist in:

• EASTE Block Cycle Candidate Selection 4.4.3

• EASTE Project Planning 4.4.4

• EASTE System Requirements Definition 4.4.5

• EASTE Software Requirements Definition 4.4.6

• EASTE Architectural and Detailed Design Definition 4.4.7

• EASTE Implementation, Integration and System Functional Test 4.4.8, 4.4.10

• EASTE Field Testing 4.4.12

• EASTE Software Fielding Support 4.6

• EASTE FCA/PCA Plan 4.6. 1

• EASTE FCA/PCA Audit 4.6.2

4.4 PFS/EASTE/EWAISF Software Test Cycle Support

The contractor shall support the test cycle for the AN/ALQ-161A and AN/ALM-280 subsystem in accordance with the PWS/task description. The contractor shall capture all data generated within the following subtasks in the DAL. The contractor shall report the status of the following subtasks and per test case, where appropriate, in the monthly status report. Engineering documentation submitted by the contractor shall be technically accurate, requiring no more than one (1) revision per document after the initial submission due to technical inaccuracies.

4.4.1 PFS/EASTE/EWAISF Independent Verification and Validation (IV&V)

The contractor shall conduct an IV&V of Government directed software (i.e. PFS, ERS, RSST, EASTE, firmware, etc.). Software may consist of larger Block Cycle software packages or small “patch” size software packages. The verification function is to ensure the assigned software satisfies the development requirements of the software maintenance effort. The

Contract PR FD2060-23-30042 PWS REV: 0 10

Contractor IV&V team shall develop the test cases to include the required mission data parameters, test signal scenario(s), and test procedures required to test the software. The verification is to be conducted on the system and/or in a software environment using contractor developed tools as required. The contractor shall ensure:

• Availability of all equipment and its associated set-up and interfaces with each other needed to run the test

• Step by step procedures that trace to and implement the objectives of the test

• Demonstration of the problem as well as the solution and software versions associated with each

• Functional definition, location, and expected values to be observed at system test points and software break points used in the procedures

• Expected results for success/failure thresholds (e.g., voltages, memory locations and contents, technique parameters, etc.)

• Traceability of procedures to WRPR requirements

• Demonstration that other components of the system have not been affected by these changes

• Code audits are conducted to validate software changes do not contain unnecessary dead code or prototype code as well as ensuring software conforms to modern coding standards

The results of IV&V will be documented in a Test Report delivered at the completion of the IV&V effort. All problems discovered during the IV&V process will be documented in the Software Test Report (STR) and entered into the EPR database to ensure that all problems discovered are captured. A listing of all recorded EPRs and/or WRPRs shall be included in the Contractor-delivered monthly status report.

CDRL DID Title Sub Title(if applicable) DID A006 Status Report Monthly Status Report DI-MGMT-80368A/T A00L Software Test Report (STR) System Test Report DI-IPSC-81440A

4.4.2 PFS/EASTE/EWAISF Qualification and Testing

The contractor’s primary responsibilities is to support planning, development, execution and test analysis of PFS development and testing efforts to include deficiency analysis, block cycle candidate selection, project planning, qualification test, flight emulation test, Installation & Checkout (I&CO) and flight test. Development of additional risk mitigation processes is expected as lessons learned from previous block cycles.

The contractor shall provide engineering test support for other software system products which are directly impacted by or related to the PFS in accordance with PWS/task description. These software products may include, but are not limited to, EID, ERS, AN/ALM-280 EASTE software, CAPRE mission data load software, LRU firmware and software load tools, and system lab and data analysis tools.

The contractor shall participate in deficiency analysis, software development phases, I&CO, flight test, Technical Interchange Meetings (TIM), requirements and design meetings and

Contract PR FD2060-23-30042 PWS REV: 0 11 technical review of documents to identify and resolve deficiencies in technical content, including specific attributes such as accuracy, adequacy, lack of ambiguity, completeness, testability, test adequacy, and the degree of technical quality.

A00L Software Test Report (STR) System Test Report DI-IPSC-81440A

4.4.3 PFS/EASTE/EWAISF Software Block Cycle Candidate Selection

The contractor shall support the software block cycle candidate selection process, whereby they shall participate as a Multi-Functional Team (MFT) member to:

• Review the software candidate selections’ attributes:

• Assess the problem at the system performance level

• Identify the required system performance requirements

• Identify system operational performance benefits

• Identify system performance limitations resulting from the anticipated solution

• Identify existing, related system performance limitations that will not be addressed

• Identify interface impacts (internal, external, flight data recorder, AFS, LRU firmware, EID, ERM, ERS, CAPRE, technical data, etc.)

• Identify testability issues and potential system test approaches

• Identify impacts to software development, verification, and validation, lab and aircraft tools

• Identify the verification and validation approach

• Identify affected maintenance and operational procedures

• Assess the technical risk associated with the anticipated solution

• Define the validation and verification matrix for all block cycle software candidates

• Prioritize candidates

• Identify block cycle documentation impacts

• Identify requirements from other contractors and government agencies

• Collaborate to establish the project schedule

The contractor shall support a Block Cycle Candidate Selection in accordance with the PWS/task description.

4.4.4 PFS/EASTE/EWAISF Project Planning

The contractor shall support development of a project plan that describes the software work plan, tasks and schedule for accomplishment. The project plan shall address the software development processes, software tools, documentation requirements, software coding standards, configuration management processes, technical milestone meetings and criteria, test methodology, and any other requirements for successful execution of this software effort. The plan shall address all tasks to be accomplished and the responsible entity for accomplishing each task.

A00Q Management Plan N/A DI-MGMT-80004A

Contract PR FD2060-23-30042 PWS REV: 0 12

4.4.5 PFS/EASTE/EWAISF System Requirements Definition

The contractor shall review the redlined System/Subsystem Specification (SSS), ensuring the requirements meet the technical characteristics of a lack of ambiguity, validity, accuracy, and completeness. The contractor shall also analyze each system requirement and associated system test procedure(s), identifying any deficiencies with the test procedures. The contractor shall identify the requirement or procedure, the nature of the deficiency, and suggested solutions to the deficiency through the Technical Screening Committee/Technical Review Board (TSC/TRB) process. The TSC/TRB process will be provided by the government. The contractor shall verify, via documentation, that 100% of work products sent to the TSC are reviewed by the contractor.

The contractor shall provide quality technical reviews of documentation generated during the development phase. The contractor shall be allowed zero (0) EPRs attributed to a system or software requirement’s characteristics of ambiguity, validity, accuracy, completeness, and verifiability after completion of the design phase. The contractor shall participate in the system requirements definition efforts of the development organization(s), in accordance with PWS/task description.

A008 System/Subsystem Specification

(SSS) N/A DI-IPSC-81431A

A00M Test Requirements Document (TRD) N/A DI-ATTS-80041A A00N Engineering Support Data (ESD) Test Strategy Report DI-ATTS-80285C/T

A009 Software Requirements Specification

(SRS) N/A DI-IPSC-81433A

A00A Interface Requirements Specification

(IRS) N/A DI-IPSC-81434A

4.4.6 PFS/EASTE/EWAISF Software Requirements Definition

The contractor shall review the redlined SRS and Interface Requirements Specification (IRS), ensuring the requirements meet the technical characteristics of a lack of ambiguity, validity, accuracy, and completeness. The contractor shall be allowed zero (0) Engineering Problem Reports (EPRs) attributed to a system or software requirement’s characteristics of ambiguity, validity, accuracy, completeness, and verifiability after completion of the design phase. The contractor shall also analyze each software requirement and associated software test procedure(s), identifying any deficiencies with the test procedures. The contractor shall identify the requirement or procedure, the nature of the deficiency, and suggested solutions to the deficiency through the TSC/TRB process. The contractor shall verify, via documentation, that 100% of work products sent to the TSC are reviewed by the contractor. The contractor shall support a combined SSR/SRR per this PWS.

The contractor shall participate in the software requirements definition efforts of the development organization(s), in accordance with PWS/task description. The contractor shall analyze each software requirement and document test deficiencies with the requirements of the subject software product. The contractor shall support the Government in identifying the

Contract PR FD2060-23-30042 PWS REV: 0 13 requirement, the nature of the test deficiency, and suggested solutions to the test deficiency. The contractor shall convey the analysis and suggested changes using the TSC/TRB process.

The contractor shall support a combined System Specification Review (SSR) / Software Requirements Review (SRR) per this PWS.

A009 Software Requirements Specification

(SRS) N/A DI-IPSC-81433A

A00A Interface Requirements Specification

(IRS) N/A DI-IPSC-81434A

4.4.7 PFS/EASTE/EWAISF Architectural and Detailed Design Definition

The contractor shall participate in the design definition efforts of the development organization(s), in accordance with PWS/task description. The contractor shall identify potential design deficiencies of the system/software requirement that could cause unsuccessful qualification and/or aircraft verification efforts. The contractor shall convey results of the review and suggested changes using the TSC/TRB process. The contract or shall support a combined Preliminary Design Review (PDR) / Critical Design Review (CDR).

A00B Software Design Description (SDD) N/A DI-IPSC-81435B A00C Interface Design Description (IDD) N/A DI-IPSC-81436A

4.4.8 PFS/EASTE/EWAISF System Integration Test

In accordance with PWS/task description, the contractor shall support system software integration testing by:

• reviewing test procedures

• executing test procedures

• performing data analysis

• reporting test results and problems

• Supporting anomaly investigation of system failures to isolate faults to hardware, software, test setup, or associated equipment problems.

• Providing initial investigation of EPRs discovered during Avionics Integration Support

Facility (AISF) testing.

The contractor shall staff the lab such that the AFLCMC/WNY approved schedule of test execution in the EWAISF is maintained. The contractor shall incur zero (0) business days schedule slip due to formal test phases due to poor planning or execution of test activities by the contractor. The contractor shall review the software integration test description and test report to determine whether any of those tests could adequately verify the system level requirement. The contractor shall suggest changes to the integration testing that would allow system level verification at the integration test level possible, where appropriate. The contractor shall also

Contract PR FD2060-23-30042 PWS REV: 0 14 suggest modifications to the software integration testing to increase fault detection at this level.

Engineering documentation submitted by the contractor shall be technically accurate, requiring no more than one (1) revision after the initial submission due to technical inaccuracies.

The contractor shall review the system integration and functional test description and test report to determine whether any of those tests could adequately verify the system level requirement.

The contractor shall suggest changes to the testing that would allow system level verification at the system integration and functional test level possible, where appropriate. The contractor shall also suggest modifications to this testing to increase fault detection at this level. Changes shall be submitted through the TSC/TRB process.

4.4.9 PFS/EASTE/EWAISF Merge Phase

In accordance with PWS/task description, the contractor shall support merge system integration testing by:

• reviewing test procedures

• executing test procedures

• performing data analysis

• reporting test results and problems

• supporting anomaly investigation of system failures to isolate faults to hardware, software, test setup, or associated equipment problems

• providing initial investigation of EPRs discovered during AISF testing.

The contractor shall staff the lab such that the AFLCMC/WNY approved schedule of test execution in the EWAISF is maintained. The contractor shall incur zero (0) business days schedule slip due to formal test phases due to poor planning or execution of test activities by the contractor. The contractor shall review the merged software integration test description and test report to determine whether any of those tests could adequately verify the system level requirement. The contractor shall suggest changes to the integration testing that would allow system level verification at the integration test level possible, where appropriate. The contractor shall also suggest modifications to the software integration testing to increase fault detection at this level. Engineering documentation submitted by the contractor shall be technically accurate, requiring no more than one (1) revision after the initial submission due to technical inaccuracies.

The contractor shall support a TRR for system functional testing.

The contractor shall support the merge effort of all documentation redlines provided by other development organizations in accordance with the PWS/task description. The contractor shall review all software documentation deltas provided by other development organizations to ensure the delta requirements and design data maintain or exceed the baseline software standards of accuracy, completeness, consistency, feasibility, testability, traceability, and validity, and lack ambiguity. The contractor shall deliver software development cycle documents, with red-lined modifications to the original software baseline documents which include the current software cycle contractor developed deltas and the other development organizations’ deltas.

Contract PR FD2060-23-30042 PWS REV: 0 15

In accordance with PWS/task description, the contractor shall support the system integration testing of the merged product. The contractor shall support a Test Readiness Review (TRR) for system functional testing per this PWS.

4.4.10 PFS/EASTE/EWAISF System Functional Test

In accordance with PWS/task description, the contractor shall support system functional testing by:

• reviewing test procedures

• executing test procedures

• performing data analysis

• reporting test results and problems

• supporting anomaly investigation of system failures to isolate faults to hardware,

• providing initial investigation of EPRs discovered during AISF testing schedule slip to formal test phases due to poor planning or execution of test activities by the contractor. The contractor shall review the system integration and functional test descriptions and test report to determine whether any of those tests could adequately verify the system level requirement. The contractor shall suggest changes to functional testing that would allow system level verification at the functional test level possible, where appropriate. The contractor shall also suggest modifications to the software integration testing to increase fault detection at this level. Engineering documentation submitted by the contractor shall be technically accurate, requiring no more than one (1) revision after the initial submission due to technical inaccuracies.

The contractor shall support a System Functional Test (SFT) to demonstrate that the software product meets the system requirements and performs adequately for field use in accordance with PWS/task description. The contractor shall support a TIM describing the test results, deficiencies identified and analyzed, deficiency analysis recommendations with supporting technical basis, and lessons learned per this PWS.

4.4.11 EWAISF Software Test Cycle Support

In accordance with PWS/task description, the contractor shall support the formal software test cycle by:

• reviewing test procedures

Contract PR FD2060-23-30042 PWS REV: 0 16

• executing test procedures

• performing data analysis

• reporting test results and problems

• supporting anomaly investigation of system failures to isolate faults to hardware, software, test setup, or associated equipment problems

• providing initial investigation of EPRs discovered during IFAST testing execution in the EWAISF is maintained. A notional schedule is included for reference only.

The contractor shall incur zero (0) business days schedule slip to formal test phases due to poor planning or execution of test activities by the contractor. The contractor shall capture all data generated within the following subtasks in the DAL. The contractor shall report the status on each sub task in the monthly status report.

4.4.12 PFS/EASTE/EWAISF Qualification and Field Testing

The contractor shall support accomplishment of testing following system integration and functional test, in accordance with PWS/task description. Qualification and field testing typically consists of:

• Flight Emulation Test

• Compatibility and Integration Testing

• Independent Verification and Validation (IV&V)

• Aircraft Ground Testing

• Flight Testing

In accordance with PWS/task description, the contractor shall support TRRs for qualification and field testing.

Support of testing includes, but is not limited to: logistics planning, CEESIM scenario development, lab reconfiguration, test execution participation, anomaly investigation, mockup troubleshooting, data reduction, data analysis, and special test equipment operation.

The contractor shall develop and deliver an overall system level test report encompassing the results of all qualification and field test activities. Contractor performance requirements for specific test phases follow.

In accordance with PWS/task description, the contractor shall perform data reduction and analysis of captured test data to verify the software achieves system requirements and that no

Contract PR FD2060-23-30042 PWS REV: 0 17 system deficiencies were introduced. The contractor shall identify deficiencies and data analysis results in accordance with the program’s SDP. The contractor shall document and deliver the results of the test phase to the responsible entity for delivering the respective test phase’s software test report, as defined in the SDP.

The contractor shall document and deliver the results of each test type in a summary report, which will cite:

• Tests executed, date executed, and summary test results

• Tests not attempted and supporting details

• List of tests not successfully passed and supporting details

• List of anomalies encountered that did not adversely affect test results

The contractor shall be allowed zero (0) EPRs attributed to test setup, incorrectly programmed CEESIM scenarios, or improperly executed test procedures.

The contractor shall be allowed zero (0) in-scope EPRs written during aircraft test phases that are potentially identifiable in the lab. The contractor shall be allowed five (5) in-scope EPRs written during lab test phases that are potentially identifiable in earlier lab (unit, software integration, system integration, FQT) test phases. The contractor shall report the status on each test phase in the monthly status report of paragraph 4.14.2.

A007 Scientific and Technical Reports Summary

4.4.13 PFS /EWAISF Flight Emulation Testing

The contractor shall develop and deliver the Flight Emulation Testing (FET) procedures, with requirements derived from the flight test descriptions delivered by the 412 Test Wing, Edwards

AFB.

The contractor shall support a TRR for FET per this PWS.

The contractor shall support execution of FET activities, to include lab execution participation, Combat Electromagnetic Environment Simulator (CEESIM) scenario development, mockup troubleshooting, and special test equipment operation.

The contractor shall perform data reduction and analysis of captured FET data to verify the software achieves system requirements and that no system deficiencies were introduced. The contractor shall identify deficiencies and data analysis results in accordance with the program’s SDP. The contractor shall document and deliver the results of the flight test phase in a test

Contract PR FD2060-23-30042 PWS REV: 0 18

The contractor shall support a technical briefing describing the test results, deficiencies identified and analyzed, deficiency analysis recommendations with supporting technical basis, and lessons learned per Paragraph 4.5.1.

A00K Software Test Description (STD) System Test Procedures DI-IPSC-81439A

4.4.14 PFS/EASTE/EWAISF Aircraft Ground Checkout (I&CO)

The contractor shall develop and deliver the aircraft ground I&CO procedures, with test requirements derived from the PRS candidates and SSS red-lined requirements.

The contractor shall support a TRR for I&CO per this PWS. The contractor shall support execution of at least two I&CO activities, to include test logistics planning support, CEESIM scenario and other support equipment emitter/scenario development, and procedure execution.

The contractor shall perform data reduction and analysis of captured data to verify the software achieves system requirements and that no new system deficiencies were introduced. The contractor shall identify deficiencies and data analysis results in accordance with the program’s SDP. The contractor shall document and deliver the results of each I&CO in a test report.

The contractor shall support a technical briefing describing the test results, deficiencies identified and analyzed, deficiency analysis recommendations with supporting technical basis, and lessons learned per this PWS.

4.4.15 PFS Flight Testing

The contractor shall support execution of Flight Test activities, to include lab execution participation, CEESIM scenario development, mockup troubleshooting, special test equipment operation, and range support in accordance with the PWS/task description. The contractor shall thoroughly review all flight test related products such as Integrated Flight Test Plan (IFTP), flight test point matrices, and run cards for accuracy and coverage of associated system/software requirements. The contractor shall execute all proposed flight test procedures in a lab environment prior to any aircraft flight test evolution.

The contractor shall perform data reduction and analysis of captured flight test data to verify the software achieves system requirements and that no system deficiencies were introduced. The contractor shall identify deficiencies and data analysis results in accordance with the program’s SDP. The contractor shall document and deliver the results of the flight test phase in a test report within 30 calendar days after completion of the flight test. The contractor shall support a technical briefing describing the test results, deficiencies identified and analyzed, deficiency analysis recommendations with supporting technical basis, and lessons learned per this PWS.

Contract PR FD2060-23-30042 PWS REV: 0 19

4.4.16 AN/ALQ-161A and AN/ALM-280 Test Management

The contractor test manager shall technically manage contractor work efforts and B-1B DAS test programs in accordance with the PWS/task description. Test management shall include planning, developing, executing, assessing, and reporting status of all test activities in coordination with the DAS lead engineer and designated project software manager (PSM). The contractor test manager shall demonstrate working knowledge of Department of the Air Force Directive (DAFD) 99-1 (Test and Evaluation Process) and Department of Defense Instruction (DoDI) 5000.89/Department of the Air Force Instruction (DAFI) 99-103 (Capabilities-Based Test and Evaluation) while performing the following Test Representative (TESTREP) [defined in Air Force Instruction (AFI) 99-103 Supp (Test Management)] duties:

• Advises AFLCMC/WNY on issues related to test infrastructure requirements and test resource availability.

• Advise and assist AFLCMC/WNY in the formulation of test and evaluation (T&E) policies, strategies, plans, processes, and other related T&E documentation, including T-2 packages.

• Plan test programs, accounting for manpower, machines, methods and materials requirements.

• Generate and maintain test schedules.

• Track and report test progress.

• Prepare presentations and documents for test discussions.

• Plan and conduct laboratory-test TRRs, DAS Integrated Test Teams (ITT), and other test-related meetings in accordance with the PWS/task description.

• Participate in Configuration Control Boards (CCB), TRBs, TSCs, B-1B ITTs, Global

Power Bomber TIMs, test management councils, product improvement working groups, and meetings that may identify new test requirements.

• Coordinate test activities with Participating Test Organizations (PTO) to ensure required expertise and capabilities.

• Provide physical oversight and assistance, when authorized, at test execution locations to ensure that tests are conducted in accordance with approved test plans, test procedures, and safety documentation.

• Plan, provision for, execute, analyze and report on test activities assigned to all B-1B DAS laboratories and aircraft.

• Technically evaluate all test procedures and methodologies to ensure the most efficient test strategies are executed.

• Technically evaluate all test result products (including test data sheets, data analyses, test reports) to ensure the product under test has been properly qualified and/or verified.

• Coordinate with the Tinker System Program Office (SPO), and perform all required activities with respect to T-2 clearances, Military Flight Release (MFR), Air Worthiness (AW) determinations, Software product Computer Program Identification Number

Contract PR FD2060-23-30042 PWS REV: 0 20

(CPIN) registrations and any associated meetings/CCBs to include the generation of any documentation required for those activities.

Formal test cycles [Formal Qualification Test (FQT), FET, Compatibility & Integration (C&I), and aircraft] shall incur zero (0) business days schedule slips due to poor planning or execution of test activities by the contractor test manager. Formal tests shall miss zero (0) test objectives due to poor planning and/or executing of test activities by the contractor test manager.

As specified by AFMCI 99-103 (Test Management), the TESTREP shall be co-located at the product center (AFLCMC); thus, the contractor aiding in the performance of TESTREP duties shall also be located at the product…