16-60702_D.O_1_SOW_Rev_0.pdf

Statement of Work (SOW) for

AN/ALQ-161A Operational Flight Program (OFP) 6.40

FD2060-16-60702

Revision: 0

15 January 2016

PREPARED BY: BOMBER AIRCRAFT ELECTRONIC WARFARE (EW) SYSTEMS

ENGINEERING (AFLCMC/WNYEBA)

AIRCRAFT INTEGRATED ELECTRONIC COMBAT ENGINEERING

SECTION

EW/AVIONICS DIVISION

AGILE COMBAT SUPPORT DIRECTORATE

AIR FORCE LIFE CYCLE MANAGEMENTCENTER

APPROVED BY: ROBERT J. CUSHING, GS-13, DAF

CHIEF, EW BOMBERS SECTION

ELECTRONIC WARFARE AND AVIONICS DIVISION

DISTRIBUTION STATEMENT D: Distribution authorized to U.S. Government Agencies and their Contractors (Critical Technical) (01 Apr 2015). Other requests for this document shall be referred to AFLCMC/WNKCB, Robins AFB, GA 31098- 5365. Questions concerning the technical content should be directed to AFLCMC/WNYEBA.

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 shall prevent disclosure of the contents or reconstruction of the document.

PR: FD2060-16-60702 D.O. #1 SOW REVISION: 0 i

Table of Contents

!UNEXPECTED END OF FORMULA

1.1 TECHNICAL INQUIRIES

1.2 DEFICIENCY ANALYSIS

1.3 OFP DEVELOPMENT CYCLE SUPPORT

1.3.1 Software Block Cycle Candidate Selection

1.3.2 Project Planning

1.3.3 System Requirements Definition

1.3.4 Software Requirements Definition

1.3.5 Architectural and Detailed Design Definition

1.3.6 Code, Unit Test, and Software Integration Test

1.3.7 System Integration Test (SIT)

1.3.8 Formal Qualification Test

1.4 SOFTWARE TEST CYCLE SUPPORT

1.4.1 Qualification and Field Testing

1.4.2 Software Fielding Support

1.4.2.1 FCA/PCA Planning

1.4.2.2 FCA/PCA Audit

2. SERVICES SUMMARY

3. GOVERNMENT FURNISHED PROPERTY AND SERVICES

4. TECHNICAL REQUIREMENTS

4.1 PERIOD AND PLACE OF PERFORMANCE

4.1.1 Place of Performance

4.1.2 Contract/Order Period of Performance

4.2 POST AWARD CONFERENCE

4.3 MEETINGS AND TRAVEL

4.4 DATA ACCESSION LIST (DAL)

4.5 MONTHLY STATUS REPORT

4.6 TECHNICAL INTERCHANGE MEETINGS (TIMS)

4.7 SEMI-ANNUAL PERFORMANCE REVIEW

4.8 PROGRAM MANAGEMENT REVIEWS

4.9 SYSTEMS SOFTWARE ENGINEERING

4.10 SOFTWARE CONFIGURATION MANAGEMENT

4.11 SOFTWARE QUALITY ASSURANCE

4.12 SOFTWARE ENGINEERING GROUP (SEG) MEMBERSHIP

4.13 TECHNICAL ORDER/MANUAL UPDATE SUPPORT

4.14 SUPPLIES

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 Classified/Unclassified

5.2.2 Government Security Regulations

5.2.3 Operations Security (OPSEC)

5.2.4 Communication Security (COMSEC)

5.2.5 Security Clearance

5.2.6 Security Incident or Violation

PR: FD2060-16-60702 D.O. #1 SOW REVISION: 0 ii

5.2.7 Security of Contractor System(s)

5.2.8 Access to Government Systems

5.2.9 Access to Government Facility

5.2.10 Common Access Card (CAC)

5.2.11 Access to Robins AFB

5.3 ENVIRONMENTAL MANAGEMENT SYSTEMS (EMS)

5.4 AFFIRMATIVE PROCUREMENT

5.5 SAFETY REQUIREMENTS

5.5.1 Contractor Compliance

5.5.2 Voluntary Protection Program (VPP)

5.5.3 Mishap Notification and Investigation

5.5.4 Safety & Health Plan

5.5.5 System Safety

5.5.6 Document the system safety approach

5.5.7 Identify and document hazards

5.6 INSPECTION OF SERVICES

5.7 TRAFFICKING IN PERSONS

5.8 CONTRACT MANPOWER REPORTING

5.9 INVOICING/PAYMENT AND RECEIPT/ACCEPTANCE

6. APPENDICES

6.1 APPENDIX A, REFERENCES

6.2 APPENDIX B, CONTRACT DATA REQUIREMENTS LIST

6.3 APPENDIX C, CANDIDATES

PR: FD2060-16-60702 D.O.#1SOW REVISION: 0 2

1. DESCRIPTION OF SERVICES

The purpose of this Statement of Work (SOW) is to acquire engineering support for the AN/ALQ-161A Operational Flight Program (OFP) 6.40 sustainment effort and to deliver block cycle software updates. OFP 6.40 is a block cycle effort that includes resolution of software deficiency candidates using the OFP 6.20 baseline. Once OFP

