ATTACHMENT_1_-_N00421-17-R-0021-_FMF_APP_SOW.PDF

Revision 5.7.1 (CM#)

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503

Statement of Work (SOW) for

Flight Management Function (FMF) Software Application

FMF Software Application

NAVAIR PMA209

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 Executive Order 12470. Violations of these export laws are subject to severe criminal penalties.

DISTRIBUTION STATEMENT D: Distribution authorized to the Department of Defense and U.S.

DoD Contractors only (software documentation), 03 April 2017. Other requests SHALL be referred to Naval Air Systems Command, PMA209, 47123 Buse Rd, Building 2272, Patuxent River, MD 20670- 1547.

If technical data is also Export Controlled, it SHALL be marked with the Export Control Warning IAW DoDM 5200.01 Vol 2 Enclosure 3.

SOW for RNP RNAV FMF v.5.7.1 (20170724)

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 1

Revision History

Revision Date Approved

- (baseline) 21 July 2017

Change Summary

Date Change Change Reviewer

21 July 2017 Baseline Statement of Work n/a n/a

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 2

Table of Contents

1 SCOPE

2 DOCUMENTS

Government Documents

Non-Government Documents

3 REQUIREMENTS

Software Application

3.1.1 Software Version Description (SVD)

Component and System Construction

3.2.1 Software Production

3.2.2 Software Refactoring

3.2.3 Software Defects

3.2.4 Software Security

3.2.5 Software Metrics

3.2.6 Reserved

3.2.7 Government Software Oversight

3.2.8 Agile Software Development Methodology Requirements

3.2.9 Plan for Software Aspects of Certification (PSAC)

3.2.10 Software Development Plan (SDP)

3.2.11 FMF Software Application Specification

3.2.12 Software Requirements Specification (SRS)

3.2.13 Software Design Description (SDD)

3.2.14 Interface Design Description (IDD)

3.2.15 Software Quality Assurance Plan (SQAP)

3.2.16 Software Quality Assurance Report (SQAR)

3.2.17 Integration Constraints

3.2.18 Configuration Management Plan (CMP)

3.2.19 Requirements Verification Matrix (RVM)

3.2.20 Software Accomplishment Summary (SAS)

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 3

Software Safety

3.3.1 System Safety Assessment

3.3.2 System Safety Program Plan (SSPP)

3.3.3 Software Criticality Assessment and Software Level of Rigor (LOR) Tasks

3.3.4 Safety Assessment Report (SAR)

Open System Architecture

3.4.1 Modular Open Systems Approach

3.4.2 Future Airborne Capability Environment (FACE) Conformance

Systems Engineering Master Plan

Systems Engineering Technical Reviews (SETR)

3.6.1 System Requirements Review/ System Functional Review (SRR/SFR)

3.6.2 Preliminary Design Review (PDR)

3.6.3 Critical Design Review (CDR)

3.6.4 Test Readiness Review for Functional Qualification Testing (TRR for FQT)

3.6.5 Release Backlog Review (RBR)

Technical Interchange Meetings (TIMs)

Weekly Engineering Meetings

External Databases

3.9.1 Navigation Database (NDB)

3.9.2 Magnetic Variation (MAG VAR)

3.9.3 Performance Databases

Operational Program Configuration (OPC)

Test Program

3.11.1 Software Test Plan (STP)

3.11.2 Software Test Description (STD)

3.11.3 Functional Qualification Test (FQT)

3.11.4 Systems Integration Lab (SIL)

FMF Application Platform Integration Support

3.12.1 General

Program Management

3.13.1 Integrated Master Schedule (IMS)

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 4

3.13.2 Program Kickoff

3.13.3 Program Management Review (PMR)

3.13.4 Data Accession List (DAL)

3.13.5 Risk Management

Logistics

3.14.1 Packaging, Handling, Shipping, and Transportation (PHS&T)

SECURITY

3.15.1 General

3.15.2 Cybersecurity

3.15.3 Public Key Infrastructure (PKI)

3.15.4 Operations Security (OPSEC)

3.15.5 Public Release

3.15.6 Cybersecurity Risk Management Framework (RMF)

4 ACRONYMS

List of Tables Table 1: Government Documents

Table 2: Non-Government Documents

Table 3: IEEE/EIA 12207 Priority Rating

Table 4: Acronyms

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 5

1 SCOPE

High traffic congestion of commercial airways has forced significant changes to the air traffic control environments and regulatory mandates domestically and abroad. Spurred by the need to operate under these new civil regulations in support of military operations and facilitated by recent advances in aviation technology, the Naval Air Systems Command (NAVAIR) initiated a program to provide a common systems approach, bringing Navy aircraft into compliance with regulatory requirements. The result of the regulatory changes includes new definitions of the airspace and new requirements for aircraft navigation and reporting capabilities. Though initiated by the Federal Aviation Administration (FAA) and International Civil Aviation Organization (ICAO), these requirements are mandated for all Navy and Marine Corps aircraft, herein after referred to as “Department of the Navy (DoN) aircraft”, through the Communication, Navigation, Surveillance/Air Traffic Management (CNS/ATM) program which defines these capabilities. Specifically, Program Management Air (PMA)209 at NAVAIR is responsible for the implementation and integration of FAA-mandated capabilities for all DoN aircraft.

The effort within this Statement of Work (SOW) is to construct a Future Airborne Capability Environment (FACETM) conformant Flight Management Function (FMF) software application to be used on multiple DoN and Navy-led Joint Program Office aircraft. In this document, the FMF Software Application is referred to as the “FMF Application”. The “Government Specification (GS) for Flight Management Function Software (SW) Application”, within this document, will hereafter be called the “GS for FMF SW App”. This SOW defines the tasks to be accomplished by the Contractor in support of FMF Application. The role of the Contractor is to deliver a FACE-conformant FMF Application.

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 6

2 DOCUMENTS

The following documents form a part of this SOW to the extent specified. In event of a conflict between this SOW and any of the documents listed, the SOW is the superseding document. The following document lists are considered as guidance, unless otherwise noted below. Nothing in this SOW, however, supersedes applicable laws and regulations, unless a specific exemption has been obtained.

Government Documents

Table 1: Government Documents

Document Document Name Date Required/ Guidance

GS for FMF SW App Government Specification for Flight Management Function Software Application, Rev A

28 Jun 2017 Required

FAA Job Aid FAA Conducting Software Reviews Prior to Certification Job Aid, Rev 1

16 Jan 2004 Required

NAVAIRINST

5100.3D

Naval Aviation System Safety Engineering Policy

7 Apr 2016 Required

MIL-STD-882E

Department of Defense Standard Practice:

System Safety

11 May 2012 Required

NAVAIRINST

5234.5B

Metrics for Software Intensive Programs 13 Nov 2012 Required

NAVAIRINST

4355.19E

Systems Engineering Technical Review Process

06 Feb 2015 Required

DoDM 5200.01, Vol 1 DoD Information Security Program:

Overview, Classification, and Declassification

24 Feb 2012 Required

DoDM 5200.01, Vol 3 DoD Information Security Program:

Protection of Classified Information, Change 2

19 Mar 2013 Required

DoDM 5200.01, Vol 4 DoD Information Security Program:

Controlled Unclassified Information (CUI)

24 Feb 2012 Required

DoD 5220.22-M National Industrial Security Program Operating Manual (NISPOM)

28 Feb 2006 Required

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 7

DoDD 5400.07 DoD Freedom of Information Act (FOIA) Program

25 Jan 2017 Required

FIPS PUB 140-2

Security Requirements for Cryptographic Modules, Change Notices

03 Dec 2002 Required

DoDI 5230.24 Distribution Statements on Technical Documents, Change 1

28 Apr 2016 Required

DoDI 8500.01 Cybersecurity 14 Mar 2015 Required

DAFIF 8.1

Digital Aeronautical Flight Information File (DAFIF) edition 8.1 version 3.4a

Mar 2014 Required

LOR Tasks Table NAVAIR Software System Safety Level of Rigor (LOR) Tasks

20 Oct 2016 Required

FAA AC 20-115C Airborne Software Assurance 19 Jul 2013 Guidance

JSSSEH

Joint Software System Safety Engineering Handbook (JSSSEH) Version 1.0

27 Aug 2010 Guidance

DoD Manual O-5205.13

Defense Industrial Base (DIB) Cyber Security and Information Assurance (CS/IA) Program Security Classification Manual (SCM)

26 Apr 2012 Guidance

SWP4940-024

Software Measurement Plan, Standard Work Package 4940.024, Version 4.1

21 Jun 2016 Guidance

MIL-HDBK-516C Airworthiness Certification Criteria 12 Dec 2014 Guidance

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 8

Non-Government Documents

Table 2: Non-Government Documents

Document Document Name Date Require/ Guidance

FACE Technical Standard

The Open Group Technical Standard for the Future Airborne Capability Environment (FACE™) (Edition 2.1)

May 2014 Required

FACE

Conformance Policy

The Open Group Future Airborne Capability Environment (FACE ™) Conformance Policy

Sep 2016 Required

FACE

Conformance Verification Matrix

The Open Group Future Airborne Capability Environment (FACE ™): Conformance Verification Matrix (Edition 2.1)

Dec 2014 Required

FACE Shared Data Model

The Open Group Future Airborne Capability Environment (FACE ™): Shared Data Model (Version 2.1.34)

July 2017 Required

ASTM-D3951-15 Standard Practice for Commercial Packaging 01 Dec 2015 Required

RTCA DO-178C

Radio Technical Commission for Aeronautics

– Software Considerations in Airborne Systems and Equipment Certification

13 Dec 2011 Required

RTCA DO-330

Radio Technical Commission for Aeronautics

– Software Tool Qualification Considerations

13 Dec 2011 Required

RTCA DO-200B

Radio Technical Commission for Aeronautics

– Standards for Processing Aeronautical Data

18 Jun 2015 Required

IEEE/EIA

12207.2

Institute of Electrical and Electronics Engineers/Electronic Industries Association Systems and software engineering — Software life cycle processes, Annex J

Apr 1998 Required

ARINC 653

ARINC Specification 653P1-4, Avionics Application Software Standard Interface, Part 1: Required Services

Aug 2015 Required

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 9

3 REQUIREMENTS

Software Application

The Contractor SHALL deliver a FMF Application to meet the requirements defined in the GS for FMF SW App. (CDRL A001)

3.1.1 Software Version Description (SVD)

The Contractor SHALL produce the SVD, identifying and describing a software version consisting of one or more Unit of Conformance (UoC). (CDRL A002)

The Contractor SHALL perform a cryptographic hash of each software executable file being delivered to the Government using the Secure Hash Algorithm (SHA) SHA-256. (CDRL A002)

Component and System Construction

3.2.1 Software Production

The Contractor SHALL construct the FMF Application in compliance with RTCA DO-178 and its supplements, as described by FAA AC 20-115, to the limits identified within this SOW.

To show RTCA DO-178 compliance, the Contractor SHALL support Stages of Involvement (SOI) audits as described in the FAA “Conducting Software Reviews Prior to Certification” (CSRPC) Job Aid, Revision 1.

The Contractor SHALL prepare and present evidence of RTCA DO-178 compliance at the SOI audits.

A table relating SOI audit questions to evidence documentation using hyperlinks is the preferred method of presentation.

The Contractor SHALL document the proceedings of the SOI audits, not to include the detailed evidence artifacts. (CDRL A003, CDRL A004, CDRL A005)

3.2.2 Software Refactoring

The Contractor SHALL analyze any legacy software source code reused for efficiency and scalability.

(CDRL A006)

The Contractor SHALL identify their strategy for refactoring (i.e., code/architecture improvement before and after functionality is implemented) any legacy software source code reused to ensure that the architecture and source code are easily expandable, modifiable and sustainable. (CDRL A006)

3.2.3 Software Defects

3.2.3.1 Software Control Board

The Contractor SHALL conduct regular Software Control Board (SCB) meetings consisting of Government and Contractor representatives to jointly analyze and prioritize software defects.

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 10

The Contractor SHALL ensure that the SCB includes the appropriate subject matter experts (SMEs) from the Contractor to support defect discussions.

The Contractor SHALL document software defects to include defect history, defect priority, legacy defects, and all Open, Closed, and Pending software defects. (CDRL A007)

The Contractor SHALL extract defects from the Contractor’s configuration management tool and report the defect data in support of the SCB.

3.2.3.2 Software Defects

Software defect priority classifications will be assigned by the Government in accordance with the (Institute of Electrical and Electronics Engineers/Electronic Industries Association) IEEE/EIA 12207 scale, Table 3.

The Contractor SHALL correct all Priority 1 and Priority 2 software defects identified prior to delivery of the final software products and associated construction artifacts.

The Contractor SHALL analyze Priority 3 defects to determine if an aggregation of Priority 3 defects results in a collective Priority 1 or 2 severity impact, as approved by the Government.

The Contractor SHALL correct the aggregated Priority 3 defects that are identified as having a Priority 1 or 2 impact. Remaining software defects, Priorities 3, 4, and 5, will be addressed at the discretion of the Government.

Table 3: IEEE/EIA 12207 Priority Rating

IEEE/EIA 12207 Priority Rating

Priority

1 a) Prevent the accomplishment of an essential capability

