StatementofWork.pdf

ALQ-172 SOW

Revision -, 12 Dec 2019

FD2060-21-30005 Page 1 of 222

Statement of Work (SOW)

For

AN/ALQ-172(V)

Program

Prepared By:

ALQ-172 INTERNAL ATTACK INTEGRATED PRODUCT TEAM (IPT)

ELECTRONIC WARFARE/AVIONICS SYSTEM PROGRAM OFFICE

AGILE COMBAT SUPPORT DIRECTORATE

AIF FOR LIFE CYCLE MANAGEMENT CENTER

AFLCMC/WNY

DISTRIBUTION STATEMENT D: Distribution authorized to U.S. Government Agencies and their contractors (Critical Technical) (12 December 2019). Other requests for this document shall be referred to AFLCMC/WNY, 235 Byron St., Ste. 19A, Robins AFB, GA 31098-1670. Questions concerning the technical content should be directed to AFLCMC/WNY ALQ-172 Sub-IPT.

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.

FD2060-21-30005 Page 2 of 222

Revision Page

The following revisions have been made to this document:

# Revision Affected Pages

FD2060-21-30005 Page 3 of 222

Table of Contents

1 BACKGROUND

1.1 Purpose and Scope

1.2 Objectives

2 REQUIREMENTS

2.1 Sustainment

2.1.1 Deficiency Analysis

2.1.1.1 Deficiency Analysis Plan

2.1.1.2 Deficiency Analysis Execution

2.1.1.3 Technical Inquiries

2.1.2 Block Cycle (BC)

2.1.2.1 BC Candidate Selection

2.1.2.2 Project Planning

2.1.2.3 System Requirements Definition

2.1.2.4 Software Requirements Definition

2.1.2.5 Architectural and Detailed Design Definition

2.1.2.6 Code, Unit Test, Software Integration Test and System Integration Test

2.1.2.7 System Functional Test

2.1.2.8 Emergency and Urgent Operational Change Request

2.1.3 Software Test Cycle Support

2.1.3.1 Independent Verification and Validation (IV&V)

2.1.3.2 Qualification and Field Testing

2.1.3.3 Software Fielding Support

2.1.3.4 FCA/PCA Planning

2.1.3.5 FCA/PCA Audit

2.1.4 Unit Under Test (UUT)/Test Program Set (TPS)

2.1.4.1 Project Planning

2.1.4.2 Software Requirements Definition

2.1.4.3 Software Design Definition

2.1.4.4 Code, Unit Test, Software Integration Test and System Integration Test

2.1.4.5 Qualification Test

2.1.4.6 Software Fielding Support

2.1.5 ALQ-172 Sustaining Engineering Services

2.1.5.1 Technical Inquiries

2.1.5.2 System Deficiency Analysis

Deficiency Analysis Plan

Deficiency Analysis Execution

2.2 EMD

2.2.1 Planning

2.2.1.1 Reserved

2.2.1.2 Aircraft Surveys

FD2060-21-30005 Page 4 of 222

2.2.1.3 Aircraft Structures and Design

2.2.1.4 Wire Routing and Electrical Load

2.2.1.5 Thermal Environment and Cooling

2.2.1.6 Aircraft Weight and Balance

2.2.1.7 Modeling & Simulation

2.2.1.8 Human Factors Engineering Analysis

2.2.1.9 Support Equipment Planning

Maintenance Test and Support Equipment List

Support Equipment Installation Data (SEID)

Facilities Requirements Document (FRD)

Support to Depot Maintenance Working Group (DMWG)

2.2.1.10 Reliability and Maintainability Program

2.2.1.11 Risk Management

2.2.1.12 Cybersecurity

System Requirements Document (SRD) and System Specifications

2.2.2 Design

2.2.2.1 Failure Mode, Effects, and Criticality Analysis (FMECA)

2.2.2.2 Airworthiness

2.2.2.3 Safety of Flight

2.2.2.4 Compatibility

2.2.2.5 Producibility

2.2.2.6 Required Interfaces

2.2.2.7 Interface Control Working Group (ICWG)

2.2.2.8 Crew Station Working Group (CSWG)

2.2.2.9 Integrated Test Team (ITT) and Threat Working Group (TWG)

2.2.2.10 Weapon System Working Group (WSWG)

2.2.2.11 Group A & B Integration Technical Interchange Meetings (TIMs)

2.2.2.12 System/Subsystem Specification (SSS)

2.2.2.13 System/Segment Interface Control Specification

2.2.2.14 Interface Requirements Specification (IRS)

2.2.2.15 Software Requirements Specification (SRS)

2.2.2.16 System/Subsystem Design Description

2.2.2.17 Requirements Traceability

2.2.2.18 Reviews

System Requirements Review (SRR)

System Requirements Review (SRR) - MDFG

Hardware Preliminary Design Review (PDR)

Software Preliminary Design Review (PDR)

Hardware Critical Design Review (CDR)

Software Critical Design Review (CDR)

2.2.3 Development