6.30 is deemed mature enough by the Government, the contractor shall merge all the changes made to OFP 6.20 required for this effort with OFP 6.30 to form the OFP 6.40 baseline required for formal qualification testing

(FQT).

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 effort. The end goal is to provide cost-efficient, quality software solutions that can be fielded in a timely manner and support the Air Force mission. AFLCMC/WNYEBA is the overall system technical authority and has Operational Safety, Suitability, and Effectiveness (OSS&E) responsibility. AFLCMC/WNYCB, also part of AFLCMC/WNY, has program management responsibilities for all AN/ALQ-161A projects.

The contractor’s primary responsibility is to identify candidates, incorporate solutions, and test the resulting OFP block cycle product per the AFLCMC/WNYEBA-approved OFP 6.40 Project Requirements Specification (PRS) and per the AFLCMC/WNYEBA-approved OFP 6.40 Software Development Plan (SDP).

The contractor shall provide engineering support for other system software products which are directly impacted by or related to the OFP as directed by AFLCMC/WNYEBA. These software products may include, but are not limited to, Emitter Identification Data (EID), Emitter Reprogramming Software (ERS), AN/ALM-280 Enhanced Automated Special Test Equipment (EASTE) software, Mission Data Load Tool (MDLT) software, Line Replaceable Unit (LRU) firmware, and system lab and data analysis tools.

The OFP 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, Unit Test, Software Test, System Integration Test

6. Formal Qualification Test

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

1. Independent Validation and Verification (IV&V)

2. Flight Emulation Test (FET)

3. Compatibility and Integration Testing (C&I)

4. Aircraft Test

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

Additionally, this task provides for contractor performance of deficiency analysis tasks associated with in-scope software candidates and problems, test adequacy and efficiency studies, and future block cycle candidates.

1.1 Technical Inquiries

The contractor shall respond to software-related inquiries from AFLCMC/WNYEBA. The contractor shall provide response within five (5) business days to all email technical inquiries. The contractor shall notify the AFLCMC/WNYEBA 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/WNYEBA, as problems arise and are deemed sufficiently complex to warrant an analysis.

Technical inquiries include the contractor’s support during software-related technical meetings as requested by

AFLCMC/WNYEBA.

PR: FD2060-16-60702 D.O.#1SOW REVISION: 0 3

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

1.2 Deficiency Analysis

Deficiency Analysis is a software sustainment risk reduction effort typically focused on analyzing prioritized software candidates scheduled for inclusion in upcoming OFP block cycles. A deficiency analysis request, however, is not limited to an OFP candidate, but may be assigned for any system-related sustainment software issue. The contractor shall document each deficiency analysis plan (Paragraph 1.2.1), and the results of each deficiency analysis (Paragraph 1.2.2) shall be presented using the AFLCMC/WNYEBA Requirements, Operational, and Test Analysis Report (ROTAR) format. The contractor shall submit each plan and each completed analysis to the Technical Screening Committee (TSC) and Technical Review Board (TRB) for review and comment by other contractors and government agencies. The contractor shall update the documents as directed by the TSC/TRB.

The contractor shall perform deficiency analyses on the candidates identified in each Delivery Order. The contractor shall be responsible for completing the Deficiency Analysis Reports (DARs) for of all candidates identified in each Delivery Order and have them presented for review and approval to the TSC/TRB prior to the Software Requirements Review (SRR). The results of the DAR and recommendations to include the candidate into the OFP block cycle in total, partially or to exclude it from inclusion into the block cycle will be presented at the SRR. The Government will make the final determinations as how to proceed based on the contractors recommendations. Final delivery by the contractor shall be submittal of the SRR package, an approved SRR briefing and Deficiency Analysis Reports briefed and/or completed by SRR.

The contractor shall also perform review of other contractor and government agency deficiency analysis products related to the ALQ-161 per the TSC/TRB processes as defined in the SDP.

The contractor shall report the status of each analysis investigation in the monthly status report, citing the subject, hours expended developing the analysis plan, performing design analysis, developing the prototype solution, testing the prototype solution, performing re-work, and documenting the effort. The contractor shall include a summary total of the number of analyses and hours expended for the entire contract in each monthly status report.

1.2.1 Deficiency Analysis Plan

The contractor shall develop and deliver a Deficiency Analysis Plan on each candidate assigned by AFLCMC/WNYEBA. The baseline software and hardware configurations shall be identified to the contractor by the AFLCMC/WNYEBA technical POC at the time of deficiency analysis assignment. As a minimum, the plan shall cite the following:

• Warner Robins Problem Report (WRPR) Number

• Title

• 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 Assessed impacts to Avionics Flight Software (AFS) interface o Assessed impacts to LRU firmware o Assessed impacts to the EID, Emitter Reprogramming Manual (ERM) and ERS

PR: FD2060-16-60702 D.O.#1SOW REVISION: 0 4

o Assessed impacts to other related configurable items (lab tools, analysis tools, operational tools, maintenance tools)

