Final_PWS_18-31300_Signed.pdf

PR: FD2060-18-31300 PWS REVISION: 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)

Purchase Request: FD2060-18-31300

17 Aug 2018

APPROVED BY: ROBERT J. CUSHING, NH-03, DAF

CHIEF, EW BOMBERS PROGRAM OFFICE

ELECTRONIC WARFARE AND AVIONICS PROGRAM OFFICE

AFPEO AGILE COMBAT SUPPORT

DISTRIBUTION STATEMENT D: Distribution authorized to U.S. Government Agencies and their contractors (Critical Technical) (12 Feb 14). Other requests for this document shall be referred to

AFLCMC/WNKC, 235 Byron Street, Suite 19A, Robins AFB, GA 31098-1670. 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.

PR: FD2060-18-31302 PWS REVISION: 0 i

Table of Contents 1 Description of Services

1.1 Objective(s)

1.2 Benefit to United States Air Force (USAF)

1.3 Background

2 Services Summary

3 Government Property

3.1 Contractor Responsibility

3.2 Government Property to be Provided

3.3 Loss of Government Property

3.3.1 Definition of Loss of Government Property

3.3.2 Reporting Loss of Government Property

3.4 Return or Retention of Government Property

3.5 System Access

4 Technical Requirements

4.1 PFS Technical Inquiries

4.2 PFS Deficiency Analysis

4.3 PFS Deficiency Analysis Plan

4.4 PFS Deficiency Analysis Execution

4.5 EASTE Software Development Cycle Support

4.6 PFS Software Test Cycle Support

4.6.1 PFS Qualification and Testing

4.6.2 PFS Software Block Cycle Candidate Selection

4.6.3 PFS Project Planning

4.6.4 PFS System Requirements Definition

4.6.5 PFS Software Requirements Definition

4.6.6 PFS Architectural and Detailed Design Definition

4.6.7 PFS System Integration Test

4.6.8 PFS Merge Phase

4.6.9 PFS System Functional Test

4.6.10 PFS Qualification and Field Testing

4.6.11 PFS Flight Emulation Testing

4.6.12 PFS Aircraft Ground Checkout (I&CO)

4.6.13 PFS Flight Testing

4.6.14 AN/ALQ-161A Test Management

4.6.15 Laboratory and Equipment Maintenance

4.7 EWAISF PFS Development Cycle Support

PR: FD2060-18-31302 PWS REVISION: 0 ii

4.7.1 EWAISF Software Block Cycle Candidate Selection

4.7.2 EWAISF Project Planning

4.7.3 EWAISF System Requirements Definition

4.7.4 EWAISF Software Requirements Definition

4.7.5 EWAISF Architectural and Detailed Design Definition

4.7.6 EWAISF System Integration Testing

4.7.7 EWAISF Merge Phase

4.7.8 EWAISF System Functional Test

4.7.9 EWAISF Software Test Cycle Support

4.7.10 EWAISF Qualification and Field Testing

4.7.11 EWAISF Software Fielding Support

4.8 Software Engineering Sustainment Support

4.8.1 Facilitator Role

4.8.2 Program Status Notebooks (PSN)

4.8.3 Master Program Schedules (MPS)

4.8.4 Master Status Notebook

4.8.5 Engineering Problem Report (EPR) Databases

4.8.6 Warner Robins Problem Report (WRPR) Database

4.8.7 Test/Data Tracking Sheets

4.8.8 Laboratory Tool Development & Improvement

4.8.9 Classified Material Control

4.8.10 Documentation and Configuration Control

4.8.11 Shipping & Receiving

4.8.12 Material Purchase

4.9 Period and Place of Performance

4.9.1 Contract/Order Period of Performance

4.9.2 Place of Performance

4.10 Contract Data Requirements List(s) (CDRL)

4.10.1 Quality of CDRL Deliverable

4.10.2 Receipt of CDRL Deliverable

4.10.3 Contract Deliverables Matrix

4.11 Technical Order/Manual Update Support

4.12 Holidays and Facility Closings

4.13 Travel

4.13.1 Meetings and Travel

4.13.2 Travel Costs

PR: FD2060-18-31302 PWS REVISION: 0 iii

4.14 Program Management

