SOW_for_RNP_RNAV_FMF_v2.7_(20161222).docx

STATEMENT OF WORK

FOR

FLIGHT MANAGEMENT FUNCTION (FMF)

SOFTWARE APPLICATION

22 DECEMBER 2016

Table of Contents

4 RESERVED

List of Tables

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 through the Communication, Navigation, Surveillance/Air Traffic Management (CNS/ATM) program which defines these capabilities. Specifically, PMA209 at NAVAIR, is responsible for planning and budgeting to ensure all Navy and Marine Corps aircraft are compliant with these capabilities.

The effort within this Statement of Work is to create a (Future Airborne Capability Environment (FACETM) Conformant Flight Management Function (FMF) software application that can be used on multiple aircraft type/model/series aircraft to achieve this capability. In this document the FMF software application is referred to as the FMF application or FMF App. The Government Specification for Flight Management Functionality (FMF) Software Application within this document will hereby be called The Government FMF application specification.

This Statement of Work (SOW) defines the tasks to be accomplished by the Contractor in support of the United States Navy (USN), FMF application. The role of the Contractor consists of two main areas:

1. The design, develop, test and to deliver a FACE conformant FMF application.

2. To develop and deliver all software and supporting documentation for the project including, but not limited to, items found on the Contract Data Requirements List (CDRL).

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 list is considered as guidance unless otherwise noted below. Nothing in this SOW however, supersedes applicable laws and regulations unless a specific exemption has been obtained.

Applicable Documents Table 1: Applicable Documents

REQUIREMENTS

Software The Contractor SHALL develop a FMF Software Application to meet the requirements defined in the Government Specification of Flight Management Functionality (FMF) Software Application. (CDRL A001) Component and System Design Software Development The Contractor SHALL develop the FMF Software Application in compliance with DO-178.

To show 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, Rev 1.

Software Refactoring The Contractor SHALL analyze any legacy software source code reused for efficiency and scalability. (CDRL A002)

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 A002) Software Defects The Contractor SHALL track defects that includes software defect history, including defect priority, legacy defects and all Open, Closed, and Pending software defects. (CDRL A005)

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

The Contractor SHALL report defects to support the SCCB as part of the Data Accession List (DAL).

The Contractor SHALL ensure that the SCCB consists of the appropriate subject matter experts from the Contractor to support defect discussions.

The Contractor SHALL correct all Priority 1 and Priority 2 software defects identified prior to delivery of the final software products and associated design 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.

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

Software defect priority classifications SHALL be assigned in accordance with the IEEE12207 scale.

Table 2: IEEE 12207 Priority Rating IEEE 12207 Priority Rating

Priority

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

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

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

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

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

The Contractor SHALL utilize at least two different commercial or open source static analysis tools to measure software quality and vulnerabilities. (CDRL A005)

The Contractor SHALL utilize at least two different commercial or open source dynamic analysis tools to measure software quality and vulnerabilities. (CDRL A005)

The Contractor SHALL provide appropriate security training pertinent for their job function for project managers, designers, developers, and testers assigned to this project.

Software Metrics The Contractor SHALL implement measurement and metrics in accordance with NAVAIRINST 5234.5 and Standard Work Package SWP4940-024.

The Contractor SHALL create a metrics report. (CDRL A006) Reserved Government Software Oversight 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 Software Integration Laboratory (SIL) The Contractor SHALL maintain a SIL.

The Contractor SHALL use the SIL to verify requirements identified in the Government FMF application specification and lower level documentation.

These tests SHALL be executed prior to software delivery. (CDRL A007)

The Contractor SHALL describe the Contractor’s test environment, set up, equipment, hardware and software versions and hardware and software descriptions. (CDRL A008)

The Contractor SHALL develop a SIL Functionality Test Plan to perform the test to verify that the SIL operates correctly and repeatedly. (CDRL A009) Agile Software Development Requirements The following requirements apply if the Contractor chooses to use an Agile software development methodology.

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

The RBR SHALL use requirement, design and test evidence accumulated across multiple sprints to assess the maturity of the release product baseline and baseline the backlog.

Software Development Plan (SDP) The Contractor SHALL maintain the Software Development Plan. (CDRL A010)

The Contractor SHALL manage the software development as documented in the SDP.