(A001, DI-MISC-81384, Service Engineering Report)

1.2.2 Deficiency Analysis Execution

Following AFLCMC/WNYEBA direction to perform each deficiency analysis, the contractor shall perform the analysis effort per the approved 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 requirements and applicable changes

• Derive lower level system performance requirements

• Identify applicable Software Requirements Specification 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 AFS interface impacts o Identify Flight Data Recorder (FDR) interface impacts, as applicable o Identify LRU firmware impacts o Identify EID, ERM and ERS impacts o Generate test Emitter Identification Data (EIDs).

o Develop prototype Developmental Southwest Asia (DSWA) and Engineering Southwest Asia

(ESWA) EIDs for use in the development and test of OFP 6.40 o Identify EASTE 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 impacts to Preprocessor Avionics Control Unit (PACU) duty cycle, where applicable o Identify risk assessment of the solution for incorporation into the next OFP 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 successful implementation in a block cycle program in the future. The deficiency analysis testing shall consist of:

• Initial lab test to determine existing functional capabilities

• Intermediate lab test to evaluate potential solutions

• Final lab and/or field test to determine overall solution adequacy

Following AFLCMC/WNY acceptance of the deficiency analysis report for a prototype solution, no more than 5% of scheduled regression tests shall fail due to problems induced by the prototype solution.

The contractor shall document all requirements identified above and the results of the deficiency analysis in a deficiency analysis report (DAR) using the AFLCMC/WNYEBA ROTAR format. The contractor shall also submit WRPR Database updates to the WRPR Database configuration manager. The contractor shall list the

PR: FD2060-16-60702 D.O.#1SOW REVISION: 0 5

tested prototype code and executables in the Data Accession List (DAL) of Paragraph 4.4.

The contractor shall also submit problems detected during the deficiency analysis in the form of Engineering Problem Reports (EPRs) or WRPRs as decided by the Technical Screening Committee (TSC)/Technical Review Board (TRB) process. Reports shall be technically accurate with no more than one (1) technical error. Following receipt of all comments, reports shall require no more than one revision after the initial submittal.

(A002, DI-MISC-81384, Service Engineering Report)

1.3 OFP Development Cycle Support

The contractor shall support the OFP development cycle for the AN/ALQ-161A subsystem as directed by AFLCMC/WNYEBA. 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.4. Additionally, the contractor shall participate in meetings related to other government organizations or contractor work products as directed by AFLCMC/WNYEBA. The contractor shall report the status and the hours expended on each 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 and hours expended (per candidate, where appropriate) for the entire contract in each monthly status report of Paragraph 4.5.

The contractor shall be responsible for incorporation of all candidates identified in Appendix C, unless the Government directs that it not be included in OFP 6.40 block cycle effort. This decision will be made no later than final approval of the Software Requirements Review (SRR) minutes and action item close-out.

The contractor shall also be responsible for delivering the final software products for the PACU, to include all software configuration items within the PACU.

1.3.1 Software Block Cycle Candidate Selection

The contractor shall support the software block cycle candidate selection process, whereby they shall participate as an Integrated Product Team (IPT) member to:

• Review the software candidate selections’ attributes:

o Assess the problem at the system performance level o Identify the required system performance requirements o Identify system operational performance benefits o Identify system performance limitations resulting from the anticipated solution o Identify existing, related system performance limitations that will not be addressed o Identify interface impacts (internal, external, flight data recorder, AFS, LRU firmware, EID, ERM, ERS) o Identify ERS requirements to develop new Emitter Identification Data (EID) files and convert existing EID files compatible for use with OFP 6.40 o Identify ESWA and DSWA EID requirements for use in the development and test of OFP 6.40 o Identify impacts to software development, verification, and validation, lab and aircraft tools o Identify the verification and validation approach o Identify affected maintenance and operational procedures o 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 the data and incorporate into a delivered PRS. The contractor shall submit the PRS to the TSC/TRB for review and comment by other contractors and government agencies.

The contractor shall support Block Cycle Candidate Selection meeting per Paragraph 4.6. (A003,DI-MISC-

PR: FD2060-16-60702 D.O.#1SOW REVISION: 0 6

80048, Scientific and Technical Reports Summary)

1.3.2 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. (A004, DI-IPSC-81427A, Software Development Plan; A005, DI-IPSC-81438A, Software Test Plan; A006, DI-MGMT-81334D, Contract Work Breakdown Structure; A007, DI-MGMT- 81861, Integrated Program Management Report)

1.3.3 System Requirements Definition

The contractor shall identify, analyze, and document the system requirements for the software candidates to be resolved by the contractor per the PRS. The contractor system requirements definition shall include full definition of the required system capabilities, identification of the system and software components required for the functionality, identification and resolution of interface impacts, and documentation of the requirements. The contractor shall document all requirements identified above using the AFLCMC/WNYEBA ROTAR format for TSC/TRB review. The contractor shall deliver a System/Subsystem Specification (SSS), with red-lined modifications to the original specification as applicable. Red-lined documents shall be technically accurate, and following receipt of all comments shall require no more than one revision after the initial submission.