b) Jeopardize safety, security, or other requirement designated “critical”

2 a) Adversely affect the accomplishment of an essential capability and no work-around solution is known

b) Adversely affect technical, cost, or schedule risks to the project or to life cycle support of the system, and no work-around solution is known

3 a) Adversely affect the accomplishment of an essential capability but a work-around solution is known

b) Adversely affect technical, cost, or schedule risks to the project or to life cycle support of the system, but a work-around solution is known

4 a) Result in user/operator inconvenience or annoyance but does not affect a required operational or mission-essential capability

b) Result in inconvenience or annoyance for development or maintenance personnel but does not prevent the accomplishment of the responsibilities of those personnel

5 Any other effect

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 11

3.2.4 Software Security

The Contractor SHALL implement a set of coding standards which specifies the coding language, prohibited constructs/practices/patterns, and software comment requirements.

The Contractor SHALL utilize a minimum of two static analysis tools to measure software quality and software vulnerabilities. (CDRL A008)

The Contractor’s Software Vulnerability Analysis Report (SVAR) SHALL contain an executive summary, assessment approach, a list of assessment tools (including their purpose, method of use, applicable programming languages, error types, weaknesses, vulnerabilities types detected, and previous experience with each tool), a summary of findings, description of vulnerabilities identified, and mitigation recommendations. (CDRL A008)