2.2.3.1 Engineering Data

Engineering Data Guidance Conference

In-Process Review (IPR) of the TDPs

Relationship of Contractor with Subcontractors/Vendors

Engineering Data Updates and Revisions

FD2060-21-30005 Page 5 of 222

Firmware Drawings

2.2.3.2 Technical Manuals

Technical Manuals

Technical Manuals

2.2.3.3 Request for Nomenclature

2.2.3.4 Software Development

Software Documentation

Computer Programming Manual (CPM)

Firmware Support Manuals

MDFG Software and Documentation

Mission Data Files (MDFs)

O-Level Software Documentation

2.2.3.5 Control and Display

2.2.3.6 Interface Simulators

2.2.3.7 Break-out Boxes

2.2.3.8 Logistics Support

Reserved

Logistics Management Information/Logistics Support Analysis

Provisioning Documentation

Provisioning Conferences

Parts List

Parts Derating and Parts Selection

Maintenance and Support Equipment Analysis

2.2.3.8.7.1 Test Requirements Document (TRD)

2.2.3.8.7.2 Calibration/Measurements Requirements Summary

2.2.4 Fabrication

2.2.5 Integration

2.2.5.1 Group B Integration

2.2.5.2 Group A and Group B Integration (Kit Install)

2.2.5.3 O-Level Support Equipment Integration

2.2.6 Verification

2.2.6.1 Verification Test Plan

2.2.6.2 Failure Reporting and Corrective Action System (FRACAS)

2.2.6.3 Reliability Demonstration

2.2.6.4 Maintainability Demonstration (M-Demo)

2.2.6.5 Environmental Stress Screening (ESS)

2.2.6.6 Acceptance Test Procedures (ATPs)

2.2.6.7 Acceptance Test

2.2.6.8 O-Level Test Program Sets (TPSs)

2.2.6.9 Regression Test

2.2.6.10 Information Assurance (IA) (Cybersecurity) Verification and Validation (Option) 84

2.2.6.11 Software Formal Qualification Test (SFQT)

2.2.6.12 Electrical Load Verification

2.2.6.13 Environmental Qualification Test

2.2.6.14 Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC)

2.2.6.15 Electromagnetic Environmental Effects

FD2060-21-30005 Page 6 of 222

2.2.6.16 Spectrum Certification Spectral Characteristics Data

2.2.6.17 Design Verification Test (DVT)

2.2.6.18 Functional Configuration Audits (FCAs)

2.2.6.19 Physical Configuration Audits (PCAs)

2.2.7 Delivery

2.2.7.1 Software Development Tools Delivery

2.2.7.2 Packaging and Marking

2.2.7.3 Transportation and Handling

2.2.8 Government Inspection and Test

2.2.9 Contractor Support for Government Inspection and Test

2.2.9.1 Training - Aircrew

2.2.9.2 Training - O-Level (Option)

2.2.9.3 Developmental Test/Operational Test (DT/OT) Support

Reserved

Test Readiness Review (TRR)

Operational Test (OT) Readiness Review

Deficiency Reporting

Test Site and Information Limitations

Reserved

Test Instrumentation

2.2.10 Manufacturing Readiness Assessment

2.3 Common Requirements

2.3.1 Subcontract Management

2.3.2 Program Management

2.3.2.1 Organization

2.3.2.2 Integrated Program Management – EMD

2.3.2.3 Integrated Baseline Review (IBR) – EMD

2.3.2.4 Status Reports

2.3.2.5 Systems Engineering Management Plan (SEMP) - EMD

2.4 Low Rate Initial Production – Group A, Group B, O-Level (Option)

2.4.1 Fabrication

2.4.2 Integration

2.4.2.1 Integration - Group B

2.4.2.2 Integration - Group A and Group B

2.4.2.3 O-Level Support Equipment Integration

2.4.3 Verification

2.4.3.1 Environmental Stress Screening (ESS)

2.4.3.2 Reserved

2.4.3.3 Acceptance Test

2.4.3.4 Reserved

2.4.3.5 Failure Reporting and Corrective Action System (FRACAS)

2.4.4 Delivery

2.4.5 Engineering Data

2.4.6 Other Requirements

FD2060-21-30005 Page 7 of 222

2.5 Full Rate Production – Group A, B, O-Level (Option)

2.5.1 Fabrication

2.5.2 Integration

2.5.3 Verification

2.5.4 Delivery

2.5.5 Engineering Data

2.5.6 Other Requirements

2.6 Interim Contractor Support (ICS) / (Option)

2.7 Depot Maintenance (Option)

2.7.1 Design – Depot Maintenance

2.7.1.1 Interface Considerations

2.7.1.2 System/Subsystem Specification (SSS)

2.7.1.3 System/Segment Interface Control Specifications

2.7.1.4 Interface Requirements Specification (IRS)

2.7.1.5 Software Requirements Specifications (SRSs)

2.7.1.6 Safety

2.7.1.7 Human Factors Engineering Analysis