(A008, DI-IPSC-81431A, System/Subsystem Specification; A00E, DI-MISC-81384, Service Engineering Report)

1.3.4 Software Requirements Definition

The contractor shall identify, analyze, and document the software and interface requirements for the software candidates to be resolved by the contractor per the PRS. The contractor software requirements definition shall include full definition of the required software capabilities, identification of the software components required for the functionality, identification of interface requirements, and documentation of the requirements. The contractor shall document all requirements identified above using the AFLCMC/WNYEBA ROTAR format for TSC/TRB review. The contractor shall deliver a Software Requirements Specification (SRS) and an Interface Requirements Specification (IRS), with red-lined modifications to the original specifications as applicable. Red-lined documents shall be technically accurate, and following receipt of all comments shall require no more than one revision after the initial submission.

The contractor shall support a combined System Specification Review (SSR) / Software Requirements Review (SRR) per Paragraph 4.3. The contractor shall not proceed to the design phase (Paragraph 1.3.5) until the AFLCMC/WNYEBA technical POC acknowledges successful completion of the SSR/SRR.

(A009, DI-IPSC-81433A, Software Requirements Specification; A00A, DI-IPSC-81434A, Interface Requirements Specification; A00E, DI-MISC-81384, Service Engineering Report)

1.3.5 Architectural and Detailed Design Definition

The contractor shall allocate the documented software requirements into architectural, database, interface and detailed design, as applicable, for the software candidates to be resolved by the contractor per the PRS. Top-level design issues shall be identified with planned mitigations. The contractor shall develop preliminary test plans. The contractor shall document all requirements identified above using the AFLCMC/WNYEBA ROTAR format for TSC/TRB review. The contractor shall deliver design documents, with red-lined modifications to the original design documents as applicable data. Red-lined documents shall be technically accurate, and following receipt of all comments shall require no more than one revision after the initial submission.

The contractor shall also develop and deliver system-level test descriptions to qualify the candidates the contractor is to resolve.

The contractor shall support a combined Preliminary Design Review (PDR) / Critical Design Review (CDR) per Paragraph 4.3. The contractor shall not proceed to the code and test phase (Paragraph 1.3.6) until the

PR: FD2060-16-60702 D.O.#1SOW REVISION: 0 7

AFLCMC/WNYEBA technical POC acknowledges successful completion of the PDR/CDR.

(A00B, DI-IPSC-81435A, Software Design Description; A00C, DI-IPSC-81436A, Interface Design Description)

1.3.6 Code, Unit Test, and Software Integration Test

The contractor shall generate source code for the software candidates and the OFP 6.40 compatible ESWA and DSWA EIDs to be resolved by the contractor per the PRS using the AFLCMC/WNYEBA approved design from Paragraph 1.3.5. The contractor shall recommend any design changes differing from the PDR/CDR approved-design to the AFLCMC/WNYEBA technical POC via the EPR process. The contractor shall maintain the originally approved design unless the alternate recommendation is approved via the TSC process. The contractor shall code and document the source code files per the approved coding standards as defined in the approved SDP of Paragraph 1.3.2.

The contractor shall test all modified source code files at the unit level per the SDP. The contractor shall use unit-level test procedures that are documented, repeatable, and provide maximum comprehensive testing. The contractor shall verify and report unit test results in the Integration Test Report.

The contractor shall integrate source code for the block cycle software candidates per the SDP. The contractor shall integrate and test the integrated candidates in a black-box fashion, focusing on the requirements to be met by the candidates..

Subsequent dependent module testing may be accomplished with other modules that have already been integrated. The contractor shall verify and report software integration test results in the Integration Test Report.

The contractor shall follow the applicable formal software development process to document and place test procedures and test results under configuration control. The contractor shall document defects detected during this phase following the process defined in the SDP. The contractor shall deliver applicable data for this work effort.

The contractor shall not proceed to the SIT phase of Paragraph 1.3.7 until the AFLCMC/WNYEBA technical POC acknowledges successful completion this phase. (A00D, DI-IPSC-81440A, Software Test Report)

1.3.7 System Integration Test (SIT)

The contractor shall conduct System Integration Testing (SIT) using operational AN/ALQ-161A hardware and OFP compatible EIDs. The contractor shall perform SIT at AFLCMC/WNYEBA designated facilities with the assistance of other contractor and government personnel. SIT is to be an engineering laboratory test of the integrated software to evaluate resolution of the system deficiency and to ensure the software solution(s) have no negative impact to system performance. The contractor shall deliver as requested applicable data for this work effort. The contractor shall verify and report SIT results in the Integration Test Report.

The contractor shall follow the applicable formal software development process to document and place test procedures and test results under configuration control. The contractor shall document defects detected during this phase following the process defined in the SDP. The contractor shall submit redlines to the ERM, Self-Test Quick Reference Guide, PDT/CSUT and the AFS C-bus ICD. Once redlines are approved for the ERM, Self-Test Quick Reference Guide, PDT/CSUT, the contractor shall incorporate the changes into the documents and deliver as final to the Government. The contractor shall deliver applicable data for this work effort.