The Contractor’s SVAR SHALL also contain an Extract of Software Application Tool Scan Results (Appendix A), Security Findings Issue Descriptions (Appendix B), and a Glossary of Terms (Appendix

C). (CDRL A008)

If the Contractor decides to use, with prior Government approval, an internally developed, proprietary, custom-developed, or non-commercial static analysis tool, the Contractor SHALL provide the Government with documentation that describes the purpose of the tool, the methods in which the tool is used, the programming languages applicable to the tool, and the types of errors, weaknesses, and vulnerabilities the tool is constructed to detect, as well as previous experience using the tool. (CDRL A008)

The Contractor SHALL provide software security-related training pertinent to individual job function for internal project managers, designers, developers, and testers assigned to this project.

3.2.5 Software Metrics

The Contractor SHALL implement measurement and metrics in accordance with NAVAIR Instruction (NAVAIRINST) 5234.5 and Standard Work Package (SWP) 4940-024.

The Contractor SHALL deliver a metrics report. (CDRL A009)

3.2.6 Reserved

3.2.7 Government Software Oversight

The Contractor SHALL provide notice via phone call or email to the Government Integrated Program Team Lead (IPTL) five (5) working days prior to Contractor Software Testing, Software Peer Reviews, Software Code Reviews, and Software Quality Assurance Audits.

The Government reserves the right to witness Contractor Software Testing.

The Government reserves the right to participate in:

Software Peer Reviews Software Code Reviews Software Quality Assurance Audits

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 12

3.2.8 Agile Software Development Methodology Requirements

If the Contractor chooses to use an Agile Software Development methodology, the requirements of this paragraph apply.

The Contractor SHALL conduct a Release Backlog Review (RBR) for each release (release is defined as multiple sprints/processes producing functional software).

For the RBR, the Contractor SHALL use requirement, and production evidence accumulated across multiple sprints to assess the maturity of the release product baseline and baseline the backlog.