4.14.1 Data Accession List (DAL)

4.14.2 Monthly Status Report

4.14.3 Cost Reporting

4.14.4 Technical Interchange Meetings (TIM)

4.14.5 Quarterly Performance Review

4.14.6 Program Management Reviews (PMR)

4.15 Systems Software Engineering

4.16 Software Configuration Management

4.17 Software Quality Assurance

4.18 Software Engineering Group (SEG) Membership

4.19 Technical Review Board (TRB) Membership

4.20 Post Award Conference

5 General Information

5.1 Continuation of Mission-Essential Services During a Crisis

5.1.1 Definition of Mission-Essential Services

5.1.2 Designation of Services as Mission-Essential

5.2 Security Requirements

5.2.1 Security Regulations

5.2.2 Operations Security (OPSEC)

5.2.3 Communications Security (COMSEC)

5.2.4 Security Clearance

5.2.5 Security Incident or Violation

5.2.6 Access to Government System(s)

5.2.7 Access to Government Facility or Military Installation

5.2.8 Access to Robins Air Force Base (AFB)

5.2.9 Common Access Card (CAC)

5.3 Environmental Management System (EMS)

5.4 Agency Affirmative Procurement Programs

5.5 Safety Requirements

5.5.1 Contractor Compliance

5.5.2 Mishap Notification/Investigation

5.5.3 Safety and Health Plan/Program

5.6 Inspection of Services

5.6.1 Government Inspection Rights

5.6.2 Invoking Inspection of Services Clauses

5.6.3 Inspection Process

PR: FD2060-18-31302 PWS REVISION: 0 iv

5.7 Quality Management System (QMS)

5.8 Invoicing/Payment and Receipt/Acceptance

6 Appendices

6.1 Appendix A, Reference(s)

PR: 2060-18-31300

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). These services include: (1) to acquire engineering support services for the

AN/ALM-280, commonly referred to as the Enhanced Automated Special Test Equipment (EASTE); (2) to 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) to acquire engineering and configuration management support for the B-1B DAS sustainment efforts along with maintaining the Electronic Warfare Avionics Integrated Support Facility (EWAISF) for Avionics Testing and defensive line test equipment.

1.2 Benefit to United States Air Force (USAF)

This acquisition will benefit the USAF by providing software updates for testing of B-1B DAS, Engineering test support and Field testing to meet mission requirements.

1.3 Background

The contractor shall support AFLCMC/WNY, the Product Group Manager (PGM) for the AN/ALQ-161A 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 projects.

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 shall provide engineering test support for other software system products which are directly impacted by or related to the PFS as directed by AFLCMC/WNY. These software products may include, but are not limited to, Emitter Identification Data (EID), Emitter Reprogramming Software

(ERS), AN/ALM-280 EASTE software, Mission Data Load Tool (MDLT) software, Line Replaceable

Unit (LRU) firmware, and system lab and data analysis tools.

The PFS development and integration cycle consists of the following software upgrade block cycle phases:

1. Project Planning

2. Requirements Definition

3. Preliminary Design

4. Critical Design

5. Code

6. Unit Test

7. Software Integration Test

8. Documentation and Code Merge

9. Delta Unit Test

10. Delta Software Integration Test

11. System Integration Test

12. System Functional Test

The PFS qualification and field test cycle consists of the following standard upgrade block cycle phases.

1. Formal Qualification Test

2. Flight Emulation Test

3. Aircraft Test

4. Functional Configuration Audit (FCA)/Physical Configuration Audit (PCA)

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 shall perform 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).

The contractor shall support AFLCMC/WNY, the PGM for the AN/ALQ-161A system and AN/ALM-

280 software, by participating in all phases of the multi-year sustainment effort. 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 AN/ALQ-161A system technical authority and has

OSS&E responsibility. AFLCMC/WNY is the overall AN/ALM-280 Test Program Set (TPS) technical authority and has OSS&E responsibility. AFLCMC/WNY has program management responsibilities for all AN/ALQ-161A projects as well as AN/ALM-280 TPS sustainment. AFLCMC/WNA has overall technical authority for the AN/ALM-280 core hardware and AN/ALM-280 core software.

2 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.

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