The contractor shall support a Test Readiness Review (TRR) for system functional testing per Paragraph 4.5. The contractor shall not begin the system functional tests of Paragraph 1.3.8 until the AFLCMC/WNYEBA technical POC acknowledges successful completion of the TRR. (A008, DI-IPSC-81431A, System/Subsystem Specification;

A009, DI-IPSC-81433A, Software Requirements Specification; A00A, DI-IPSC-81434A, Interface Requirements Specification; A00B, DI-IPSC-81435A, Software Design Description; A00C, DI-IPSC-81436A, Interface Design Description; A00E, DI-MISC-81384, Service Engineering Report; A00F, DI-IPSC-81439A, Software Test Description; A00D, DI-IPSC-81440A, Software Test Report)

1.3.8 Formal Qualification Test

The contractor shall perform a Formal Qualification Test (FQT) to demonstrate that all software product

PR: FD2060-16-60702 D.O.#1SOW REVISION: 0 8

developed under this effort meet the system requirements and performs adequately for field use. The contractor shall perform testing at AFLCMC/WNYEBA designated facilities with the assistance of other contractor and government personnel. The contractor shall perform FQT in a real-time environment with background environments active to simulate real world conditions (as applicable). The contractor shall accomplish testing using digital and radio frequency (RF) simulations as appropriate. The contractor shall perform aircraft maintenance system(s) integration test in a AFLCMC/WNYEBA designated laboratory with the assistance of other contractor and government personnel. The contractor shall deliver applicable data for this work effort. The contractor shall develop and deliver T.O. change packages and technical manual source.

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.3. (A00F, DI-IPSC-81439A, Software Test Description; A00T, DI-IPSC-81440A, Software Test Report; TM-86-01M, AF Technical Manual Contract Requirement)

1.4 Software Test Cycle Support

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

The contractor shall conduct all test activities in accordance with the Level 3 or higher requirements of CMU/SEI- 93-TR-24, Software Engineering Institute Capability Maturity Model for Software, Version 1.3. The contractor shall capture all data generated within the following subtasks in the DAL of Paragraph 4.4. Additionally, the contractor shall participate in meetings related to other government organizations or contractor work products as directed by AFLCMC/WNYEBA. The contractor shall report the status and the hours expended on each of the following subtasks in the monthly status report. The contractor shall include a summary total of all hours expended in support of the following subtasks for the entire contract in each monthly status report of Paragraph 4.5.

1.4.1 Qualification and Field Testing

The contractor shall support AFLCMC/WNYEBA accomplishment of additional testing following FQT. The contractor shall deliver applicable data for this work effort as requested by AFLCMC/WNYEBA. Qualification and field testing may consist of:

• FET

• C&I

• Aircraft Ground Testing (includes Integration and Checkout (I&CO))

• Flight Testing

1.4.2 Software Fielding Support

The contractor shall provide interim sustainment and maintenance support during and following completion of qualification and field testing. Interim support may be required during accomplishment of FCA/PCA and subsequent fielding of the software product. The contractor shall develop and deliver a Software Production Specification (SPS)and Software Version Description (SVD). The contractor shall deliver applicable data for this work effort. (A00G, DI-IPSC-81441A, Software Product Specification; A00H, DI-IPSC-81442A, Software Version Description)

1.4.2.1 FCA/PCA Planning

The contractor shall develop and deliver a FCA/PCA plan. The FCA/PCA is to serve as a formal audit of the software Configuration Items (CI) to verify the Product Baseline. The contractor’s audit plan shall validate that the functional and allocated performance requirements are satisfied. The contractor’s audit plan shall also verify that the technical documentation adequately represents the CI. The FCA is typically performed via test, and the PCA is performed by verifying that the data (specifications, plans, test reports, etc.) adequately represent the CI.

(A00Y, DI-SESS-81646, Configuration Audit Plan)

1.4.2.2 FCA/PCA Audit

PR: FD2060-16-60702 D.O.#1SOW REVISION: 0 9

The contractor shall execute the AFLCMC/WNYEBA-approved audit plan of Paragraph 1.4.2.1 and per the requirements of Paragraph 4.3. The contractor shall further support the audit review by incorporating all outstanding changes into the baseline documentation for review (as applicable). The documentation for review includes:

• Project Requirements Specification (PRS)

• Software Development Plan (SDP)

• System/Subsystem Specification (SSS)

• Software Requirements Specification (SRS)

• Interface Requirements Specification (IRS)

• Software Design Description (SDD)

• Interface Design Description (IDD)

• Software Test Plan (STP)

• Software Test Descriptions (STD)

• Software Test Reports (STR)

• Software Product Specification (SPS)

• Software Version Description (SVD)

• Emitter Reprogramming Manual (ERM) Additional items included in the audit include traceability matrices, source code, executable, software configuration items supporting testing, and technical orders/manuals updates and/or redlines. The contractor shall develop and deliver a configuration audit report and shall accomplish actions as assigned as a result of the audit. (A00J, DI-CMAN-81022C, Configuration Audit Summary Report)