3.2.9 Plan for Software Aspects of Certification (PSAC)

The Contractor SHALL construct and implement the PSAC. (CDRL A00A)

3.2.10 Software Development Plan (SDP)

The Contractor SHALL construct and implement the SDP. (CDRL A00B)

The Contractor SHALL utilize the SDP in software production.

3.2.11 FMF Software Application Specification

The Contractor SHALL produce a FMF Software Application Specification (Contractor’s FMF System/Subsystem Specification (SSS)) that reflects the requirements set forth in the GS for FMF SW App. (CDRL A00C)

The Contractor SHALL identify and document all additional capabilities provided by the software application that are not documented in the GS for FMF SW App. (CDRL A00C)

The Contractor SHALL document the requirements marked “Objective” in the GS for FMF SW App that the Contractor will achieve in their FMF Application. (CDRL A00C)

The Contractor SHALL analyze the traceability between the GS for FMF SW App and the Contractor’s

SSS. (CDRL A00C)

3.2.12 Software Requirements Specification (SRS)

The Contractor SHALL produce a SRS for each FMF Application UoC. (CDRL A00D)

The Contractor SHALL produce traceability between the Contractor’s SSS and their SRS. (CDRL A00D)

3.2.13 Software Design Description (SDD)

The Contractor SHALL produce a SDD for each FMF Application UoC. (CDRL A00E)

The Contractor SHALL analyze the traceability between the Contractor’s SRS and their SDD. (CDRL A00E)

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 13

3.2.14 Interface Design Description (IDD)

The Contractor SHALL describe in detail the interface construction between subsystem UoCs in the

IDD. (CDRL A00F)

3.2.15 Software Quality Assurance Plan (SQAP)

The Contractor SHALL produce a SQAP that identifies the organizations and procedures used to perform activities related to software quality. (CDRL A00G)

The Contractor SHALL utilize the SQAP for the project.

3.2.16 Software Quality Assurance Report (SQAR)

The Contractor SHALL produce a SQAR. (CDRL A00H)

3.2.17 Integration Constraints

The Contractor SHALL specify, as a series of Technical Performance Measures, the minimum hardware (Central Processing Unit (CPU), Random Access Memory (RAM), Read Only Memory (ROM), and input/output (I/O) throughput) requirements for the FMF Application to execute in peak conditions.

(CDRL A00E)

The Contractor SHALL specify any functions, processes or UoCs that cannot be interrupted during execution. (CDRL A00C)

If FMF Application partitioning is used, the Contractor SHALL specify all partitioning constraints relating to Aeronautical Radio, Incorporated’s ARINC 653 APEX (Application Executive) services, such as minimum visit time for a partition and maximum time between partition visits, that are required to support operation of the FMF Application. (CDRL A00J)

3.2.18 Configuration Management Plan (CMP)

The Contractor SHALL produce a CMP detailing how they plan to manage the product and documentation configuration. (CDRL A00K)

The Contractor SHALL manage the product and document configuration in accordance with the CMP.

3.2.19 Requirements Verification Matrix (RVM)

The Contractor SHALL produce a Specification RVM, traceable to each requirement, and provide method(s) (inspection, analysis, demonstration, and/or test), approach(es) (textual description), and venue(s) for each requirement’s verification. More than one verification method, approach, or venue may be applicable to a requirement. Verification addresses the performance aspects of a requirement or the function of a construction element. The venue identifies the point in which design verification (function) is completed. (CDRL A00L)

The Contractor SHALL utilize requirements traceability throughout all phases of the program.

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 14

The Contractor SHALL ensure traceability between the GS for FMF SW App requirements, all lower level requirements, test cases, and test procedures.

The Contractor SHALL demonstrate traceability throughout the system engineering effort as part of the SETR event design reviews.

3.2.20 Software Accomplishment Summary (SAS)

The Contractor SHALL produce a SAS, describing the compliance effort for the FMF Application.

(CDRL A00M)

The Contractor SHALL include in the SAS any compliance gaps to RTCA DO-178 objectives.

Software Safety

For this section, the term “System” is restricted to the FMF Application as it affects the safety of an aircraft upon integration. Safety-related aspects of an integrated aircraft, including computing hardware, not related to FMF Application functionality, are deferred to the integration efforts.

3.3.1 System Safety Assessment

The Contractor SHALL perform system safety in accordance with MIL-STD-882.

The Contractor SHALL support weekly safety meetings via virtual briefings. These meetings will be one hour in length. Minutes are required for these meetings. (CDRL A004)

The Contractor SHALL conduct analyses to identify and quantify hazards in software associated with the implementation of the FMF Application.

The Contractor SHALL implement a software system safety program in compliance with MIL-STD-882 and the attached “Software System Safety Level of Rigor (LOR) Requirements Tasks Table” (Attachment B of the solicitation).

The Contractor SHALL use the guidance provided in the “Joint Software System Safety Handbook” (JSSSEH) and MIL-HDBK-516.

The Contractor SHALL categorize risks associated with hazards using the NAVAIR “System Safety Hazard Risk Matrix” from NAVAIRINST 5100.3.

The Contractor SHALL categorize risks associated with software-related defects using Table B-1 of

MIL-STD-882.

The Contractor SHALL participate in and provide technical support for System Safety Working Groups (SSWGs) in compliance with MIL-STD-882 Task 105. The Contractor SHALL conduct the SSWGs at the Contractor facility.

The Contractor SHALL support SSWGs no later than 30 days prior to each SETR event (except for RBRs if using Agile Software Development) or bi-annually if there are no SETR events planned.

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 15