The contractor shall report the status of each analysis investigation in the monthly status report.

4.2

4.4

4.10.1

Reports shall be technically accurate with no more than one (1) technical error per report. 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. 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.6.14 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

4.1

4.2

4.3

4.6

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

Performance Objective PWS

Reference

Performance Threshold

AN/ALQ-161A

modification programs.

4.7

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

4.1

4.2

4.3

4.6

4.7.3

4.7.4

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.2

4.6

4.8.5

4.8.6

4.19

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.1

4.2

4.3

4.11

4.14.1

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.

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

4.2

4.6

4.7.3

4.7.4

4.7.11.1

4.8.5

4.8.6

4.19

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.2

4.6

4.7.6

4.7.7

4.7.8

4.7.9

4.8.5

4.8.6

4.19

The contractor shall provide initial investigation on

100% of EPRs discovered during AISF testing.

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

4.6 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.7.9

4.19

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.

Performance Objective PWS

Reference

Performance Threshold

The contractor shall maintain EPR and WRPR databases.

4.2

4.6

4.8.5

4.8.6

4.19

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.6

4.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

The contractor shall conduct acceptable

Contractor Safety

Program.

5.5.3 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.

5.2 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 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 one (1) rejection of each

deliverable. There shall be no more than five (5) total rejection(s) of deliverables per quarter. The

Government will reject a deliverable if one (1) or more 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 defined as 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.

Adherence to Contractor the QMS

4.14

4.17

5.7

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.

3 Government Property

3.1 Contractor Responsibility

The Contractor shall be responsible for Government property in their possession in accordance with the

Federal Acquisition Regulation (FAR) and applicable supplements including, but not limited to, FAR Part

45, Government Property; FAR 52.245-1, Government Property; and Defense Federal Acquisition

Regulation Supplement (DFARS) Part 245, Government Property. The FAR and applicable supplements can be accessed at the site below. http://farsite.hill.af.mil

3.2 Government Property to be Provided

Government property to be provided includes, but is not limited to, an EASTE cart with associated components, as well as a Portable Automatic Test Equipment Calibrator (PATEC) with associated components. AFLCMC/WNY will provide current intelligence information to the Contractor as available.

In addition, the EWAISF 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 Software Test Facility (STF) 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. The official Government-Furnished Property (GFP) listing will be incorporated into the contract in Section J, List of Attachments, and all updates will be incorporated via contract modification.

3.3 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

The Contractor shall report loss of Government property using Defense Contract Management Agency

(DCMA) / Access to eTools. The reporting requirement does not change any liability provisions or other reporting requirements that may exist under the contract/order. http://www.dcma.mil/aboutetools.cfm

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.

http://farsite.hill.af.mil/ http://www.dcma.mil/aboutetools.cfm

3.5 System Access

The Government will provide Contractor personnel access to systems necessary to perform tasks under the contract/order. The Contractor shall ensure Contractor personnel who require access to an unclassified or classified Automated Information System (AIS) have the appropriate background check or security investigation conducted. The Government will provide system access subject to approval of the

Department of Defense (DD) Form 2875, System Authorization Access Request (SAAR). Upon completion/termination of the contract/order or transfer/termination of Contractor personnel, the system account will be closed

4 Technical Requirements The 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 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 technical Point of Contact (POC) of any inquiry requiring more than 16 hours work effort.

The contractor shall support anomaly investigations at the discretion of the 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 of Paragraph 4.14.2, 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. (DI-MGMT-80368A/T, Status Report)

4.2 PFS 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 as directed by AFLCMC/WNY. The contractor shall document each deficiency analysis investigation as directed by AFLCMC/WNY deficiency analysis plan (Paragraph 4.3) and the results of each deficiency analysis (Paragraph 4.2).

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 with no more than one (1) technical error per report. Following receipt of all comments, reports shall require no more than one (1) revision per report after the initial submittal. (DI-MISC-80048/T, Scientific and Technical Reports Summary)

4.3 PFS Deficiency Analysis Plan

The contractor shall develop and deliver a Deficiency Analysis Plan on each candidate assigned by

AFLCMC/WNY. At a minimum, the plan shall cite the following:

Top level problem description

Focus of deficiency analysis effort

Related problem reports