PR: FD2060-16-60702 D.O.#1SOW REVISION: 0 10

2. SERVICES SUMMARY

PERFORMANCE

OBJECTIVE

SOW

REFERENCE

PERFORMANCE THRESHOLD

The contractor shall respond to general software technical inquiries from AFLCMC/WNYEBA.

1.1 The contractor shall provide response within five

(5) business days to all email technical inquiries.

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

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

The contractor shall perform regression testing to validate that no faults were introduced by the prototype solution.

1.2.2 Following AFLCMC/WNY acceptance of the

deficiency analysis report for a prototype solution, no more than 5% of scheduled regression tests shall fail due to problems induced by the prototype solution.

The contractor shall provide red-lines of documentation changes via the Data Accession List (DAL).

1.3, 1.4 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 accomplish efforts in accordance with project schedules.

1.2, 1.3, 1.4 The contractor shall be allowed no more than 10% schedule variance against project schedules for development, testing, investigations, and document support.

The contractor shall comply with Air Force wide and local security procedures.

5.2 The contractor shall be allowed zero (0)

reportable security violations within the contract period of performance, as determined by the B-1B Security Classification Guide (SCG) and organizational procedures.

PR: FD2060-16-60702 D.O.#1SOW REVISION: 0 11

3. GOVERNMENT FURNISHED PROPERTY AND SERVICES

AFLCMC/WNYEBA will provide current intelligence information to the contractor as available.

AFLCMC/WNYEBA furnished Special Test Equipment will be available at the Government facilities to accomplish this work effort. The Electronic Warfare Avionics Integration Support Facility (EWAISF) at Robins AFB, the Software Test Facility (STF) at a contractor’s facility (Amityville, NY), and the Reprogrammable Electronic Warfare Systems Test (REWST) Facility at Eglin AFB will be made available for accomplishing this work effort on a non-interference basis.

PR: FD2060-16-60702 D.O.#1SOW REVISION: 0 12

4. Technical Requirements

4.1 Period and Place of Performance

4.1.1 Place of Performance

The place of performance for this contract shall be a combination of a U.S. Government installation (Robins AFB, GA and Eglin AFB, FL) and the Contractor’s facility.

4.1.2 Contract/Order Period of Performance

The period of performance for this engineering services effort is 36 months after receipt of order (ARO).

4.2 Post Award Conference

The Contractor shall host a Post Award Conference (PAC) approximately 45 calendar days after contract award.

The purpose of this meeting shall be to discuss security, technical aspects of project execution, detailed schedule, and other contract requirements. The Contractor shall submit an agenda, presentation and minutes in accordance with the deliverables of paragraph 4.3.

4.3 Meetings and Travel

The Contractor shall conduct or support meetings as required to accomplish the work efforts in this task. As requested by AFLCMC/WNYEBA, the Contractor shall participate or conduct the following conferences:

• Block Cycle Candidate Selection for task 1.3.1

• SSR/SRR for task 1.3.4

• Combined PDR/CDR for task 1.3.5

• Test Readiness Reviews (TRR) for tasks 1.3.7, 1.3.8, 1.4.1

• System Test Results Review for task 1.3.8

• FCA/PCA for task 1.4.2.2

• Post Award Conference for task 4.2

• Technical Interchange Meetings for task 4.6

• Semi-annual Performance Reviews for task 4.7

• Program Management Reviews for task 4.8

The Contractor shall provide engineering and program expertise to support all aspects of the AN/ALQ-161A throughout the B-1 community (e.g. Program Management Reviews (PMR), Working Groups and Technical Interchange Meetings) as requested by AFLCMC/WNYEBA.

The Contractor shall submit agendas and minutes for each meeting conducted. The Contractor shall accomplish the travel required to complete these work efforts and shall provide a trip summary in the monthly status report covering the calendar period during which each trip was taken. The Contractor shall submit travel requests to the contract-assigned AFLCMC/WNY program manager or AFLCMC/WNYEBA engineer a minimum of five (5) calendar days prior to all routine travel. Travel requests shall include the names and applicable roles of travelers, travel dates, purpose of travel, duration of the trip, itinerary, current travel CLIN balance and estimated cost. The Contractor shall not perform any travel until written permission is provided by AFLCMC/WNY. Travel by Contractor personnel shall be conducted in accordance with FAR 31.205-46, Travel Costs. (A00K, DI-ADMN-81249A, Conference Agenda; A00L, DI-ADMN-81250A, Conference Minutes; A00M, DI-MISC-81384, Service Engineering Report; A00N, DI-ADMN-81373, Presentation Material)

4.4 Data Accession List (DAL)

All data wholly developed under this work effort shall become property of the Government and under data management control of AFLCMC/WNYEBA. The Contractor shall provide a DAL that lists all data developed by the Contractor in accomplishment of this task. The Contractor shall provide access to any data developed under this task at the request of AFLCMC/WNY. (A00X, DI-MGMT-81453A, Data Accession List)