The Contractor SHALL support the SSWG by briefing assigned topics, providing status on safety program tasks, adjudicating hazards, and providing support to technical area experts (TAE) to resolve process and/or technical issues related to the system safety effort.

3.3.2 System Safety Program Plan (SSPP)

The Contractor SHALL produce a SSPP in compliance with MIL-STD-882 Task 102 and the attached “Software System Safety Level of Rigor (LOR) Requirements Tasks Table” (Attachment B of the solicitation) that documents the system safety methodology for the identification, classification, and mitigation of safety hazards as part of the overall Systems Engineering (SE) and Software Development (SD) processes. (CDRL A00N)

The Contractor SHALL address software safety specific tasks and processes. (CDRL A00N)

The Contractor SHALL execute the software system safety program in accordance with a documented

SSPP.

The Contractor SHALL perform MIL-STD-882 tasks 102, 104, 105, 106, 401, 201, 202, 203, 204, 208, 301, and 304.

The Contractor SHALL perform all hazard analyses under the System Safety Program to include system interfaces and contributions associated with Commercial-Off-the-Shelf (COTS) items, Government-Off-the-Shelf (GOTS) items, Government-Furnished Equipment (GFE) items, and Non-Developmental Items (NDI).

3.3.3 Software Criticality Assessment and Software Level of Rigor (LOR) Tasks

The Contractor SHALL assess software contributions to hazards in accordance with MIL‐STD‐882.

The Contractor SHALL perform software LOR tasks in accordance with MIL-STD-882 and the attached “Software System Safety Level of Rigor (LOR) Requirements Tasks Table” (Attachment B of the solicitation), commensurate with the Software Criticality Index (SwCI) assigned in accordance with MIL‐STD‐882 for safety significant software functions.

3.3.4 Safety Assessment Report (SAR)

The Contractor SHALL produce a SAR that includes the results of the tasks performed under the System Safety Program. (CDRL A00P)

The Contractor SHALL perform the following MIL-STD-882 hazard analyses tasks: 201, 202, 203, 204, 208, 301 and 304. (CDRL A00P)

The Contractor SHALL produce the Hazard Tracking System (HTS) developed under MIL-STD-882 Task 106. (CDRL A00Q)

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 16

Open System Architecture

3.4.1 Modular Open Systems Approach

The Contractor SHALL produce and implement an Open System Management Plan (OSMP). (CDRL A00R)

The Contractor SHALL conform to the FACE Technical Standard for using modular design as defined in the GS for FMF SW App.

Note: The Government defines FACE version 2.1 and FACE Shared Data Model version 2.1.34 as the minimum baseline, but the Contractor may propose FACE conformance to later versions of the FACE Technical Standard and Shared Data Model.

The Contractor SHALL ensure that all FACE Conformance tools and documentation align with the version of the FACE Technical Standard used.

The Contractor SHALL address issues identified with the FACE Technical Standard through the FACE Problem Report (PR) & Change Request (CR) Ticketing System.

The Contractor SHALL produce the Software Architecture Document (SAD), which describes their software approach to meet FMF Application requirements, as defined in the GS for FMF SW App.

(CDRL A00J)

The Contractor SHALL ensure the construction approach results in data-centric software modules that are independent of one another, and not tied to a specific behavior of another module implementation (low coupling).

The Contractor SHALL define dependencies on all run time libraries and frameworks and where they interface to the FMF Application.

The Contractor SHALL define the specific run-time library and framework services in the SAD. (CDRL A00J)

The Contractor SHALL ensure the construction approach results in modules characterized by the singular assignment of identifiable and discrete functionality (high cohesion).

The Contractor SHALL produce FACE Data Model documentation. (CDRL A00S)

The Contractor SHALL, within the data model, use the “Optional Period Property” field within the FACE UoC Supplied Model (USM) to describe expected component operation.

3.4.2 Future Airborne Capability Environment (FACE) Conformance

The Contractor SHALL complete FACE Conformance in accordance with the FACE Conformance Policy.

The Contractor SHALL complete the FACE Conformance Verification Matrix (CVM) for each UoC.

(CDRL A00T)

The Contractor SHALL propose the version of the Conformance Test Suite that corresponds to the version of the FACE Technical Standard for Government approval at a Test Readiness Review (TRR).

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 17

Systems Engineering Master Plan

The Contractor SHALL produce a System Engineering Management Plan (SEMP) that constructs the overall plan for the engineering management of the FMF Application effort. (CDRL A00U)

The Contractor Systems Engineering efforts SHALL be performed in accordance with SEMP.

Systems Engineering Technical Reviews (SETR)

The Contractor SHALL conduct SETR events for the FMF Application project. (CDRL A003 and

CDRL A004)

The Contractor SHALL produce and present presentation packages for each SETR event. (CDRL A005)

The Contractor SHALL support the Government SETR event readiness assessments and completion of SETR checklists for each event.

The Government WILL chair SETR events, in accordance with NAVAIRINST 4355.19. The list of reviews includes System Requirements Review (SRR)/System Functional Review (SFR), Preliminary Design Review (PDR), Critical Design Review (CDR), Release Backlog Review (RBR) (if using Agile) and a Test Readiness Review (TRR) for Functional Qualification Testing (FQT).

With Government approval, some reviews may be combined to streamline the process. The Contractor SHALL define their proposed SETR plan in their SEMP (CDRL A00U) along with the rationale for combining events. The Contractor is expected to propose tailored SETR events, based upon the maturity of their baseline software and the additional Non-Recurring Engineering (NRE) effort required to make their baseline software compliant to the GS for FMF SW App. The SETR events identified below are expected for a major NRE effort. If the Contractor tailors the SETR events defined below based upon a reduced NRE effort, it is expected to be fully defined in their proposal. SRR/SFR, CDR, and TRR for FQT are required for all efforts.