FMF System Specification The Contractor SHALL develop a FMF System Specification that reflects the requirements set forth in the Government FMF application specification. (A011) Software Requirements Specification (SRS) The Contractor SHALL develop a Software Requirements Specification (CDRL A012).

Software Design Description (SDD) The Contractor SHALL develop a Software Design Description for each FMF application Computer Software Configuration Item (CSCI). (CDRL A013) Interface Design Description (IDD) The Contractor SHALL describe the detailed design of the interfaces between subsystems CSCIs in Interface Design Description (CDRLA014).

Interface Control Document (ICD) The Contractor SHALL develop the system-level Interface Control Document (ICD). (CDRL A015) Software Test Description (STD) The Contractor SHALL develop the test preparations, test cases, and test procedures to be used to perform qualification testing.

The Contractor SHALL develop the Software Test Description (STD). (CDRL A016) Software Quality Assurance Plan (SQAP) The Contractor SHALL develop a Software Quality Assurance Plan that identifies the organizations and procedures used to perform activities related to the Software Quality.

The Contractor SHALL manage the software quality assurance in accordance with the Software Quality Assurance Plan. (CDRL A017) Software Quality Assurance Report (SQAR) The Contractor SHALL develop a Software Quality Assurance Report (CDRL A018) Software Version Description (SVD) The Contractor SHALL produce the SVD identifying and describing a software version consisting of one or more CSCIs (CDRL A019) Integration Constraints The Contractor SHALL describe the minimum hardware (CPU, RAM, ROM, and input/output throughput requirements for the FMF App to execute in nominal conditions. (A011)

The Contractor SHALL describe the minimum hardware (CPU, RAM, ROM, and input/output throughput) requirements for the FMF App to execute in peak conditions. (A011)

The Contractor SHALL document any functions or CSCIs that cannot be interrupted during execution. (A011)

The Contractor SHALL document the minimum hardware configuration (including processors, displays, computers, test equipment, etc.) used during vendor testing. (A011)

The Contractor SHALL document the minimum supporting software (OS, I/O, test equipment, etc.) used for vendor testing. (A011)

If partitioning is used, the Contractor SHALL define and document all partitioning constraints relating to ARINC 653 APEX services, such as minimum visit time for a partition and maximum time between partition visits, that are required to support seamless operation of the FMF application. (CDRL A011) Configuration Management Plan (CMP) The Contractor SHALL develop a Configuration Management Plan detailing how they plan to manage the product and documentation configuration.

The Contractor SHALL manage the configuration in accordance with the Configuration Management Plan. (CDRL A020) Requirements Verification Matrix (RVM) The Contractor SHALL develop a Specification Requirements Verification Matrix (RVM) traceable to each requirement, and providing a method (inspection, analysis, demonstration, and/or test), approach (textural description), and venue for each verification. More than one verification method, approach, venue may be applicable to a requirement. Verification addresses the performance aspects of a Requirement or the form/fit/function of a design element. Venue identifies the point in which design verification (form, fit, function) is completed. (CDRL A021)

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

· Inspection (I): Verification by a visual examination of the item/system, reviewing 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. Inspection may be performed by either quality assurance or qualified non-quality personnel.

· Analysis (A): Verification by technical/mathematical evaluation using mathematical models, charts, and data to show that the requirements have been met. Demonstration or Test may be substituted for analysis.

· Demonstration (D): Verification of operation or performance to the requirement without recording specific quantitative data except for checklists or not using specific collecting methods or tools to verify the requirement. The item/system may be instrumented, and quantitative limits of performance are monitored, but actual data is not required to be recorded; just a pass/fail is recorded.

· Test (T): Verification of operation or performance to the requirement while recording specific quantitative data or using specific collecting methods or tools to verify the requirement. The item/system is instrumented, quantitative limits of performance are monitored, and the actual data is required to be recorded.

Software Accomplishment Summary (SAS) The Contractor SHALL develop a SAS describing the compliance effort for the FMF software. (CDRL A022) Software Safety System Safety Assessment The Contractor SHALL perform system safety in accordance with MIL-STD-882.

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

The Contractor SHALL implement a software system safety program in compliance with MIL-STD-882, the Joint Software System Safety Handbook (JSSSEH), MIL-HDBK-516 and the attached Software System Safety Level of Rigor (LOR) Requirements Tasks Table (Attachment A).

The Contractor SHALL execute the software system safety program in accordance with a documented System Safety Program Plan (SSPP). (CDRL A023)

The safety program SHALL be applicable to the entire effort defined in the SOW.

Risks associated with hazards SHALL be categorized using the NAVAIR System Safety Hazard Risk Matrix from NAVAIRINST 5100.3.

Risks associated with software-related defects SHALL be categorized using Table B-1 of MIL-STD-882.

The Contractor SHALL be a technical advisor to the System Safety Working Groups (SSWG) in compliance with MIL-STD-882.

The Contractor SHALL participate in and provide technical support for SSWGs on a bi-annual basis.

This support SHALL include briefing assigned topics, providing status on safety program tasks, adjudication of hazards, providing appropriate technical area expert (TAE) support to resolve process or technical issues related to the system safety effort.

System Safety Program The Contractor SHALL develop a System Safety Program Plan (SSPP) in compliance with MIL-STD-882 Task 102 and the attached Software System Safety Level of Rigor (LOR) Requirements Tasks Table (Attachment A) 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 processes.

The SSPP SHALL address software safety specific tasks and process. (CDRL A023)

In addition to Task 102, the Contractor SHALL perform MIL-STD-882 tasks 104, 105, 106, 401, and the following hazard analyses tasks: 201, 202, 203, 204, 208, 301 and 304. (CDRL A023)

Additionally, for each of the preceding tasks, the Contractor SHALL comply with the requirements delineated for each where applicable in the attached Software System Safety Level of Rigor (LOR) Requirements Tasks Table (Attachment A).

All hazard analyses performed under the System Safety Program SHALL 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), to include software.