2.7.1.8 Requirements Traceability

2.7.1.9 Reviews

System Requirements Review (SRR)

Preliminary Design Reviews (PDRs)

Critical Design Review (CDR)

2.7.2 Development – Depot Maintenance

2.7.2.1 Engineering Data

Engineering Data Guidance Conference

In-Process Review (IPR) of the TDPs

Relationship of Contractor with Subcontractors/Vendors

Engineering Data Updates and Revisions

Firmware Drawings

2.7.2.2 Technical Manuals

2.7.2.3 Test Requirements Document (TRD)

2.7.2.4 Calibration/Measurements Requirements Summary

2.7.2.5 Firmware Support Manuals

2.7.3 Fabrication – Depot Maintenance

2.7.3.1 Hardware

2.7.3.2 Software

CSCIs

Test Program Sets (TPSs)

2.7.4 Integration – Depot Maintenance

2.7.5 Delivery - - Depot Maintenance

2.7.5.1 Software Development Tools Delivery

2.7.6 Verification – Depot Maintenance

2.7.6.1 Acceptance Test Procedures (ATPs)

FD2060-21-30005 Page 8 of 222

2.7.6.2 Acceptance Test

2.7.6.3 Test Program Set (TPS) Acceptance Test

2.7.6.4 Software Formal Qualification Test

2.7.6.5 Functional Configuration Audit (FCA)

2.7.6.6 Physical Configuration Audit (PCA)

2.7.7 Training

2.7.8 Other Requirements

2.8 Anti-Tamper (Option)

2.8.1.1 Anti-Tamper Plan

2.8.1.2 Anti-Tamper Verification and Validation

3 GENERAL REQUIREMENTS

3.1 LABORATORY AND EQUIPMENT MAINTENANCE/UPDATE

3.1.1 System Engineering Integration Test Equipment (SEINTE)

3.1.1.1 Design - SEINTE

Interface Considerations

System/Subsystem Specification (SSS)

System/Segment Interface Control Specification

Interface Requirements Specification (IRS)

Software Requirements Specifications (SRSs)

Safety

Human Factors Engineering Analysis

Requirements Traceability

Reviews

3.1.1.1.9.1 System Requirements Review (SRR)

3.1.1.1.9.2 Preliminary Design Review (PDR)

3.1.1.1.9.3 Critical Design Review (CDR)

3.1.1.2 Development - SEINTE

Engineering Data

3.1.1.2.1.1 Engineering Data Guidance Conference

3.1.1.2.1.2 In-Process Review (IPR) of the TDPs

3.1.1.2.1.3 Relationship of Contractor with Subcontractors/Vendors

3.1.1.2.1.4 Engineering Data Updates and Revisions

3.1.1.2.1.5 Firmware Drawings

Technical Manuals

Test Requirements Document (TRD)

Calibration/Measurements Requirements Summary

Firmware Support Manuals

3.1.1.3 Fabrication – SEINTE

Hardware

CSCIs

3.1.1.4 Integration – SEINTE

3.1.1.5 Delivery - SEINTE

Software Development Tools Delivery

FD2060-21-30005 Page 9 of 222

3.1.1.6 Verification - SEINTE

Acceptance Test Procedures (ATPs)

Acceptance Test

Software Formal Qualification Test

Functional Configuration Audit (FCA)

Physical Configuration Audit (PCA)

3.1.1.7 Training - SEINTE

3.1.1.8 Other Requirements – SEINTE

3.2 Execution Management

3.2.1 Sustainment Support

3.2.1.1 Facilitator Role

Program Status Notebook (PSN)

Master Program Schedules (MPS)

Master Status Notebook

Monthly Status Report

3.2.1.2 Engineering Problem Report (EPR) & Problem Log (PLOG) Databases

3.2.1.3 Technical Review Board (TRB) Membership

3.2.2 Travel

3.2.3 Post Award Conference

3.2.4 Program Management Reviews (PMRs)

3.2.5 Technical Interchange Meetings (TIMs)

3.2.6 Production Status Reporting (Option)

3.2.7 Communications

3.2.8 Continuation of Essential DoD Services During Crisis

3.2.9 Data Management

3.2.9.1 Data Delivery

3.2.10 Data Accession List (DAL)/Internal Data

3.2.11 Reserved

3.2.12 Data Rights

3.2.12.1 Unlimited Rights

3.2.12.2 Government Purpose Rights

3.2.12.3 Limited or Restricted Rights

3.2.12.4 Purchased Government Purpose Rights (Option)

3.2.13 Software Development Plan (SDP)

3.2.14 Configuration Management

3.2.14.1 Configuration Management Plan

3.2.14.2 Engineering Change Proposals (ECPs) and Notice of Revisions (NORs)

3.2.14.3 Variances

3.2.14.4 Contract Change Proposals (CCPs)

3.2.14.5 Parts Management

Diminishing Manufacturing Sources

Counterfeit Parts

3.2.14.6 Item Unique Identification (IUID)