3.6.1 System Requirements Review/ System Functional Review (SRR/SFR)

The Contractor SHALL conduct a combined SRR and SFR. The review will be held at Naval Air Station (NAS), Patuxent River, Maryland, or in the immediate vicinity.

3.6.1.1 SRR/SFR Entry Criteria

The timing of the SRR/SFR is driven by the FMF Application maturity. The Contractor SHALL schedule the SRR/SFR when the entry criteria described below are achieved:

Functional Baseline has been delivered.

Program Cost and Schedule update has been delivered.

Program Risk database has been delivered.

3.6.1.2 Data to Be Presented at SRR/SFR

The Contractor SHALL present the following at SRR/SFR:

Program Overview (cost, schedule, and staffing - to include SOI events)

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 18

Updated Risk assessment Functional overview of each FMF Application and including:

o Inputs, processing, and outputs of each functional component o Control flow and data flow between each functional component o FACE Data Model (preliminary)

FMF Application requirements as defined in the GS for FMF SW App and repackaged into the Contractor’s FMF Software Application Specification (CDRL A00C), including:

o Execution time, storage requirements, quality factor requirements; i.e., Correctness, Reliability, Efficiency, Integrity, Usability, Maintainability, Testability, Flexibility, Portability, Reusability, and Interoperability o Key Performance metrics o Requirements Traceability

Functional qualification requirements for the FMF Application FACE Conformance Requirements for the FMF Application Any special delivery requirements for the UOC Metrics Report

3.6.1.3 SRR/SFR Exit Criteria

The Contractor SHALL consider SRR/SFR complete when:

All Action Items submitted during the technical review have been appropriately addressed.

All Action Items assigned to the Contractor required for review/closure have been completed and approved by the required parties.

The requirements have been deemed adequate for the effort and are well understood by both parties.

The functional baseline has been presented and approved.

The Government and the Contractor concur the program risk level is acceptable.

The functional baselines have been updated in the applicable configuration management systems.

The Government Chair formally closes the review.

3.6.2 Preliminary Design Review (PDR)

The Contractor SHALL conduct a PDR. The purpose of the PDR is to ensure the system is sufficiently mature and ready to meet the stated performance requirements within program budget, schedule, risk, functional baseline, and other program and system constraints. The PDR SHALL be held at the Contractor-designated facility.

3.6.2.1 PDR Entry Criteria

The timing of the PDR is driven by product maturity. The Contractor SHALL schedule the PDR when the entry criteria described below are achieved:

Allocated Baseline has been delivered.

Program Cost and Schedule update has been delivered.

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 19

Program Risk database has been delivered.

3.6.2.2 Data to be Presented at PDR

As a minimum, the Contractor SHALL present the following at the PDR:

Program Overview (cost, schedule, and staffing) updates Technical requirements update Requirements Traceability updates Risk updates FMF Application construction o FACE Data Model o FMF Functional construction with emphasis on changes to the core FMF o FACE technical aspects of FMF Application construction o UoC functionality o Data Integrity Design for the FMF Application o Safety Hazard Analysis based on SAR

FQT plan FACE Conformance plan Metrics Report

3.6.2.3 PDR Exit Criteria

The Contractor SHALL consider PDR complete when:

All Action Items submitted during the technical review have been appropriately addressed.

All Action Items assigned to the Contractor required for review closure have been completed and approved by the required parties.

The requirements have been deemed adequate for the effort and are well understood by both parties.

The allocated baselines have been presented and approved.

The Government and the Contractor concur the program risk level is acceptable.

Any baseline updates have been updated in the applicable configuration management systems.

The Government Chair formally closes the review.

3.6.3 Critical Design Review (CDR)

The Contractor SHALL conduct a CDR. The purpose of the CDR is to ensure the system is adequate to proceed in coding, system integration, demonstration and test and can meet the stated performance requirements within budget, schedule, risk, initial product baseline, and other system constraints. The CDR SHALL be held at the Contractor-designated facility.

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 20

3.6.3.1 CDR Entry Criteria

The timing of the CDR is driven by product maturity. The Contractor SHALL schedule a CDR when the entry criteria described below are achieved.

Product Baseline has been delivered.

Program Cost & Schedule update has been delivered.

Program Risk database has been delivered.

3.6.3.2 Data to be Presented at CDR

As a minimum, the Contractor SHALL present the following at the CDR:

Program Overview (cost, schedule, and staffing) updates Technical requirements update Requirements Traceability updates RVM updates Risk updates FMF Application construction o FACE Data Model o FMF Functional construction with emphasis on changes to the core FMF o FACE technical aspects of FMF Application construction o UoC functionality o Data Integrity Design for the FMF Application o Safety Hazard Analysis based on Safety Assessment Report

FQT plan FACE Conformance plan Metrics Report

3.6.3.3 CDR Exit Criteria

The Contractor SHALL consider CDR complete when:

All Action Items submitted during the technical review have been appropriately addressed.

All Action Items assigned to the Contractor required for review closure have been completed and approved by the required parties.

The requirements have been deemed adequate for the effort and are well understood by both parties.

The product baselines have been presented and approved.

The Government and the Contractor concur the program risk level is acceptable.

Any baseline updates have been updated in the applicable configuration management systems.

The Government Chair formally closes the review.

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 21

3.6.4 Test Readiness Review for Functional Qualification Testing (TRR for FQT)