The hazard tracking system (HTS) developed under Task 106 SHALL be produced with each delivery.

Software Criticality Assessment and Software Level of Rigor (LOR) Tasks Software contributions to hazards SHALL be assessed in accordance with MIL‐STD‐882.

Software Level of Rigor (LOR) tasks SHALL be performed in accordance with MIL-STD-882 and the attached Software System Safety Level of Rigor (LOR) Requirements Tasks Table (Attachment A) commensurate with the Software Criticality Index (SwCI) assigned in accordance with MIL‐STD‐882 for safety significant software functions.

Safety Assessment Report (SAR) The Contractor SHALL develop a Safety Assessment Report (SAR) that includes the results of the tasks performed under the system safety program. (CDRL A024) Open System Architecture Modular Open Systems Approach The Contractor SHALL develop and maintain an Open System Management Plan (OSMP). (CDRL A003)

The Contractor SHALL conform to the Future Airborne Capability Environment (FACE) Standard for using modular design as defined in the FMF application specification. The government defines FACE version 2.1 as the minimum baseline, the Contractor can propose FACE conformance to later versions of the FACE Technical Standard (TS). (Ref FACE TS)

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

The Contractor SHALL demonstrate compliance with the open systems approach during SETR and TIM events as defined in the OSMP. (CDRL A003)

The Contractor SHALL demonstrate progress towards conformance with the FACE Standard during SETR and TIM events. (CDRL A006)

The Contractor SHALL develop the Software Architecture Document (SAD) which describes their software approach to meet FMF application requirements as defined in the Government FMF Specification. (CDRL A025)

The Contractor SHALL ensure the design 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 app.

The Contractor SHALL define the specific run time library and framework services in the Software Design Description (SDD).

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

The Contractor SHALL develop data model documentation. (CDRL A026)

The Contractor SHALL, within the data model, use the optional timing field within the FACE Unit of Performance (UoP) Supplied Model (USM) to describe component behavior.

FACE Conformance The Contractor SHALL complete the FACE Conformance Verification Matrix (CVM) Edition 2.1 or later for each Unit of Conformance (UoC). (CDRL A027)

The Contractor SHALL propose the version of the Conformance Test Suite from the V2.1 series for Government approval at a Test Readiness Review (TRR).

The Contractor SHALL perform verification utilizing the Government approved Conformance Test Suite.

The Contractor SHALL provide FACE conformance testing status and FACE conformance-testing metrics. (CDRL A006)

The Contractor SHALL resolve all deviations from the Conformance Verification Matrix.

Systems Engineering The Contractor SHALL develop a System Engineering Management Plan (SEMP) that establishes the overall plan for the engineering management of the FMF Application effort.