3.2.14.7 Marking of Electrical and Electronic Parts

3.2.15 Quality Assurance

FD2060-21-30005 Page 10 of 222

3.2.16 Manufacturing Management

3.2.17 Green Procurement Program

3.2.18 Electrostatic Discharge (ESD) Control Program

3.2.19 Corrosion Prevention and Control Plan

3.2.20 Foreign Object Damage

3.2.21 Security Requirements

3.2.21.1 General

Security Classification Guide (SCG)

3.2.21.2 Controlled Unclassified Information (CUI)

3.2.21.3 Operations Security (OPSEC)

3.2.21.4 Reserved

3.2.21.5 Security Incidents and Violations

3.2.21.6 Communications Security (COMSEC)

3.2.21.7 Program Protection Plan (PPP)

Reserved

Program Protection / System Security Risk Assessment

Cyber Incidents

Attack Path Analysis

Cybersecurity and Trusted Systems and Networks

3.2.21.7.5.1 Cybersecurity Plan

3.2.21.7.5.2 Criticality Analysis

3.2.21.7.5.3 Defense Intelligence Agency – Threat Analysis Center Report

3.2.21.7.5.4 Security and Resiliency Requirements Allocation

3.2.21.7.5.5 Trusted Source

3.2.21.7.5.6 Software Assurance

3.2.21.7.5.7 Key and Certificated Management Plan (KCMP)

3.2.21.7.5.8 Telecommunications Electronics Materials Protected from Emanating Spurious

Transmissions (TEMPEST)

3.2.21.7.5.9 Interim Authority To Test (IATT) and Authority To Operate (ATO)

Critical Program Information (CPI) Identification/Protection

Criticality Analysis

Supply Chain Risk Management (SCRM)

3.2.21.8 Labeling Of Classified

3.2.21.9 Safeguarding Classified Material

3.2.21.10 Personnel Security

3.2.21.11 Security Incidents and Violations

Compliance with Safeguarding Covered Defense Information Controls

Limitations on the Use or Disclosure of Third-Party Contractor Reported Cyber

Incident Information

Safeguarding Covered Defense Information and Cyber Incident Reporting

3.2.21.12 Common Access Card (CAC)

3.2.22 Contractor Acquired Property

3.2.23 Warranty

3.2.24 Warranty Returns of Classified Hardware

3.3 Lead-Free Control Plan

FD2060-21-30005 Page 11 of 222

3.4 Safety

3.4.1 Hazardous Materials Management

4 Government Property

4.1 Contractor Responsibility

4.2 Government Property To Be Provided

4.2.1 Government Furnished Property

4.3 Reporting of Government Property

4.4 Loss of Government Property

4.4.1 Definition of Loss of Government Property

4.4.2 Reporting Loss of Government Property

4.5 Return or Retention of Government Property

4.6 Government Furnished Software (GFS)

4.7 Government Furnished Test Facilities

4.8 Government Furnished Documentation (GFD)

5 General Information

5.1 Referenced Documents and Order of Precedence

5.1.1 Military Standards, Handbooks, Manuals

5.1.2 DoD Documents

5.1.3 Other Documents

5.2 Definitions

5.3 Data Item Delivery Summary

5.4 Attachments

5.4.1 Attachment 1: Modification Baseline, Critical Technology Elements (CTEs)

5.4.2 Attachment 2: System Engineering Integration Test Equipment (SEINTE)

Capabilities

5.4.3 Attachment 3: Post Mission Analysis Tool Capabilities

5.4.4 Attachment 4: Common Support Equipment List

5.5 Acronyms

FD2060-21-30005 Page 12 of 222

1 BACKGROUND

The AN/ALQ-172(V) Electronic Countermeasures System (CMS) is the primary Radio Frequency (RF)

Electronic Warfare (EW) system installed on the Air Force Global Strike Command (AFGSC) B-52 and

Air Force Special Operations Command (AFSOC) MC-130H Combat Talon II Aircraft.

This Statement of the Work (SOW) covers the work requirements applicable to engineering and supply support for the complete AN/ALQ-172(V) CMS to operate and maintain the system on the platforms.

1.1 Purpose and Scope

The AN/ALQ-172(V) program is currently in a sustainment phase that is expected to be converted into early stages of life cycle of a program in order to deliver required Situational Awareness, and Self-

Protection capabilities as well as to achieve seamless integration with other systems to aid automation and consolidation of current federated EW functions installed on the B-52.

The scope of sustainment, engineering and manufacturing support required is outlined by the requirements set forth in this SOW. Additional details of each effort will be provided in individual task orders. The Contractor shall provide required services as defined in the individual task orders, from negotiated rates and labor categories, for the period of performance stated in the individual orders. In addition, the Contractor shall furnish a proposal for each task order together with the contractor’s estimate of task completion date and cost.

This SOW encompasses Sustainment, Engineering & Manufacturing Development (EMD) and

Production & Deployment tasks for the entire Group A and B system.