PR: FD2060-16-60702 D.O.#1SOW REVISION: 0 13

4.5 Monthly Status Report

The Contractor shall document the status of all activities performed in a monthly status report. As an attachment to the monthly status report, the Contractor shall include copies of the invoices submitted for payment. The Contractor shall also attach a Funds and Man-hour Expenditure report detailing the man-hours and the labor categories charged.

Minimum items to be addressed in the report include:

• Summary of planned work (BCWS, man-hours) versus actual work (ACWP) versus budgeted Cost of Work

Performed (BCWP)

• Identification of areas where the Contractor’s performance/deliverables are not projected to meet the requirements of the contract

• Hours by Labor Category charged by month and cumulative throughout the period of performance.

• Schedule of actual costs versus planned costs to date and projections to the end of contract

• Status of Action Items from reviews and meetings

• Summary of work performed during the month

• Summary of planned work during next month

• Identification of technical problems or anomalies encountered

• Metric reports required by the contract or SDP

• Software products delivery matrix, comparing due dates of software products with actual delivery dates

• Rework matrix, identifying the rework products (Software work products, tests, etc.), rework hours and estimated rework costs

The Contractor shall update and deliver the DAL and IMS with the status report. (A00X, DI-MGMT-81453A, Data Accession List; A00P, DI-MGMT-80368A/T, Status Report; A00Q, DI-FNCL-80331A, Funds and Man-Hour Expenditure Report; A007 DI-MGMT- 81861, Integrated Program Management Report)

4.6 Technical Interchange Meetings (TIMs)

The Contractor shall support, participate in, and as directed by the AFLCMC/WNY, chair TIMs in support of this effort. The intent of these meetings is to ensure proper technical control and program management by AFLCMC/WNY. No pre-submitted agenda is required unless specifically requested by AFLCMC/WNY. As requested by AFLCMC/WNY, the Contractor shall develop and submit presentation material. The Contractor shall record detailed minutes of each review and shall provide them as an attachment to the status report covering the calendar period during which the meeting took place. The meeting shall be held at the Government or Contractor’s facility at the discretion of AFLCMC/WNY. It is expected that the majority of the technical interchange meetings shall be held by Video Teleconferencing (VTC) or Telephone Conferencing. Attendees shall consist of, as a minimum, an AFLCMC/WNY representative and the Contractor. The Contractor shall provide requested deliverables and minutes in accordance with the deliverables of paragraph 4.3.

As a minimum, the contractor shall plan to support the Government at quarterly block cycle requirements and planning board meeting to be held at the Boeing facility in Midwest City, OK or at Tinker AFB, OK.

4.7 Semi-Annual Performance Review

The Government POC shall conduct a semi-annual meeting to discuss the Contractor’s overall performance and progress. Any significant issues of the Contractor’s performance, both positive and negative, shall be discussed.

This meeting typically shall be conducted via teleconference and shall not require travel by any of the required participants. This meeting shall be documented by completion of the Semi-Annual Contractor Performance Meeting Summary form. The Government contract monitor shall maintain completed original forms. A copy of any report containing any significant comments shall be forwarded to the contracting officer. A copy of the completed form shall be provided to the Contractor.

4.8 Program Management Reviews

The Contractor shall host semi-annual program management reviews with Government representatives as required by AFLCMC/WNYEBA for the duration of the program. At each PMR the Contractor shall include a presentation of project status showing all work accomplished and any problems encountered. These formal reviews may be held at another Government installation or Contractor facility if specified by the Government. PMRs may also be scheduled on an "as requested" basis by either the Government or the Contractor. The Contractor shall conduct and

PR: FD2060-16-60702 D.O.#1SOW REVISION: 0 14

document the meetings for the purpose of program control and review. The Contractor shall submit an agenda, presentation and minutes in accordance with the deliverables of paragraph 4.3.

4.9 Systems Software Engineering

The Contractor’s software development and modification activities shall support AFLCMC/WNYEBA in accordance with the Level 3 or higher requirements of CMU/SEI-2002-TR-012, Capability Maturity Model Integration, Version 1.3 or higher and applicable ISO 9000 series processes.

4.10 Software Configuration Management

The Contractor shall implement a configuration management program for all engineering software products generated or processed as a result of the Deficiency Analysis, to include software prototype code, Deficiency Analysis Plans, and Deficiency Analysis Reports. References to appropriate Software Configuration Management (SCM) procedures shall be addressed in the project SDP and based on the Contractor’s Software Development Policies and Procedures (SDPP).

4.11 Software Quality Assurance

The Contractor shall implement a quality assurance program for all software products generated or processed as a result of this block cycle. The role of Software Quality Assurance (SQA) shall be addressed in the SDP and based upon the Contractor’s SDPP.

4.12 Software Engineering Group (SEG) Membership

The SEG has responsibility for software requirements analysis, design, code and test for each software effort. As part of the SEG, the Contractor shall participate in meetings, peer reviews, and audits as defined per the applicable

SDP.

4.13 Technical Order/Manual Update Support