The Contractor Systems Engineering efforts SHALL be performed in accordance with the Systems Engineering Management Plan (SEMP).

The SEMP SHALL demonstrate an integrated Systems Engineering approach for developing the software based on The Government FMF application specification, and verifying functional and FACE requirements, and providing the artifacts necessary to satisfy system safety requirements.

The Contractor SHALL utilize requirements traceability throughout the modification, production, and verification phases of the program.

Traceability SHALL include all levels of the system and subsystem requirements. (CDRL A028)

System Engineering Technical Reviews (SETR)

The Contractor SHALL participate in SETR events for the FMF application project. (CDRL A034 and CDRL A035)

The reviews SHALL be conducted in accordance with NAVAIRINST 4355.19. The list of reviews includes System Requirements Review-2 (SRR-2), System Functional Review (SFR), Preliminary Design Review (PDR), Critical Design Review (CDR), and a Functional Qualification Test Readiness Review (TRR). Some reviews may be combined to streamline the process.

The Contractor SHALL develop the necessary presentation packages for each SETR event. (CDRL A029)

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

Systems Requirements Review (SRR)-2/Systems Functional Review (SFR) The Contractor SHALL conduct a combined software Systems Requirements Review (SRR)-2 and System Functional Review (SFR) for the software aspects of the FMF application. The SRR/SFR is a formal review to ensure that the requirements, including the system specification, SOW and DoD Directives are complete and understood; and to approve the functional allocation of the requirements. The review will be held on the Naval Air Station Patuxent River Maryland or in the immediate vicinity.

SRR-2/SFR Documentation Documentation required to support the SRR includes:

a) The Contractor Specification (also known as the System/Subsystem Specification (SSS)

b) Specification Requirements Verification Matrix (RVM)

c) Software Transition Plan (STRP)

d) Software Development Plan (SDP)

e) System Safety Program Plan (SSPP)

f) Interface Requirements Specification (IRS)

g) Software Requirements Specification (SRS)

h) Safety Assessment Report (SAR)

i) Open Systems Management Plan (OSMP) Data To Be Presented at SRR-2/SFR The Contractor SHALL present the following at SRR:

a) Integrated Master Schedule

b) Updated cost data

c) Staffing profile (projection and shortfalls)

d) Updated Risk assessment

e) Functional overview of the FMF App and each functional decomposition within the FMF App including:

· Inputs, processing, and outputs of each functional component.

· Control flow and data flow between each functional components

· FACE Data Model (preliminary)

f) FMF App requirements as defined in the Government Specification and repackaged into the Contractor’s specification, including:

· Execution time, storage requirements, quality factor requirements; i.e., Correctness, Reliability, Efficiency, Integrity, Usability, Maintainability, Testability, Flexibility, Portability, Reusability, and Interoperability

· Key Performance metrics

· Requirements Traceability

· Requirements Verification Matrix

g) Functional qualification requirements for the FMF App.

h) FACE Conformance Requirements for the FFM App

i) Any special delivery requirements for the CSCI.

j) Metrics Report SRR-2/SFR Exit Criteria The SRR SHALL be considered complete when the Contractor has:

a) All items submitted during the technical review have been appropriately addressed.

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

c) The requirements have been deemed adequate for the effort and are well understood by both parties. The functional baseline has been presented and approved.

d) The government and the vendor concur the program risk level is acceptable.

e) The affected baselines have been updated in the applicable configuration management systems

f) The chair formally closes the review.

Preliminary Design Review (PDR) The Contractor SHALL conduct a PDR engineering technical review. The purpose of the PDR is to ensure the system is sufficiently mature and ready to proceed into detailed design and can meet the stated performance requirements within program budget, schedule, risk, and other program and system constraints.

PDR Entry Criteria The timing of the PDR is driven by the maturity modification. The review SHALL be held when the entry criteria described below is achieved.

· Allocated Baseline has been delivered

· Program Cost & Schedule update has been delivered.

· Program Risk database has been delivered.

Documentation required to support the PDR entry includes:

· The Contractor Specification (also known as the SSS)

· System Requirements Documents (SRD)

· FACE Data Model

· System Safety Program Plan (SSPP)

· FMF Master Test Plan

· Software Requirements Specification (SRS)

· Software Transition Plan (STRP)