The optional EMD and Production & Deployment tasks include requirements for a Contractor to plan, design, develop, fabricate, integrate, verify, and deliver the system Group A/Group B kits on designated aircraft(s). The contract will specify a number and types of spares for each task. Contract options covered by this SOW are indicated by “(Option)”.

1.2 Objectives

The Government may award multiple contract(s) with multiple options to contractors and Government units that shall have the responsibility to manage, execute, and support the sustainment, development, test, and production of the system.

FD2060-21-30005 Page 13 of 222

The contractor shall support Air Force Life Cycle Management Center, Electronic Warfare/Avionics

System Program Office (AFLCMC/WNY), the responsible System Program Office (SPO) for the

AN/ALQ-172 system, by participating in all phases of the multi-year Sustainment of currently fielded configurations, EMD, Production, and Sustainment of new configurations resulted from the EMD tasks.

The end goal is to provide cost-efficient, quality software and hardware solutions that can be fielded in a timely manner in order to support the United States Air Force (USAF) mission. AFLCMC/WNY has the overall Group-B program management and technical authority includes Operational Safety, Suitability, and Effectiveness (OSS&E) responsibility.

All deliverables generated under tasks issued under this contract shall be forwarded to AFLCMC/WNY for final inspection and acceptance, unless otherwise specified in the task order(s) or amendment(s) thereto. Copies of all transmittal letters, by which work products are forwarded to AFLCMC/WNY, shall be sent to the Procuring Contracting Officer (PCO), the appropriate Administrative Contracting Officer

(ACO). Final inspection and acceptance of hardware items generated under tasks issues under this contract will be made by Government personnel at a location set forth in each task order. Shipping instructions, as required, will be set forth in each task order. In addition, specific data requirements will be identified in each order.

The contractor will not place any proprietary restrictions or markings on deliverable software, hardware, documentation, or other work products other than commercial-off-the-shelf (COTS) products, except as explicitly approved by AFLCMC/WNY.

All work hereinafter specified shall be performed in the most economical and expeditious manner by skilled personnel and shall be in conformance with the highest engineering standards and practices.

FD2060-21-30005 Page 14 of 222

2 REQUIREMENTS

The following requirements shall apply to the Contractor’s system regardless of method of development

(example: COTS, modified COTS, Non-Developmental Item (NDI), or subcontracted). The Contractor shall flow down requirements to all subcontractors.

2.1 Sustainment

2.1.1 Deficiency Analysis

Deficiency Analysis is a software sustainment risk reduction effort typically focused on analyzing high priority software candidates from the Operational Change Request (OCR) and/or Software Change

Request (SCR) Databases for inclusion in upcoming software Block Cycles (BCs). A deficiency analysis request, however, is not limited to a software candidate, but may be assigned for any system-related sustainment software issue. The contractor shall document each deficiency analysis plan (Paragraph

2.1.1.1), and the results of each deficiency analysis (Paragraph 2.1.1.2) shall be presented in accordance with the Data Item Description (DID) of each deliverable specified in applicable DD Form 1423, Contract

Data Requirements List (CDRL). The contractor shall submit each plan and each completed analysis to the Technical Review Board (TRB) for review and comment by other contractors and government agencies. The contractor shall update the documents as directed by the TRB.

The contractor shall perform deficiency analyses on the candidates scheduled for inclusion in the next routine BCs. The candidates will be provided by individual task orders.

The contractor shall also perform technical review of other contractor’s and government agency’s deficiency analysis products related to the ALQ-172 as directed by AFLCMC/WNY.

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.

CDRL Data Item Description (DID) Title Subtitle (if applicable) DID

A001 Status Report Monthly Status Report DI-MGMT-80368A

A002 Funds and Man-Hour Expenditure Report DI-FNCL-80331A

FD2060-21-30005 Page 15 of 222

2.1.1.1 Deficiency Analysis Plan

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

AFLCMC/WNY. The baseline software and hardware configurations shall be identified to the contractor by the AFLCMC/WNY technical POC at the time of deficiency analysis assignment. As a minimum, the plan shall cite the following:

OCR/SCR/Problem-LOG (PLOG) Number (if applicable)

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 Anticipated technical and operational performance improvements o Anticipated technical and operational performance limitations o Anticipated technical risks o Anticipated impacts to aircraft physical and functional objects/interfaces o Anticipated impacts to firmware/Operational Flight Programs (OFPs including Control

Display Unit (CDU) OFP) o Anticipated impacts to Emitter Identification (EID) and Mission Data File Generation

(MDFG) Tool o Anticipated impacts to Diagnostics, Status Monitoring, and Trouble-Shooting tools o Anticipated impacts to other related configurable items (lab tools, analysis tools, operational tools, maintenance tools)

CDRL Data Item Description (DID) Title Subtitle (if applicable) DID

A003 Service Engineering Report Deficiency Analysis Plan DI-MISC-81384

2.1.1.2 Deficiency Analysis Execution