The Contractor shall provide operational and maintenance Technical Orders update support as directed by AFLCMC/WNYEBA. This support shall include review of Technical Orders and identification of changes required due to recommended software prototype changes identified during this task.

4.14 Supplies

The Contractor shall be allowed to purchase consumables, items, supplies, and/or acquire specialized engineering services as required to meet contractual requirements. Prior to obtaining the requested items, the Contractor shall obtain Government approval for all purchase requests, with a unit price of five thousand dollars ($5K) or more.

Purchase requests should include a detailed list of all requested items, their estimated costs and their intended purpose or need.

PR: FD2060-16-60702 D.O.#1SOW REVISION: 0 15

5. General Information

5.1 Continuation of Mission-Essential Services During a Crisis

5.1.1 Definition of Mission-Essential Services

In accordance with DFARS 252.237-7023(a)(1), Continuation of Essential Contractor Services, “ ‘Essential contractor service’ means a service provided by a firm or individual under contract to DoD to support mission-essential functions, such as support of vital systems, … associated support activities, … and similar services provided to foreign military sales customers under the Security Assistance Program. Services are essential if the effectiveness of defense systems or operations has the potential to be seriously impaired by the interruption of these services, as determined by the appropriate functional commander or civilian equivalent.”

5.1.2 Designation of Services as Mission-Essential

In accordance with DFARS 237.7602(a), The Continuation of Essential Contractor Services, DFARS 252.237- 7023(a)(2), and Air Force Instruction (AFI) 10-403, Deployment Planning and Execution, paragraph 1.9.1.33.2, the Functional Commander (FC) or civilian equivalent has determined these services are not mission-essential and will not continue in the event of a crisis.

5.2 Security Requirements

5.2.1 Classified/Unclassified

Knowledge and/or generation of classified and/or controlled unclassified information are required for performance of the contract. The Contractor shall ensure applicable Contractor personnel have security clearances at the Secret level.

5.2.2 Government Security Regulations

The Contractor shall ensure personnel, information, system, property and facility security requirements are met. The Contractor shall comply with Government Security regulations including, but not limited to, DoD 5200.2-R, Personnel Security Program; DoD 5220.22-M, National Industrial Security Program Operating Manual (NISPOM);

DoDD 5205.02E, DoD Operations Security (OPSEC) Program; DoD Manual 5205.02-M, DoD Operations Security (OPSEC) Program Manual; and Robins Air Force Base Integrated Defense Plan (RAFB IDP) 31-101.

5.2.3 Operations Security (OPSEC)

The purpose of OPSEC is to reduce the vulnerability of USAF missions to adversary collection and exploitation of critical information. The Contractor shall ensure compliance with DoDD 5205.02E, DoD Manual 5205.02-M, and other applicable Government security regulations including procedures to protect classified and/or controlled unclassified information, Government projects and/or programs.

5.2.4 Communication Security (COMSEC)

The Contractor shall use only secure communications methods and/or equipment to transmit or otherwise transfer classified and/or controlled unclassified information in accordance with DoD 5220.22-M and other applicable Government security regulations. Applicable Government property, including equipment, shall be safeguarded, maintained, and operated in accordance with DoD 5220.22-M and other applicable Government security regulations.

5.2.5 Security Clearance

The Contractor shall ensure applicable Contractor personnel have security clearances at the SECRET level for proper accomplishment of contract/order requirements. The security clearance shall be obtained in accordance with the DD Form 254, Department of Defense Contract Security Classification Specification. Contractor personnel whose clearances have been suspended or revoked shall immediately be denied access to classified and/or controlled unclassified information and classified items.

5.2.6 Security Incident or Violation

The Contractor shall immediately notify the Government Security Office of any potential or actual security incident or violation including potential or actual unauthorized disclosure or compromise of classified and/or controlled unclassified information. The Contractor shall be allowed zero (0) reportable security violations within the contract

PR: FD2060-16-60702 D.O.#1SOW REVISION: 0 16

period of performance, as determined by the B-1B Security Classification Guide (SCG) and organizational procedures.

5.2.7 Security of Contractor System(s)

The Contractor shall ensure the security of Automated Information System (AIS) at the Contractor’s facility to preclude potential security incidents or violations including potential unauthorized disclosure or compromise of classified information and/or controlled unclassified information.

5.2.8 Access to Government Systems

The Government shall provide Contractor personnel access to systems necessary to perform tasks under the contract/order. The Contractor shall ensure Contractor personnel who require access to any Government Automated Information System (AIS) have the appropriate background check or security investigation. The Contractor shall ensure Contractor personnel who require access to any classified or unclassified AIS that requires a security clearance have the appropriate security investigation for that system. The Government shall provide system access subject to approval of the DD Form 2875, System Authorization Access Request (SAAR). Upon completion/termination of the contract/order or transfer/termination of Contractor personnel, the system account shall be closed.

5.2.9 Access to Government Facility

The Contractor shall ensure Contractor personnel who require access to a Government facility comply with the security procedures and security education requirements of the facility.

5.2.10 Common Access Card (CAC)

5.2.10.1 In accordance with AFFARS 5352.242-9001, Common…