· Software Design Description (SDD)

· Database Design Description (DBDD)

· FQT Plan

· Safety Assessment Report (SAR)

· Specification Requirements Verification Matrix (RVM)

· FMF Software Quality Assurance Plan

· Software Test Description (STD)

· Software Development Plan (SDP)

· Open Systems Management Plan (OSMP)

· System Architecture Document (SAD) Data to be Presented at PDR As a minimum, the Contractor SHALL present the following at the PDR:

a) Program Overview (cost, schedule, and staffing) updates

b) Technical requirements & metrics updates,

c) RVM updates,

d) Risk updates

e) FMF App design

· FACE Data Model

· FMF Functional design with emphasis on changes to the core FMF

· FACE (wrapper) aspect of FMF design

· UoC functionality

· Database Design Description (DBDD)

· Data Integrity Design for the FMF App

· Safety Hazard Analysis based on safety assessment report

f) FQT plan

g) FACE Conformance plan

h) Metrics Report PDR Exit Criteria The Contractor SHALL consider PDR complete when

a) All items submitted during the technical review have been appropriately addressed.

b) All action items assigned to the Contractor required for review closure have been completed and approved by the required parties.

c) The requirements have been deemed adequate for the effort and are well understood by both parties. The allocated and product baselines have been presented and approved.

d) The government and the vendor concur the program risk level is acceptable.

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

f) The chair formally closes the review.

Critical Design Review (CDR) The Contractor SHALL conduct a Critical Design Review (CDR) technical review. The purpose of the CDR is to ensure the detailed design for the system is adequate to proceed in coding, system integration, demonstration and test and can meet the stated performance requirements within budget, schedule, risk, and other system constraints.

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

· Product Baseline has been delivered.

· Program Cost & Schedule update has been delivered.

· Program Risk database has been delivered.

Documentation required to support the CDR entry includes:

· Contractor Specification (also known as the SSS)

· System Requirements Documents (SRD)

· FACE Data Model

· System Safety Program Plan (SSPP)

· FMF Master Test Plan

· Software Requirements Specification (SRS)

· Software Transition Plan (STRP)

· Software Design Description (SDD)

· Database Design Description (DBDD)

· FQT Plan

· Safety Assessment Report (SAR)

· Specification Requirements Verification Matrix (RVM)

· FMF Software Quality Assurance Plan

· Software Test Description (STD)

· Software Development Plan (SDP)

· System Architecture Document (SAD) Data to be Presented at CDR As a minimum, the Contractor SHALL present the following at the PDR:

a) Program Overview (cost, schedule, and staffing) updates

b) Technical requirements & metrics updates,

c) RVM updates,

d) Risk updates

e) FMF App design

· FACE Data Model

· FMF Functional design with emphasis on changes to the core FMF

· FACE (wrapper) aspect of FMF design

· UoC functionality

· Database Design Description (DBDD)

· Data Integrity Design for the FMF App

· Safety Hazard Analysis based on safety assessment report

f) FQT plan

g) FACE Conformance plan

h) Metrics Report CDR Exit Criteria The Contractor SHALL consider CDR complete when:

a) All items submitted during the technical review have been appropriately addressed.

b) All action items assigned to the Contractor required for review closure have been completed and approved by the required parties.

c) The requirements have been deemed adequate for the effort and are well understood by both parties. The allocated and product baselines have been presented and approved.

d) The government and the vendor concur the program risk level is acceptable.

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

f) The chair formally closes the review.

Functional Qualification Test (FQT) Test Readiness Review (TRR) The vendor SHALL conduct a test readiness review prior to their lab functional testing for score. The purpose of the FQT TRR is to assess test objectives, test methods and procedures, test scope, and readiness for vendor FQT.

The FQT TRR SHALL be held at the Contractor facility.

TRR Entry Criteria

a) Test objectives delivered.

b) Test procedures delivered.

c) Test environment definition has been delivered

d) Test environment resources ready.

e) Risk assessment delivered.

f) Master Test Plan

g) Metrics Report TRR Exit Criteria

a) All action items identified during the FQT TRR have been appropriately addressed.

b) All action items assigned to the Contractor required for review closure have been completed and approved by the required parties.

c) 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.

d) The government and the vendor concur the program risk level is acceptable.