The Contractor SHALL conduct a TRR prior to performing FQT for score. The purpose of the TRR for FQT is to assess test objectives, test methods and procedures, test scope, and readiness for Contractor FQT. The TRR for FQT SHALL be held at the Contractor-designated facility.

3.6.4.1 TRR for FQT Entry Criteria

Test objectives delivered.

Test procedures delivered and traced to requirements.

Test environment definition has been delivered.

Test environment resources ready.

Risk assessment delivered.

Software Test Plan.

Metrics Report.

3.6.4.2 Data to be Presented at TRR for FQT

Program Overview (cost, schedule, and staffing) Risk assessment/updates Measurement Data (Metrics) Test Program Overview, including the test schedule Identification of any preliminary testing already conducted, including a summary of test results Status of all open software problem/defect reports Required test resources (personnel, facilities, test environment, and test assets) Status of outstanding deficiencies with the test environment (i.e., SIL) and their impact upon execution of FQT Status of test procedures, test cases, and traceability Status of RVM Software Test Plan changes Final reporting process/format defined Recommendation on readiness to commence testing and a mitigation plan for addressing technical issues and obstacles during tests

3.6.4.3 TRR for FQT Exit Criteria

The Contractor SHALL consider TRR for FQT complete when:

All Action Items identified during the TRR for FQT have been appropriately addressed.

All Action Items assigned to the Contractor required for review closure have been completed and approved by the required parties.

The requirements have been deemed adequate for the effort and well understood by both parties.

The test procedures have been presented and approved. The test environment has been defined and approved.

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 22

The Government and the Contractor concur the program risk level is acceptable.

Test procedures to conduct formal testing for the record and for dry run testing are approved.

The Government technical lead or Chair formally closes the review.

3.6.5 Release Backlog Review (RBR)

The Contractor SHALL conduct a RBR for each release if using Agile Software Development.

The purpose of RBR is to:

1) Assess maturity of release.

2) Assess the backlog allocated to Sprints and Releases delivery.

3) Ensure the system integration plan is complete for the release to:

Gauge execution progress of sprints and the current release.

Gauge release capabilities in satisfying system requirements.

Assure synchronization of all sprint teams.

Assess impact of new requirements and/or reallocating requirements from one release to another on overall system construction.

Assure that release timing is appropriate to maximize integration and test effectiveness.

Review plans for current and future releases.

3.6.5.1 RBR Entry Criteria & Data to be Presented

The following items should be part of the standard review agenda and presented at an RBR:

Backlog list (user stories), current allocation to each sprint and release.

Annotated changes to the backlog list, i.e., sprint and release previously assigned to, which ones were modified/added/deleted since the previous RBR.

Rework quantification and backlog allocation to Sprints and Releases Sprint teams (or supplier teams) and their synchronization mechanism process/status.

Traceability, release functionality to system requirements.

Software analysis and assessment progress, i.e., all Sprint assessments within release, and results.

Update of the User Story Rework Status Table.

Update of Agile Software Development metrics.

o Computer resource utilization metrics have been updated to reflect the latest release.

o Software construction execution metrics have been updated to reflect the latest release.

Systems Integration planning.

Laboratory simulation/stimulation updates.

Updates to laboratory toolsets for data requirements.

Developer CM processes to ensure accurate tracking of changes is utilized as requirements are reallocated to/from sprints.

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 23

3.6.5.2 RBR Exit Criteria

The RBR ensures that all user stories in the backlog are assigned to a sprint, either completed or scheduled. The review also assesses the management of the backlog, which is the main focus in Agile Software Development. In this regard, the following are exit criteria:

User stories for the next release are assigned to the follow-on sprint(s).

Releases and release functionality are identified.

All sprint teams are synchronized with respect to the backlog.

New requirements are appropriately factored into the backlog.

There is traceability between release functionality and requirements.

Credit is taken for verification and validation, with the possibility of laboratory testing.

Releases are occurring at logical intervals.

All Action Items identified during the RBR have been appropriately addressed.

All Action Items assigned to the Contractor required for review closure have been completed and approved by the required parties.

The requirements have been deemed adequate for the effort and well understood by both parties.

The test procedures have been presented. The test environment has been defined.

The Government and the Contractor concur the program risk level is acceptable.

Technical Interchange Meetings (TIMs)

The Contractor SHALL support quarterly TIMs to facilitate the exchange of technical information needed to resolve system/subsystem issues. Half of the planned TIMs will be conducted at the Contractor facility and the other half of the planned TIMs will be held at Naval Air Station (NAS), Patuxent River, Maryland, or in the immediate vicinity. TIMs may be combined with other reviews or meetings as appropriate. Additionally, virtual briefing capabilities will be used where possible to reduce the amount of program travel. When travel is required, only the minimum required personnel will travel, and the rest will join the meeting via virtual briefing tools. (CDRL A003, CDRL A004, and

CDRL A005)

Weekly Engineering Meetings

The Contractor SHALL support weekly engineering meetings via virtual briefings. These meetings will be no longer than two hours. Formal agendas and minutes are not required for these meetings.

External Databases

3.9.1 Navigation Database (NDB)

The Contractor SHALL define the format the FMF Application requires for digital NDB data. (CDRL A00V)

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 24

3.9.1.1 Navigation Database Packing Tool

If the Contractor's implementation requires an NDB Packing Tool that converts the Digital Aeronautical Flight Information File (DAFIF) NDB format to the NDB format consumable by the FMF Application, then the Contractor SHALL deliver the Packing Tool. (CDRL A00W)