Following AFLCMC/WNY approval of the deficiency analysis plan, the contractor shall perform the analysis. The contractor shall document, prototype, 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 satisfactorily addresses the problem set. During deficiency analysis, the contractor shall:

Identify applicable System/Subsystem Specification requirements and applicable changes

Identify lower level system performance requirements

Identify applicable Software Requirements Specification requirements and applicable changes

Perform and document a detailed causal analysis of the problem

FD2060-21-30005 Page 16 of 222

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

For each prototype solution o Identify aircraft physical and functional impacts o Identify mission planning/crew interface impacts, as applicable o Identify firmware/OFP impacts o Identify EID and Mission Data Tool impacts o Identify Diagnostics, Status Monitoring, and Trouble-Shooting tools impacts o Identify all other fielded Computer Software Configuration Item (CSCI) 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 Describe the functional tests to verify technical adequacy of the prototype solution(s) o Provide qualitative and/or quantitative data analysis, as applicable, for the executed tests o Identify limitations of prototype tests, where applicable o Identify anticipated performance deltas between baseline software configuration and final solution o Identify Mission Analysis Report (MAR) impacts, where applicable o Identify impacts to processor throughput and memory, where applicable o Identify risk assessment of the solution for incorporation into the next system software block cycle

The contractor shall perform testing to evaluate the prototype software for operational performance. The contractor shall ensure that the proposed solution will satisfy the performance improvements identified in the OCR or documented problem report. The deficiency analysis testing shall consist of:

Initial lab test to determine existing functional capabilities

Final lab test to evaluate potential solutions

The contractor shall document all requirements identified above and the results of the deficiency analysis using the applicable DID format. The contractor shall also submit problem report updates to the respective OCR/SCR database configuration manager. The contractor shall list the tested prototype code and executable in the Data Accession List (DAL) of Paragraph 3.2.10.

The contractor shall also submit problems detected during the deficiency analysis in the form of

Engineering Problem Reports (EPRs) (sometimes referred to as “PLOGs”) or OCRs as decided by the

TRB process. The EPR database requirements are identified in Paragraph 3.2.1.2.

A004 Service Engineering Report Deficiency Analysis Report DI-MISC-81384

FD2060-21-30005 Page 17 of 222

2.1.1.3 Technical Inquiries

The contractor shall respond to software-related inquiries related to block cycle candidates from

AFLCMC/WNY. Technical inquiries include the contractor’s support during software-related technical meetings as requested by AFLCMC/WNY. The contractor shall notify the AFLCMC/WNY technical

Point of Contact (POC) of any inquiry requiring more than 40 hours work effort. All inquiries shall be documented in the monthly status reports of Paragraph 3.2.1.1.4, 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 cumulative total hours expended for the entire contract in each monthly status report.

2.1.2 Block Cycle (BC)

The contractor shall identify candidates, incorporate solutions, and test the resulting software BC products per the AFLCMC/WNY-approved Project Requirements Specifications (PRS) and per the

AFLCMC/WNY-approved Software Development Plans (SDP). Other government organizations and/or contractors may perform resolution of additional software deficiency candidates in parallel with this effort using the previous software configuration baseline. The contractor shall merge the mature software products from these organizations. Maintaining the delivery schedule of this product for aircraft test is critical to minimizing block cycle costs.

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 Data Accession List (DAL) of Paragraph 3.2.10. 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 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 3.2.1.1.4.

The contractor shall provide engineering support for other software system products that are directly impacted by or related to the OFP sustainment efforts as directed by AFLCMC/WNY. These software products may include, but are not limited to, EID and Mission Data, Diagnostics, Status Monitoring, and

Trouble-Shooting tools, Operational, Intermediate, Depot-Level testers, system software load tools, other firmware and software (i.e. LRU-21 CDU OFP), and system lab and data analysis tools.

FD2060-21-30005 Page 18 of 222

The development and integration cycle consists of the following software upgrade Block Cycle phases:

Project Planning

Requirements Definition

Preliminary Design

Critical Design

Code/Unit Test/Software Integration Test

System Integration Test

System Functional Test

The qualification and field test cycle consists of the following standard upgrade Block Cycle phases.

Independent Verification and Validation (IV&V)

Aircraft Test

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

The contractor shall resolve BC candidates for AFGSC and AFSOC that will be provided by each task order, satisfying the subparagraph requirements of Paragraphs 2.1.2, 2.1.3 and 3.2.1.

As directed by AFLCMC/WNY, the contractor shall support the resolution of the additional BC candidates to be accomplished by another contractor or Government agency.

A005 Scientific and Technical Reports Summary PRS DI-MISC-80048

2.1.2.1 BC 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, LRU/SRU firmware, OFPs, Other system

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

FD2060-21-30005 Page 19 of 222

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 Technical Review Board (TRB) for review and comment by other contractors and government agencies.

The contractor shall support a Block Cycle Candidate Selection meeting per Paragraph 3.2.2. The contractor shall not proceed to the system and software requirements analysis phase (Paragraphs 2.1.2.3 and 2.1.2.4) until the AFLCMC/WNY POC acknowledges successful completion of the Block Cycle