Facility requirements for investigation

Time estimate for investigation

Baseline software configuration

Baseline hardware configuration

Investigative approach (including alternates as applicable) including o Technical and operational performance improvements o Technical and operational performance limitations o Technical risks o Interoperability impacts

Assessed impacts to PFS interface

Assessed impacts to Avionics Flight Software (AFS) interface

Assessed impacts to LRU firmware

Assessed impacts to the EID, Emitter Reprogramming

Manual (ERM) and ERS

Assessed impacts to other related configurable items (lab tools, analysis tools, operational tools, maintenance tools) (DI-MISC-80048/T, Scientific and Technical Reports Summary)

4.4 PFS Deficiency Analysis Execution

Following receipt of AFLCMC/WNY written-approval of the deficiency analysis plan, the contractor shall perform the analysis effort per the plan. The contractor shall document, design, code, and test software changes in an effort to characterize the critical paths of an identified problem set, develop a prototype solution set, and then demonstrate the solution set for validation. During deficiency analysis, the contractor shall:

Identify applicable System/Subsystem Specification (SSS) requirements and applicable changes

Derive lower level system performance requirements

Identify applicable Software Requirements Specification (SRS) requirements and applicable changes

Perform and document a detailed causal analysis of the problem

Develop prototype software solution(s) per the approved analysis plan

For each prototype solution o Generate design deltas from the software configuration baseline o Generate source code o Identify number of subsystems, classes, subclasses and modules modified o Identify Source Lines of Code (SLOC) estimates o Identify interoperability impacts (i.e., PFS, AFS, Flight Data Recorder (FDR), LRU firmware, EID, ERM and ERS impacts) o Identify impacts to operational procedures, where applicable o Identify impacts to maintenance procedures, where applicable o Identify impacts to other related configurable items (development, verification, validation tools) o Develop and/or identify functional tests to verify technical adequacy of the prototype solution(s) o Develop, document and execute qualification level tests against the prototype solution(s) requirements o Perform qualitative and/or quantitative data analysis, as applicable, for the executed tests o Identify limitations of prototype tests, where applicable o Identify performance deltas between baseline software configuration and prototyped solution o Identify technical and operational performance improvements for each prototype solution o Identify technical and operational performance limitations for each prototype solution o Identify risk assessment of the solution for incorporation into the next software block cycle

The contractor shall perform testing to evaluate the prototype software for operational performance. The contractor shall ensure that baseline performance is retained; that design improvements satisfy the minimum performance requirements; and that risk is sufficiently reduced, ensuring a successful implementation in a block cycle program in the future. No more than 5% of scheduled regression tests shall fail due to problems induced by the prototype solution. This metric will be calculated quarterly. The deficiency analysis testing shall consist of:

Initial lab test to determine existing functional capabilities and deficiencies

Intermediate lab test to evaluate potential solutions

Final lab and/or field test to determine overall solution adequacy The contractor shall submit problems detected during testing and data analysis in the form of Engineering

Problem Reports (EPR) to the AFLCMC/WNY technical point of contact.

The contractor shall submit a Deficiency Analysis Report to document the results of the analysis. The report shall include recommended solutions, updates to requirements, design and test documentation, risk assessment, operational and maintenance impacts, and all lab results. These reports shall be submitted and approved by the AFLCMC/WNY technical point of contact. After approval, the contractor shall provide source data inputs to update the EASTE problem report database. The contractor shall also list the tested prototype code and executables in the Data Accession List (DAL), paragraph 4.14.1.

4.5 EASTE Software Development Cycle Support

The contractor shall support the following EASTE development cycles as directed by AFLCMC/WNY.

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 of Paragraph 4.14.1. 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 of Paragraph 4.14.2.

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

• EASTE Block Cycle Candidate Selection

• EASTE Project Planning

• EASTE System Requirements Definition

• EASTE Software Requirements Definition

• EASTE Architectural and Detailed Design Definition

• EASTE Implementation, Integration and System Functional Test

• EASTE Field Testing

• EASTE Software Fielding Support

• EASTE FCA/PCA Phase

• EASTE FCA/PCA Audit

4.6 PFS Software Test Cycle Support

The contractor shall support the test cycle for the AN/ALQ-161A subsystem as directed by