If the Contractor's implementation requires an NDB Packing Tool, then the Contractor SHALL provide evidence that the Packing Tool complies with the requirements of RTCA DO-200. (CDRL A00X)

3.9.2 Magnetic Variation (MAG VAR)

The Contractor SHALL define the format the FMF Application requires for MAG VAR data. (CDRL A00V)

3.9.3 Performance Databases

The Contractor SHALL define the format(s) the FMF Application requires for external aircraft performance databases. (CDRL A00Y)

Operational Program Configuration (OPC)

The Contractor SHALL define the format the FMF Application requires for the Operational Program Configuration (OPC) file(s). (CDRL A00F)

Note: If the Contractor’s implementation requires an Operational Configuration File to enable optional Contractor-managed features, then the file may be subdivided into a Contractor-managed OPC and a Government-managed OPC.

The Contractor SHALL document each configurable function and feature contained within the FMF Application by name, short description, map to the Software Design Description (SDD) paragraph(s), and the mechanism required to enable/disable those features. (CDRL A00Z)

Test Program

The Contractor SHALL implement a test program to assess the performance of the FMF Application against the requirements of this SOW, the GS for FMF SW App, and lower level requirements.

The Contractor SHALL perform one or more of the following methods to analyze compliance to requirements:

Inspection (I): Inspection is an element of verification that involves a visual examination of the item/system, a review of descriptive documentation, gauging or measurement, and comparing the characteristics with a predetermined standard to determine conformance to requirements without the use of special laboratory equipment or procedures.

Analysis (A): Analysis is an element of verification that uses established technical or mathematical models or simulations, algorithms, charts, graphs, circuit diagrams, data, or other scientific principles and procedures to provide evidence that stated requirements were met.

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 25

Demonstration (D): Demonstration is an element of verification that involves the actual operation of an item. Operation or performance is verified through action and observation of responses with no specific analysis, instrumentation or quantitative data collection.

Demonstration is used when quantitative assurance is not required for verification of requirements. Used for verification of requirements that have an On-Off/Yes-No response.

Test (T): Test is an element of verification designed to provide data on functional features, performance or equipment operation under fully controlled and traceable conditions. The data is used to evaluate quantitative characteristics. Operation or performance is verified through action with specific instrumentation or data collection. Implicitly requires analysis.

The Contractor SHALL assess by Test all Inputs/Outputs to the FMF Application to prove the FMF Application conforms to the GS for FMF SW App requirements and lower level requirements.

3.11.1 Software Test Plan (STP)

The Contractor SHALL produce a Software Test Plan that describes the scope of testing necessary to analyze the FMF Application across differing platforms and host environments. (CDRL A010)

3.11.2 Software Test Description (STD)

The Contractor SHALL produce a Software Test Description which delineates test preparations, test cases, and test procedures to be used for testing. (CDRL A011)

3.11.3 Functional Qualification Test (FQT)

The Contractor SHALL conduct FQT using the Software Test Descriptions (STD) and Software Test Plan (STP).

The Contractor SHALL facilitate Government witnessing of the FQT.

The Contractor SHALL document the results of the FQT in a Functional Qualification Test Report.

(CDRL A012)

The Contractor SHALL perform penetration testing on the software as part of the overall Functional Qualification Test Report. (CDRL A012)

3.11.4 Systems Integration Lab (SIL)

3.11.4.1 Contractor Systems Integration Lab (SIL)

The Contractor SHALL utilize a SIL throughout the period of performance.

The Contractor SHALL use the SIL to analyze requirements identified in the GS for FMF SW App and lower level documentation.

The Contractor SHALL document all items that would allow the system Integration Lab software and hardware to be fully replicated. (CDRL A013)

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND 42.1503 26

3.11.4.2 Government Systems Integration Lab (SIL)

The Contractor SHALL support the installation of the FMF Application, to include production of object code compiled on the target software environment, and verification of the Transport Service interface in the Government SIL (SIL supporting FACE applications). (CDRL A001)

The Contractor SHALL support portability testing of the installed FMF Application in the Government

SIL.

FMF Application Platform Integration Support

3.12.1 General

The Contractor SHALL recompile the FMF Application source code and deliver GS for FMF SW App-compliant executable files and associated version documentation for target platform hardware and operating systems.

The recompiled executable(s) will be considered the baseline FMF Application configuration and version for that specific platform for the purposes of licensing.

NOTE: This requirement may result in multiple, separate integration support activities, which are at the scheduling and discretion of the Government.

These efforts will require the Contractor to travel to a Government-designated location to perform required support activities.

Program Management

The Contractor SHALL identify and utilize a single management point of contact (Program Manager - PM) that will be responsible and have authority for the control and coordination of all work performed under this SOW.

The Contractor SHALL identify and utilize a single technical point of contact (Technical Program Manager - TPM) to be the technical liaison to the government, ensuring that all technical requirements and tasks are successfully met.

The Contractor SHALL report the technical and financial status of the program including tasks completed, issues, risk mitigation plans, as well as a 30-day look-ahead of milestone activities. (CDRL A014)

As part of this report, the Contractor SHALL provide funding and man-hour expenditures inclusive of past and current reporting period compared to planned, baseline values. (CDRL A014)

The Contractor SHALL construct an organization chart and identify points of contacts to address technical questions and programmatic issues for this contract.

3.13.1 Integrated Master Schedule (IMS)

The Contractor SHALL prepare an Integrated Master Schedule (IMS). For the basis of program performance and schedule assessment, program and technical reviews will be addressed as major

SOURCE SELECTION INFORMATION - SEE FAR 2.101 3.104 AND…