Candidate Selection meeting.

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

A006 Software Development Plan DI-IPSC-81427A

A007 Software Test Plan DI-IPSC-81438A

A008 Contract Work Breakdown Structure DI-MGMT-81334D

2.1.2.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 of interface impacts, and documentation of the requirements.

The contractor shall deliver a System/Subsystem Specification (SSS), with redlined modifications to the original specification as applicable.

FD2060-21-30005 Page 20 of 222

A00A System/Subsystem Specification DI-IPSC-81431A

2.1.2.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 deliver a Software Requirements Specification (SRS), Interface

Requirements Specification(s) (IRS), and Interface Control Documents (ICDs) with redlined modifications to the original specifications as applicable. The contractor shall also submit redlines to the

Mission Analysis Report (MAR).

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

Review (SRR) per Paragraph 3.2.2. The contractor shall not proceed to the design phase (Paragraph

2.1.2.5) until the AFLCMC/WNY technical POC acknowledges successful completion of the SSR/SRR.

A00B Software Requirements Specification DI-IPSC-81433A

A00C Interface Requirements Specification DI-IPSC-81434A

2.1.2.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. The contractor shall logically organize requirements into objects, and top-level design issues shall be identified with planned mitigations. The contractor shall develop preliminary test plans. The contractor shall deliver design documents, with redlined modifications to the original design documents as applicable data.

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

FD2060-21-30005 Page 21 of 222

The contractor shall support iterative design reviews, one formal Preliminary Design Review (PDR) combined with or prior to separate formal Critical Design Review (CDR) per Paragraph 3.2.2. The contractor shall not proceed to the formal test phase (Paragraph 2.1.2.6) until the AFLCMC/WNY technical POC acknowledges successful completion of PDR/CDR.

A00D Software Design Description DI-IPSC-81435A

A00E Interface Design Description DI-IPSC-81436A

A00F Database Design Description DI-IPSC-81437A

A00G Software Test Description DI-IPSC-81439A

2.1.2.6 Code, Unit Test, Software Integration Test and System Integration Test

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

2.1.2.2.

To the maximum and practical extent possible, the contractor shall test modified source code files at the unit level per the SDP. The contractor shall test each unit independent of other units using tests that are automated and repeatable, where applicable. The contractor shall use unit-level test procedures that are documented and provide maximum comprehensive testing, where applicable. The contractor shall verify and report unit test results in the Integration Test Report.

To the maximum and practical extent possible, the contractor shall integrate source code for units by module/class per the SDP. The contractor shall integrate and test each module in a black-box fashion, focusing on the requirements to be met by the module. The contractor shall accomplish stand-alone module integration and testing when functional implementation allows. Subsequent dependent module testing may be accomplished with other modules that have already been integrated. The contractor shall design test software with a focus on software sustainment changes (e.g. changes within one software module to be tested with existing code from other modules, as appropriate), to the maximum extent

FD2060-21-30005 Page 22 of 222 practical. The contractor shall verify and report software integration test results in the Integration Test

Report.

The contractor shall conduct System Integration Testing (SIT) using operational AN/ALQ-172 hardware.

The contractor shall perform SIT at AFLCMC/WNY 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 deliver applicable data for this work effort.

The contractor shall support a Test Readiness Review (TRR) for system functional testing per Paragraph

3.2.2. The contractor shall not begin the system functional tests of Paragraph 2.1.2.7 until the

AFLCMC/WNY technical POC acknowledges successful completion of the TRR.

A00H Computer Software Product DI-IPSC-81488

A00J Software Test Report Integration Test Report DI-IPSC-81440A

2.1.2.7 System Functional Test

The contractor shall perform a System Functional Test (SFT) to demonstrate that the software product meets the system requirements and performs adequately for field use. The contractor shall perform testing at AFLCMC/WNY designated facilities with the assistance of other contractor and government personnel. The contractor shall perform SFT 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 an AFLCMC/WNY designated laboratory with the assistance of other contractor and government personnel. The contractor shall deliver applicable data for this work effort.

FD2060-21-30005 Page 23 of 222

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

A00K Software Test Report Design Verification Test Report DI-IPSC-81440A

B005 Test Procedure DI-NDTI-80603A

2.1.2.8 Emergency and Urgent Operational Change Request

The contractor shall resolve Emergency and Urgent Operational Change Requests as directed by

AFLCMC/WNY satisfying requirements of Paragraph 2.1.2 and 2.1.3.

2.1.3 Software Test Cycle Support

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

AFLCMC/WNY. The contractor shall conduct all test 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 3.2.10. 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 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 3.2.1.1.4.

2.1.3.1 Independent Verification and Validation (IV&V)

The contractor shall perform an IV&V to demonstrate that the software product meets the system requirements and performs adequately for field use. The contractor shall perform testing at

AFLCMC/WNY designated facilities with the assistance of other contractor and government personnel.