AFLCMC/WNY. The contractor shall capture all data generated within the following subtasks in the

DAL of Paragraph 4.14.1. 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) major revision per document after the initial submission due to technical inaccuracies.

4.6.1 PFS 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, including PFS 6.20, 6.30, 6.35, and 6.40.

The contractor shall provide engineering test support for other software system products which are directly impacted by or related to the PFS as directed by AFLCMC/WNY. 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 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. (DI-IPSC-81440A, Software Test Report)

4.6.2 PFS Software Block Cycle Candidate Selection

The contractor shall support the software block cycle candidate selection process, whereby they shall participate as an 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 capture and deliver technical test data for input into the project requirements specification. The contractor shall support a Block Cycle Candidate Selection meeting per Paragraph

4.13.1.

4.6.3 PFS Project Planning

The contractor shall participate in the project planning efforts of the development organization(s), as directed by AFLCMC/WNY and paragraph 4.8.2

4.6.4 PFS System Requirements Definition

The contractor shall participate in the system requirements definition efforts of the development organization(s), as directed by AFLCMC/WNY and paragraph 4.8.3. (DI-IPSC-81431A, System/Subsystem Specification; DI-ATTS-80041A, Test Requirements Document; DI-ATTS-

80285C/T, Engineering Support Data)

4.6.5 PFS Software Requirements Definition

The contractor shall participate in the software requirements definition efforts of the development organization(s), as directed by AFLCMC/WNY and paragraph 4.8.4. 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 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 Technical Screening Committee (TSC) and Technical Review Board (TRB) process.

The contractor shall support a combined System Specification Review (SSR) / Software Requirements

Review (SRR) per Paragraph 4.13.1. (DI-IPSC-81433A, Software Requirements Specification; DI-

IPSC-81434A, Interface Requirements Specification)

4.6.6 PFS Architectural and Detailed Design Definition

The contractor shall participate in the design definition efforts of the development organization(s), as directed by AFLCMC/WNY and paragraph 4.8.5. 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. (DI-IPSC-81435A, Software Design Description; DI-IPSC-81436A, Interface

Design Description; DI-IPSC-81437A, Database Design Description)

4.6.7 PFS System Integration Test

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.6.8 PFS Merge Phase

The contractor shall support the merge effort of all documentation redlines provided by other development organizations as directed by AFLCMC/WNY. 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.

As directed by AFLCMC/WNY, 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

Paragraph 4.13.1.

4.6.9 PFS System Functional Test

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 as directed by AFLCMC/WNY. 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 Paragraph 4.14.4.

4.6.10 PFS Qualification and Field Testing

The contractor shall support AFLCMC/WNY accomplishment of additional testing following SFT. The contractor shall deliver applicable data for this work effort. Qualification and field testing may consist of:

Flight Emulation Test

Aircraft Ground Testing (includes I&CO)

Flight Testing 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.

(DI-IPSC-81440A, Software Test Report)

4.6.11 PFS 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 Paragraph 4.5.1.

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 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

Paragraph 4.5.1. (DI-IPSC-81439A, Software Test Description; DI-IPSC-81440A, Software Test

Report)

4.6.12 PFS 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 Paragraph 4.5.1. 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

4.6.13 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 as directed by AFLCMC/WNY. 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.

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

4.6.14 AN/ALQ-161A Test Management

The contractor test manager shall technically manage contractor work efforts and B-1B DAS test programs as directed by AFLCMC/WNY. 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 Air Force Policy Directive (AFPD) 99-1 (Test and Evaluation Process) and Air Force

Instruction (AFI) 99-103 (Capabilities-Based Test and Evaluation) while performing the following Test

Representative (TESTREP) [defined in Air Force Materiel Command Instruction (AFMCI) 99-103 (Test

Management)] duties:

Advise 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 as identified by AFLCMC / WNYEBA.

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

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