e) Test procedures validated for use in formal testing for the record and for dry run testing.

f) The government technical lead formally closes the review.

Technical Interchange Meetings (TIMs) The Contractor SHALL support twelve (12) TIMs to facilitate the exchange of technical information needed to resolve system/subsystem issues. Six (6) TIMs will be conducted at the Contractor facility and six (6) will be conducted at a United States Navy (USN) location. TIMs may be combined with other reviews or meetings as appropriate. Additionally, web 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 web based tools. (CDRL A034 and CDRL A035) Weekly Engineering Meetings The Contractor SHALL support weekly engineering meetings via phone and web briefings. These meetings will be two (2) hours in length. Formal agendas and minutes are not required for these meetings.

Test Program Master Test Plan The Contractor SHALL develop a Master Test Plan which ensures that the system meets all of the requirements of the FMF application project. (CDRL A030) Functional Qualification Testing The Contractor SHALL conduct Functional Qualification Test (FQT) using the Software Test Descriptions.

The Contractor SHALL facilitate government witness of the FQT.

The Contractor SHALL document the status of the testing in a FQT Final Test Report. (CDRL A031)

Program Management

The Contractor SHALL participate in an Integrated Product Team (IPT) established by the government.

The Contractor SHALL identify and maintain 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 maintain 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.

Monthly Status Report and Monthly Funds and Expenditures Status Report The Contractor SHALL report the status of the program. (CDRL A032) Integrated Master Schedule (IMS) The Contractor SHALL develop an IMS for the program. (CDRL A033) Meetings and Agendas The Contractor SHALL participate in meetings as described in this SOW, and provide agenda topics and any material that The Contractor intends to present at these reviews (CDRL A034 and CDRL A035).

Program Kickoff The Contractor SHALL schedule, coordinate and participate in a Program Kickoff TIM within 30 calendar days of contract award. This meeting will review the IMS and funds status and expenditures reporting requirements. (CDRL A034 and CDRL A035) Program Management Review (PMR) The Contractor SHALL schedule, coordinate and participate in quarterly PMRs beginning approximately 90 calendar days after the Program Kickoff TIM. These reviews may be accomplished via teleconference and web based tools; and, can be coordinated with other technical interchange meetings or SETR events. (CDRL A034 and CDRL A035) Data Accession List (DAL) The Contractor SHALL identify system design documentation not specifically requested by the Government but available for Government review in a DAL. (CDRL A036)

The Contractor SHALL maintain documents listed on the DAL in a data repository that is available to the Government via web access.

Documents produced by the program and not included within any CDRL SHALL be added to the DAL and made available via web access.

6 SECURITY

6.1 All work to be performed under this PWS, SOO, or SOW is UNCLASSIFIED. Contractor personnel shall not be required to have access to classified material. Any technical information or data that the contractor accesses shall be handled as controlled but unclassified material. Other requests for deliverables under this order shall be referred to the TPOC of this order. All contractor personnel working in support of this order must sign a Non-Disclosure Agreement (NDA) form prior to the commencement of any work performed under this order. The contractor shall not require access to classified information in performance of contract. A DD254 is not required.

The Contractor shall implement and maintain security procedures and controls to prevent unauthorized disclosure and/or distribution of controlled unclassified information (CUI) and to prevent inadvertent compilation of information from becoming classified information in accordance with the DoDM 5200.01 Volume 1 and DoDM 5400.7-R (Freedom of Information Act Regulation, Chapter 3), and the National Industrial Security Program Operating Manual (NISPOM) as well as all other applicable terms and conditions of any existing Basic Ordering Agreement (BOA).

The Contractor shall appropriately identify all controlled unclassified technical information and mark it as For Official Use Only in accordance with DoDM 5200.1 Vols 2 and 4 and DoDD 5400.07. All Contractor facilities shall provide an appropriate means of storage for controlled unclassified documents, equipment, and materials in accordance with DODM 5200.1 Volumes 2 and 4.

The contractor shall not store CUI on mobile computing devices such as laptops and personal digital assistants (PDAs), or removable storage media that do not utilize Federal Information Processing Standard 140-2 (FIPS 140-2) compliant encryption for protecting data at rest.

IAW DoDI 5230.24, the following distribution statement shall be placed on all data and is the only distribution statement authorized for this effort:

Distribution Statement D: Distribution authorized to the Department of Defense and U.S. DoD Contractors only (software documentation), 30 Sep 2008. Other requests shall be referred to Naval Air Systems Command, PMA-209, 47123 Buse Rd, Building 2272, Patuxent River, MD 20670-1547.

**NOTE to PWS, SOO, SOW Preparer: The appropriate Distribution Statement B through E can be substituted with applicable reason and date in the above format as required.** If technical data is also Export Controlled, it shall be marked with the Export Control Warning IAW DoDM 5200.01 Vol 2 Enclosure 3.

6.2 Cybersecurity

The contractor shall ensure appropriate protective measures are in place to safeguard CUI processed, stored, or transmitted on the contractor’s information systems. The Contractor shall report within 72 hours of discovery of any cyber incident that affects CUI processed, stored, or transmitted through the contractor's information systems. The contractor shall report cyber incidents to the DoD at http://dibnet.dod.mil. To minimize the potential for revealing classified information the contractor shall refer to DoD Manual O-5205.13 Defense Industrial Base (DIB) Cyber Security and Information Assurance (CS/IA) Program Security Classification Manual (SCM) specifically Table 5 of Enclosure (3) for classification information related to cyber incident reporting. The contractor shall preserve and protect data and information from all known affected information systems and all relevant monitoring or packet capture data for at least 90 days from the submission of the cyber incident report to allow DoD to request the media or decline interest. At DoD’s request, contractors must provide DoD with access to additional information or equipment that is necessary to conduct a forensic analysis related to the reported cyber incident.

6.2.1 PUBLIC KEY INFRASTRUCTURE (PKI):

Public Key Infrastructure (PKI) is the DoD framework for issuing, maintaining, and revoking public key certificates. Public key certificates provide digital signature and encryption capabilities which contribute to the identification and authentication, integrity, and confidentiality of Controlled Unclassified Information (CUI). CUI is defined as U.S. Government data that is NOT CLASSIFIED and that has NOT BEEN PUBLICALLY RELEASED. CUI includes but is not limited to data that is labeled or considered: For Official Use Only (FOUO), Privacy data, Contract Information, Unclassified Technical Data, Accountability information, DoD Sensitive But Unclassified (SBU).

The contractor shall obtain and utilize digital certificates issued by the DoD PKI or by the DoD External Certification Authority (ECA) program for authentication, digital signature, or encryption. PKI certificates shall be obtained and utilized by the contractor, its subcontractors, and suppliers when transmitting CUI via electronic means. The contractor shall utilize digital signature and encryption via DoD PKI or ECA digital certificates on all electronic mail (e-mail) messages containing CUI or e-mail messages that discuss any matter that may serve as an OPSEC indicator. The contractor shall use a separate DoD PKI or ECA digital certificate for each email address if multiple email addresses are used by any contractor personnel under this contract. Unapproved accounts, such as GMAIL, AOL, HOTMAIL or YAHOO, shall not be used for official business under this contract.

6.3 Operations Security:

All Contractor facilities shall provide an appropriate means of storage for controlled unclassified documents, equipment, and materials in accordance with Operations Security (OPSEC) requirements. The Contractor shall supplement their current security practices by requiring all Contractor personnel to complete annual OPSEC training. If there is an existing DoD/USN compliant Operational Security (OPSEC) Plan, it shall be utilized. If there is no compliant OPSEC plan, one shall be submitted IAW CDRL TBD.

6.4 Cryptologic items:

Cryptologic keying materials and controlled cryptographic items are classified or controlled by U.S. Navy, NISPOM, and NSA guidelines. Per the NISPOM, specific requirements for the management and safeguarding of COMSEC material in industry are described in the COMSEC material control and operating procedures provided to the custodian of each industrial COMSEC account. The Contractor shall manage all GFE in accordance with the requirements set forth in the DoD International AIMS Program Security Classification Guide and the EKMS-1B Policy and Procedures for Navy Electronic Key Management System Tiers 2 & 3.

6.5 Public Release

The contractor shall ensure NAVAIR program related information and graphics intended for release to the public and/or posting on internet and World Wide Web (www) site is submitted through the NAVAIR Security Policy Review (SPR) process before release. The contractor shall include note pages in all briefings and slide presentations submitted to the NAVAIR organization that owns or controls the information for review and final release authorization.