The contractor shall perform IV&V 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 deliver applicable data for this work effort.

FD2060-21-30005 Page 24 of 222

A00G Software Test Description DI-IPSC-81439A

2.1.3.2 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 as requested by AFLCMC/WNY.

Qualification and field-testing may consist of:

Simulation/Emulation Test

Compatibility and Integration Testing (with other aircraft systems)

System/Aircraft Ground Testing

Flight Testing

2.1.3.3 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), Software Version Description (SVD), and Software User

Manual (SUM). The contractor shall develop and deliver T.O. change packages and technical manual source. The contractor shall deliver applicable data for this work effort.

A00L Software Product Specification (SPS) DI-IPSC-81441A

A00M Software Version Description (SVD) DI-IPSC-81442A

A00N Software User Manual (SUM) DI-IPSC-81443A

T001 Technical Manual Contract Requirement

(TMCR)

TM-86-01Q

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

FD2060-21-30005 Page 25 of 222

A00P Configuration Audit Plan DI-SESS-81646

2.1.3.5 FCA/PCA Audit

The contractor shall execute the AFLCMC/WNY-approved audit plan of Paragraph 2.1.3.4 and per the requirements of Paragraph 3.2.2. 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 Specifications (SRS)

Interface Requirements Specifications (IRS)

Architectural Design Description (ADD)

Software Design Description (SDD)

Interface Design Description (IDD)

Database Design Description (DBDD)

Software Test Plan (STP)

Software Test Descriptions (STD)

Software Test Reports (STR)

Software Product Specification (SPS)

Software Version Description (SVD)

Software User’s Manual (SUM)

Mission Analysis Report (MAR)

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.

A00Q Configuration Audit Summary Report DI-CMAN-81022C

2.1.4 Unit Under Test (UUT)/Test Program Set (TPS)

The contractor shall support the AN/ALQ-172(V) Unit Under Test (UUT)/Test Program Set (TPS) development and sustainment cycle for Operational, Intermediate and Depot-level test equipment as

FD2060-21-30005 Page 26 of 222 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 submit the PRS to the Technical

Review Board (TRB) for review and comment by other contractors and government agencies. The contractor shall capture all data generated within the following subtasks in the DAL of Paragraph 3.2.10.

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

The contractor shall develop and/or resolve deficiency/software change request candidates for AFGSC and AFSOC, satisfying the requirements of this section (2.1.3), (2.1.4), and (3.2.9). The candidates will be provided by future task orders.

A005 Scientific and Technical Reports Summary PRS DI-MISC-80048

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

A006 Software Development Plan DI-IPSC-81427A

A008 Contract Work Breakdown Structure DI-MGMT-81334D

2.1.4.2 Software Requirements Definition

The contractor shall identify, analyze, and document the software requirements for the software candidates to be resolved by the contractor. 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

FD2060-21-30005 Page 27 of 222 contractor shall deliver a Software Requirements Specification (SRS) with redlined modifications to the original specification as applicable.

The contractor shall support a SRR per Paragraph 3.2.2. The contractor shall not proceed to the design phase (Paragraph 2.1.4.3) until the AFLCMC/WNY technical POC acknowledges successful completion of the SRR.

A00B Software Requirements Specification DI-IPSC-81433A

2.1.4.3 Software Design Definition

The contractor shall allocate the documented software requirements into a detailed design, as applicable, for the software candidates to be resolved by the contractor per the PRS. The contractor shall logically organize requirements into objects, and top-level design issues shall be identified with planned mitigations. The contractor shall develop preliminary test plans. The contractor shall deliver design documents, with redlined modifications to the original design documents as applicable data.

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 Preliminary Design Review (PDR) and Critical Design Review (CDR) per

Paragraph 3.2.2. The contractor shall not proceed to the code and test phase (Paragraph 2.1.4.4) until the

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

A00D Software Design Description DI-IPSC-81435A

A00G Software Test Description DI-IPSC-81439A

2.1.4.4 Code, Unit Test, Software Integration Test and System Integration Test

The contractor shall generate source code for the software candidates to be resolved by the contractor per the PRS using the AFLCMC/WNY approved design from Paragraph 2.1.4.3. The contractor shall recommend any design changes differing from the PDR and CDR approved-design to the

AFLCMC/WNY technical POC via the EPR process. The contractor shall maintain the originally approved design unless the alternate recommendation is approved via the TRB process. The contractor shall code and document the source code files per the approved coding standards as defined in the approved SDP of Paragraph 2.1.4.1.

FD2060-21-30005 Page 28 of 222

To the maximum and practical extent possible, the contractor shall test modified source code files at the unit level per the SDP. The contractor shall test each unit independent of other units using tests that are automated and repeatable, where applicable. The contractor shall use unit-level test procedures that are documented and provide maximum comprehensive testing, where applicable. The contractor shall verify and report unit test results in the Integration Test Report.

To the maximum and practical extent possible, the contractor shall integrate source code for units by module/class per the SDP.