Formal test cycles [Final Qualification Test (FQT), FET, Compatibility & Integration (C&I), 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 center. The contractor shall identify the contractor test manager within 30 calendar days of contract award.

4.6.15 Laboratory and Equipment Maintenance

For the purposes of this work effort the entity referred to as the laboratory shall be defined as:

AN/ALQ-161A hardware/LRUs contained within the Integration Facilities (IFAST and

EWAISF).

ASQ-184 Controls and Displays Subsystem (CADSS) and Integrated Battle Station (IBS) hardware required to simulate the B-1B EW suite (IFAST and EWAISF).

Test tools (Avionics Simulation (AVSIM), CEESIM, Measurement and Verification

System (MAVS), Ground Flight Recording System (GFRS), etc.) permanently connected to the AN/ALQ-161A used by the EWAISF at Robins AFB, REWST at Eglin AFB, and

IFAST at Edwards AFB.

Installed LRU cooling systems with their associated plumbing within the IFAST and

EWAISF labs.

All associated interconnecting cables within the IFAST and EWAISF labs.

The contractor shall support the Government in maintaining the defensive flight line test equipment and shall perform the following work efforts, at a minimum, for the IFAST laboratory at Edwards AFB and

EWAISF laboratory at Robins AFB:

Maintain the laboratory in a safe and operational state

Maintain all major hardware to support the development, integration, and test of programs to include AN/ALQ-161A and associated hardware [Closed Loop Amplitude

Set-on (CLAMPS) Plates, Radio Frequency (RF) Leakage Arrays, Antenna Direction

Receiver Multiplexer (ADR MUX) Box, Defensive Management Subsystem Simulation

(DMSS) Box, 1122 Upgrade System and Computer Control Systems (CCS), etc.]

Maintain and document hardware configuration control

Maintain documentation control of lab hardware

Record logbook entries to document anomalies/failures and corrective action taken

Troubleshoot performance related issues down to the LRU level

Support calibration of the AN/ALM-280 EASTE

Notify the local Government organization and prepare transfer of equipment out of calibration to PMEL

Perform scheduled maintenance on the AN/ALQ-161A LRU Oil Cooling System including daily, monthly and annual inspections (at IFAST, flow and filter components only)

Perform data backup and ensure current backups are on file for various test tools

(AVSIM, CEESIM, MAVS, GFRS, etc.) permanently connected to the AN/ALQ-161A

Perform application software backups and ensure current backups are on file for various test tools permanently connected to the AN/ALQ-161A (not including CEESIM)

Provide GFP and Government Furnished Material (GFM) material handling services

(including shipping, auditing, documenting utilization and consumption reporting) in support of the laboratory and aircraft tests

Perform troubleshooting procedures on LRUs that are deemed less than serviceable prior to turn-in for replacement (The contractor shall identify all confirmed hardware failures to AFLCMC/WNY technical personnel.)

Maintain the IFAST and EWAISF in a neat and orderly fashion per organizational standards

Purchase and provide consumable items and supplies as needed for IFAST and EWAISF operation and maintenance

The contractor shall not be responsible for the repair of any failed LRUs nor support equipment (e.g., AN/ALQ-161A LRU Oil Cooling Unit and 230 VAC 400 Hz Motor Generator). For these items, the contractor shall provide only preventive maintenance.

The contractor shall support a LEAN event to organize and catalog all materials, test equipment and operational equipment in the defensive mockup area of the IFAST.

The contractor shall support the Government in maintaining software tools needed to support the development, integration, and test of software and hardware upgrade programs associated with the

AN/ALQ-161A and associated lab hardware.

4.7 EWAISF PFS Development Cycle Support

The contractor shall support the PFS development cycle for the AN/ALQ-161A subsystem as directed by

AFLCMC/WNY. The contractor shall capture all data generated within the following subtasks in the

DAL of Paragraph 4.14.1. Additionally, the contractor shall participate in meetings related to other government organizations or contractor work products as directed by AFLCMC/WNY.

The contractor shall report the status of the following subtasks in the monthly status report of Paragraph

4.14.2. The contractor shall maintain a list and report the documents reviewed and the technical reviewer.

4.7.1 EWAISF Software Block Cycle Candidate Selection

The contractor shall support the software block cycle candidate selection process, whereby they shall participate as an 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) ο 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 meeting per Paragraph 4.13.1.

4.7.2 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.

4.7.3 EWAISF System Requirements Definition

The contractor shall review the redlined 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 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 provide quality technical reviews of documentation generated during the development phase.