Attachment 1 - DRAFT - OASIS Statement of Work (SOW).pdf

Draft Statement of Work For

Operational and Supportability Implementation System (OASIS)

May 25, 2023

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT i

TABLE OF CONTENTS

C.1 INTRODUCTION

C.2 APPLICABLE DOCUMENTS

C.2.1 FAA Orders, Specifications, and Standards

C.2.2 Other FAA Publications

C.2.3 Other Documents

C.3 Requirements-Technical Information

C.3.1 General

C.3.1.1 System Components C.3.1.2 Performance Capabilities

C.3.2 Program Management

C.3.2.1 Program Management Personnel C.3.2.2 Program Management Plan (PMP) C.3.2.3 Program Status Report (PSR) C.3.2.4 Post Award Conference (PAC) C.3.2.5 Program Management Review (PMR) C.3.2.6 Technical Interchange Meeting (TIM) C.3.2.7 Meeting Agendas and Minutes

C.3.2.8 RESERVED

C.3.2.9 Integrated Master Schedule (IMS) C.3.2.10 Risk Management C.3.2.11 Configuration Management (CM) C.3.2.12 Program Trouble Report (PTR)

C.3.3 System Engineering

C.3.3.1 System Level Requirements C.3.3.2 Software Engineering C.3.3.3 Software Management

C.3.4 Quality Assurance and Control

C.3.5 Safety

C.3.6 Document Library

C.3.7 Interface Requirements

C.3.8 Test and Evaluation (T&E)

C.3.8.1 Preparation for Formal Testing C.3.8.2 Test Phase Requirements C.3.8.3 Test Readiness Review C.3.8.4 Pre-Test Briefings

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT ii

C.3.8.5 Post-Test Briefings C.3.8.6 Solution Implementation Test Phase C.3.8.7 Regression Testing C.3.8.8 In-Service Test Phase C.3.8.9 Key Site Tests

C.3.9 Transition, Site Implementation, and Activation

C.3.9.1 Transition Implementation Plan (TIP) C.3.9.2 Installation Sites C.3.9.3 Site Surveys and System Installation C.3.9.4 Delivery, Installation, and Checkout C.3.9.5 Site Completion Report

C.3.10 Security

C.3.10.1 Security Program C.3.10.2 Security Authorization C.3.10.3 Security Authorization Documentation C.3.10.4 Security Assessments C.3.10.5 Security of Testbed and Lab Environments C.3.10.6 Incident Response C.3.10.7 Compliance Testing C.3.10.8 Penetration Testing C.3.10.9 Cybersecurity Exercises C.3.10.10 Facility Security C.3.10.11 Personnel Security C.3.10.12 Protecting Sensitive Unclassified Information (SUI) C.3.10.13 Supply Chain Risk Management (SCRM) C.3.10.14 Insider Threat Prevention Program

C.3.11 Training

C.3.11.1 Training Guidance Conference C.3.11.2 Task and Skills Analysis Report

C.3.11.3 RESERVED

C.3.11.4 Training Development Plan C.3.11.5 OASIS System Training C.3.11.6 Validation of Training Courses C.3.11.7 OASIS Training Technical Interchange Meetings

C.3.12 OASIS Integrated Logistics Support (ILS)

C.3.12.1 ILS Management C.3.12.2 Integrated Support Plan (ISP) C.3.12.3 Technical Manuals C.3.12.4 Post-Production Support C.3.12.5 Second Level Engineering Support C.3.12.6 Help-Desk C.3.12.7 Notification of Visits C.3.12.8 Supply Support

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT iii

C.3.13 OASIS De-Installation

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 1

C.1 INTRODUCTION

This Statement of Work (SOW) for the Operational and Supportability Implementation System contract, hereinafter referred to as “OASIS” identifies the services required to provide an integrated computer-based system for the flight service facilities in Alaska that will enable flight service specialists to provide weather briefings and flight planning assistance to general aviation pilots. OASIS is a leased system. The system will be acquired as a managed service in which the Contractor owns the hardware and software and is responsible for 2nd level engineering, configuration management, depot maintenance, and 24/7 Help Desk support to FAA operators and maintainers. FAA Air Traffic personnel will operate OASIS and FAA Technical Operations personnel will perform first-level maintenance. The FAA also tests, approves, and provides authorization for implementation of all OASIS changes.

C.2 APPLICABLE DOCUMENTS

The following specifications, standards, instructions, orders, guidelines, and handbooks form a part of this SOW and are applicable to the extent specified herein. In the event of a conflict between requirements contained in a referenced document and this SOW, the requirements of this SOW apply.

Each referenced document listed below was the most current revision available as of the Screening Information Request (SIR). Questions regarding the requirements contained therein or the applicability of the revision level of a referenced document should be immediately addressed with the Contracting Officer (CO).

C.2.1 FAA Orders, Specifications, and Standards

FAA Order 1000.36 Writing Standards

FAA Order 3000.57B Air Traffic Organization Technical Operations Training and Personnel Certification Programs

FAA-STD-025F Preparation Of Interface Documentation

FAA Order 6000.15J General Maintenance Handbook for National Airspace System (NAS) Facilities

FAA-STD-028C Contract Training Programs FAA Order 1200.22E External Requests for National Airspace System (NAS) Data FAA Order 1270.1A Freedom of Information Act Program FAA Order 1350.14B Records Management

FAA Order 1370.121B FAA Information Security and Privacy: Policy

FAA Order 1600.1F Personnel Security Program FAA Order 1600.2F Classified National Security Information (CNSI) FAA Order 1600.69C FAA Facility Security Management Program

FAA Order 1600.75 Protecting Sensitive Unclassified Information (SUI)

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 2

C.2.2 Other FAA Publications

ATO-S 2008-12 Version 1.5 Safety Risk Management Guidance for System Acquisition

(SRMGSA)

(No Number Assigned) Air Traffic Organization (ATO) Safety Management System

(SMS) Manual

(No Number Assigned) (No Number Assigned) ATO Security Requirements for Authorization

C.2.3 Other Documents

NFPA-70 National Electrical Code

Public Law 113-283 - FISMA Federal Information Security Modernization Act (FISMA) of

Presidential Policy Directive -21 Critical Infrastructure Security and Resilience Executive Order 13636 Improving Critical Infrastructure Cybersecurity Executive Order 14028 Improving the Nation’s Cybersecurity

OMB Memorandum M-14-03 Enhancing the Security of Federal Information and Information Systems

OMB Memorandum M-14-04 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management

NIST FIPS 199 Standards for Security Categorization of Federal Information and Information Systems

NIST SP 800-18, Rev. 1 Guide for Developing Security Plans for Federal Information Systems

NIST SP 800-37, Rev. 2 Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy

FAA Order 1600.78 Personal Identity Verification (PIV) Card and Other Identification (ID) Cards

FAA Order 1600.82A Insider Threat Detection and Mitigation Program FAA Order 1770.68 Selection and Use of Time and Frequency Sources for all Systems, Services, and Applications Supporting NAS Operations FAA Order 1800.66A Configuration Management Policy

FAA JO 1370.114

Implementation of Federal Aviation Administration (FAA) Telecommunications Infrastructure (FTI) Services and Information Security Requirements in the National Airspace System (NAS)

FAA JO 1370.117 National Airspace System (NAS) Internet Protocol (IP) Addressing Policy

FAA JO 1370.118 Air Traffic Organization Wireless Policy

FAA JO 1370.123 National Airspace System (NAS), Identity and Access Management (IAM) Policy

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 3

NIST SP 800-53, Rev. 5 Security and Privacy Controls for Federal Information Systems and Organizations

NIST SP 800-61, Rev. 2 Computer Security Incident Handling Guide NIST SP 800-82, Rev. 2 Guide to Industrial Control Systems (ICS) Security

NIST SP 800-137 Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 4

C.3 Requirements-Technical Information C.3.1 General

The Contractor must deliver the systems, supplies, and services required by this contract. The Contractor must provide systems engineering, human factors engineering, program management, integrated logistics support, quality assurance, configuration management, safety risk management, information system security (ISS) support, training, operational and maintenance support, testing, and material to test, deliver, and install OASIS in accordance with this SOW.

The Contractor must fully integrate their solution to meet the requirements contained in this

SOW.

C.3.1.1 System Components The Contractor must provide all hardware, software, and documentation required to operate and support OASIS. The Contractor must design and build OASIS to meet requirements in the OASIS Specification using Commercial-off-the-Shelf (COTS) hardware and Commercially Available Software (CAS) to the maximum extent possible. The use of COTS, and CAS does not exempt the Contractor from complying with contract requirements unless specifically approved in advance by the CO. The components included in OASIS may vary by site depending on the Contractor’s architectural solution.

C.3.1.2 Performance Capabilities OASIS functional requirements are contained in the OASIS Specification. In general, OASIS will:

(a) Provide real time and accurate alphanumeric (A/N) weather and graphic weather products, aeronautical information, and flight planning assistance to users;

(b) Provide the processing capability to acquire, store, retrieve and display information to support weather briefings, pre-flight planning, and in-flight operations;

(c) Provide remote access for specialists; and

(d) Provide help functions for system operators.

C.3.2 Program Management

C.3.2.1 Program Management Personnel

The Contractor must assign a Program Manager (PM) to organize, plan, schedule, implement, control, analyze, and report on all elements of the contract. The PM must have resources and authority sufficient to ensure efficient and timely program execution. The PM must serve as the focal point for all program tasks and be prepared to discuss the status of contract activities at any time. The Contractor must identify all key personnel including at a minimum: Program Manager, Chief Systems Engineer, Chief Software Engineer, Test Lead, and Integrated Logistics Support (ILS) Manager. The Contractor must notify the FAA CO and FAA Contracting Officer’s Representative (COR) of all changes in key personnel. The Contractor must designate other lead personnel as required to manage and control activities conducted in response to the requirements of this SOW and the Contract.

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 5

C.3.2.2 Program Management Plan (PMP) The Contractor must establish and maintain a PMP to manage the contract and subcontracts. The PMP must efficiently and effectively execute contract requirements concerning, but not limited to program control, quality assurance and control, configuration management, subcontract management, the management of FAA furnished resources, safety risk management, program risk management, and information system security (ISS). The Contractor’s PMP must describe the processes, activities, and personnel required to meet all Contract requirements. The Contractor must identify key personnel by name in the PMP.

CDRL PM001 Program Management Plan (PMP)

C.3.2.3 Program Status Report (PSR) The Contractor must provide a monthly PSR describing current progress, deliveries made and significant activities accomplished during the previous month, deliveries scheduled and significant activities planned for the current month, problems encountered, hardware and software failures, risks, and risk mitigation plans.

CDRL PM002 Program Status Report (PSR)

C.3.2.4 Post Award Conference (PAC) The Contractor must host a joint FAA and Contractor PAC at the Contractor’s facility. The FAA CO or COR will coordinate with the Contractor to schedule the PAC, which should occur within thirty (30) calendar days after contract award and should last no more than two (2) calendar days.

During the PAC, the Contractor must brief the FAA on its plans and schedule for satisfying each SOW requirement. The Contractor must submit an agenda that it plans to present at the PAC to the CO or COR at least five (5) calendar days prior to the PAC.

C.3.2.5 Program Management Review (PMR) The Contractor must conduct a PMR for the FAA quarterly. During the PMRs the Contractor must review contract performance and schedule status along with other performance measurement information and identify current and anticipated technical and implementation problems, associated risks and risk mitigation plans and activities. Information presented must include installed system operational availability and support status and trends, issues, and corrective actions. Each PMR must be scheduled to take no longer than two (2) business days.

As the contract proceeds, the FAA may choose at its discretion to have the PMRs conducted via teleconference or at the Contractor’s facility.

C.3.2.6 Technical Interchange Meeting (TIM) The Contractor must conduct and administratively support up to four (4) Technical Interchange Meetings (TIMs) annually, except during any technical refresh period of performance. TIMs will be conducted as needed during the option year periods. The FAA may choose at its discretion to have the TIMs held at the Contractor's facility, at the FAA’s locations in Washington, D.C. or the William J. Hughes Technical Center in Atlantic City, NJ, or via teleconference. TIMs will be scheduled on an as required basis to ensure FAA visibility into the technical progress of the contract and to discuss subjects including, but not limited to analyses, test plans and results, technical decisions, implementation concerns, and the status of activities

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 6 leading to completion of the Security Authorization documents required by the Security Section of this SOW.

C.3.2.7 Meeting Agendas and Minutes The Contractor must prepare and deliver Meeting Agendas, Presentation Material, and Minutes for all meetings and conferences in accordance with the instructions contained in this SOW. The Contractor must contact the COR for guidance in the event that the Contractor is uncertain if an agenda or minutes are required for a specific meeting.

CDRL PM003 Meeting Agenda CDRL PM004 Meeting Minutes CDRL PM005 Presentation Material

C.3.2.8 RESERVED

C.3.2.9 Integrated Master Schedule (IMS)

The Contractor must develop, maintain, and deliver an IMS in sufficient detail to plan, manage, and control all program activities. The Contractor must manage the execution of OASIS using the IMS as a day-to-day execution tool and periodically assess program progress in meeting program requirements. The Contractor must report on program progress consistent with the IMS at each program management review, at selected technical reviews and at other times at the FAA's request.

The Contractor must revise the IMS, where necessary, to reflect current contract milestones and deliverables. The IMS will include all activities of the prime contractor, subcontractors, and any activities requiring FAA participation or approvals through the completion of transition. All contractor schedule information delivered to the FAA or presented at program reviews must originate from the IMS. The Contractor must perform appropriate analyses of the IMS tasks and report potential or existing problem areas and recommend corrective actions to eliminate or reduce schedule impact to the program.

CDRL PM006 Integrated Master Schedule (IMS)

C.3.2.10 Risk Management The Contractor must identify and manage schedule and technical risks throughout the performance of this contract. Risks must be identified, classified, and analyzed according to their impact on integration, installation, performance, and schedule. The Contractor must develop and maintain a list identifying and classifying those risks as low, medium, or high priority. The Contractor must develop risk mitigation plans for risks considered medium or high priority and establish a priority for risk mitigation.

The Contractor’s risk management techniques must be identified and explained in the Contractor’s PMP. The Contractor must identify all significant risks and provide the status and risk mitigation plans in the PSR and during Program Management Reviews (PMRs).

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 7

C.3.2.11 Configuration Management (CM) The Contractor must establish, update and implement a CM program throughout the life-cycle of the system. The CM program must include, but is not limited to, the CM disciplines of planning and management, configuration identification, configuration control, status accounting, configuration verification, and audits.

The Contractor must prepare and submit a Configuration Management Plan (CMP) which must describe how CM will be established, implemented, and maintained. The Contractor’s CMP and Change Management procedures must describe the processes for submission, justification, evaluation, coordination, disposition, and implementation of changes.

The Contractor must provide a product top-down structure to identify configuration items (CIs) (top-level and lower levels) that constitute the system and assign unique identifiers for each CI.

The Contractor must apply configuration control to NDI, COTS, and Contractor-developed hardware, software, firmware, test equipment, training materials, and manuals as well as documentation. The Contractor must maintain configuration control of critical items down to the Lowest Replaceable Unit (LRU) level and software to the version level. Configuration control must manage available performance specifications and packages.

The Contractor must prepare and submit a Configuration Audit Plan, which includes the Functional Configuration Audit (FCA) and Physical Configuration Audit (PCA), and must provide all documentation to support the audit activities. The Contractor must support configuration audits and ensure that its subcontractors, vendors, and suppliers also participate in the audits, as proposed in the approved Configuration Audit Plan. The Contractor must prepare and submit a Configuration Audit Summary Report documenting the findings of the FCA and

PCA.

The Contractor must conduct an FCA at the Contractor’s facility. The FCA must verify that performance of individual CIs complies with the requirements of the allocated baseline and that the product design and the “as-built” product configuration are documented accurately.

The Contractor must conduct a PCA after the FCA has been successfully completed. Successful completion of the PCA requires FAA approval of the Contractor's final submission of the associated CDRL items. This establishes the product baseline when completed.

An OASIS configuration managed baseline must only be modified by either a Program Trouble Report (PTR) fix or incorporation of an Engineering Change Proposal (ECP). The Contractor must develop and submit the ECP as required. Contractor proposed changes affecting NAS interfaces will be captured by the FAA as a NAS Change Proposal (NCP) which will be submitted to the NAS Configuration Control Board (CCB) for approval. For the OASIS program, PTR fixes and/or an approved ECP/NCP can be combined into a software release update in accordance with the Software Modification sections of this SOW. The Contractor must prepare and submit any updated Security or Safety documentation impacted by the proposed change or software release.

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 8

Instructions for preparing Security and Safety documentation are provided in the Security and Safety sections of this SOW. The Contractor must obtain FAA approval prior to incorporation of changes into baselined CIs and associated documentation. Once the FAA has approved a change, the Contractor must incorporate the change into the body of the document that was impacted by the change as opposed to attaching redlined pages.

CDRL CM001 Configuration Management Plan (CMP) CDRL CM002 Configuration Audit Plan CDRL CM003 Configuration Audit Summary Report CDRL CM004 Engineering Change Proposal

C.3.2.12 Program Trouble Report (PTR)

The Contractor must identify, monitor, and track all hardware, software, and documentation related problems and document those problems in PTRs. Problems to be identified, monitored, and resolved are those that have an impact on OASIS functionality or National Airspace System (NAS) operations as identified by the Contractor or the FAA. Updates or changes to the scope of PTRs identified for a software baseline release must be communicated to the FAA prior to delivery to the William J. Hughes Technical Center (WJHTC) so that appropriate planning and testing changes can be implemented. The Contractor must establish and maintain a PTR database which contains a copy of all PTRs. The Contractor must provide the FAA with electronic access to the PTR database with the capability to search, sort, download files, and generate reports.

PTRs entered into the database must be prioritized by the Contractor (with review and concurrence by the FAA) according to the following definitions:

(a) Priority 1 is assigned to a problem that prevents the accomplishment of an operational, mission-critical or mission-essential capability, or jeopardizes safety, security or other requirements designated as Critical Performance Requirements (CPRs);

(b) Priority 2 is assigned to a problem that adversely affects the accomplishment of an operational, mission-critical or mission-essential capability and no work-around solution is known;

(c) Priority 3 is assigned to a problem that adversely affects the accomplishment of an operational, mission-critical or mission-essential capability, but a work-around solution is known;

(d) Priority 4 is assigned to a problem that results in a user/operator inconvenience or annoyance, but does not affect a required operational, mission-critical or mission-essential capability; and

(e) Priority 5 is assigned to any other problem/defect not described above (e.g., system documentation errors).

C.3.3 System Engineering

The Contractor must implement a System Engineering Management program for the definition, development, verification, integration, and testing of OASIS requirements. The Contractor must specify a single authority that will serve as the point of contact for system engineering issues.

The System Engineering Management program must be described in the PMP.

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 9

The Contractor must address all system engineering/software engineering analysis/design including any recommended architecture and technology infusion and/or system refresh and upgrade changes and their associated implications, including security implications, recommended for the production baseline during TIMs and PMRs.

The Contractor must maintain effective control over the system engineering and design development process, including subcontract items and services, to ensure performance and schedule requirements are met, to provide early detection and resolution of problems, and to reduce risk.

C.3.3.1 System Level Requirements C.3.3.1.1 System Architecture The Contractor’s OASIS system architecture must satisfy all requirements identified in the OASIS Specification. The Contractor must develop and submit an OASIS System Architecture Description Document which ensures all the OASIS hardware and software architecture is depicted at the national level, system (Alaska State) level, the site (Flight Service Station (FSS)) level, and at the workstation level. The Contractor must submit revisions and updates to the OASIS System Architecture Description Document when any functions are added to the OASIS Product Baseline or when otherwise required.

CDRL SE001 System Architecture Description Document

C.3.3.1.2 Requirements Allocation and Design

The Contractor must conduct a systems engineering analysis to translate and allocate the functional requirements for OASIS from the OASIS Specification to a system/subsystem specification (SSS). The Contractor must develop and deliver the System/Subsystem Specification which will serve as the Contractor’s system level functional baseline. The Contractor must receive approval from the FAA CO before amending the baseline.

CDRL SE002 System/Subsystem Specification (SSS)

C.3.3.1.3 Site Installation Engineering Drawings The Contractor must develop, update and deliver Engineering Drawings for each OASIS System site installation. The Engineering Drawings must be used in the OASIS installation planning effort and must reflect the final as-installed configuration at each site.

CDRL SE003 Site Installation Engineering Drawings

C.3.3.2 Software Engineering The Contractor must acquire or develop the software required to meet contract requirements and must identify a single point of contact for software engineering issues.

All software acquired or developed under this contract must be documented, tested and managed in accordance with OASIS Specification requirements. The Contractor must describe its plans for acquiring, developing, and updating the software required to meet contract requirements in the PMP.

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 10

The Contractor must allow the FAA to witness all tests associated with software development or integration.

C.3.3.3 Software Management

The Contractor must prepare a Software Development Plan (SDP) that describes their approach to developing OASIS. The SDP must include the plans, processes, and procedures for requirements management, software engineering management, software design, software development, software test, and human factors. The Contractor must use a software design standard consistent with their software development approach (e.g., IEEE/EIA 12207-2017 Software Lifecycle Processes), in establishing a software development process and to ensure the software lifecycle process used is compliant with ISO/IEC 90003-2014, Software Engineering.

The Contractor must define its software development environment utilized to develop OASIS.

CDRL SW001 Software Development Plan

C.3.3.3.1 Software Modifications

The Contractor must acquire or modify any software required to resolve PTRs identified during OASIS tests. Additionally, all software modifications and software maintenance releases must be tested in accordance with the Test Section of this SOW as applicable. The Contractor must accomplish the following prior to installation of any software for operational use:

(a) Correct all software related Priority 1 and 2 PTRs;

(b) Coordinate with the FAA a plan and schedule for correcting Priority 3, 4, and 5 PTRs;

(c) Conduct a system test to validate that each PTR selected for inclusion in the software modification has been corrected; and

(d) Obtain written FAA Test Director approval documenting concurrence that each PTR has been corrected.

C.3.3.3.1.1 Software Maintenance Releases

Software changes to address non-critical PTRs, user change requests, and NAS-driven changes will be implemented during software maintenance releases. Three (3) software maintenance releases will be implemented annually to include software vulnerability remediations. The content of each software maintenance release will be determined jointly by the FAA and Contractor based on the complexity of the required change and user prioritization of the change candidates. The Contractor must integrate this hardware/software into the existing OASIS software baseline such that all requirements stated in the Contractor’s approved OASIS Specification and applicable Interface Requirements Documents (IRDs) are satisfied as defined in Contract Section J, Attachments J-4, J-5, J-6 and J-7. The Contractor must develop and deliver a Change Description Document (CDD) to identify software changes requested by the FAA. The CDD will be discussed and approved during joint monthly FAA and Contractor Software Update teleconferences and is used to:

(a) Facilitate user understanding of the requirement and software changes proposed to meet the requirement; and

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 11

(b) Describe the problem and identify the proposed software modifications necessary to resolve the problem.

CDRL SE004 Change Description Document (CDD)

C.3.3.3.1.2 56-Day Database Releases

The Contractor must develop, update and manage the OASIS 56-day national charting cycle database used by Alaska Air Traffic Control Specialists for providing weather and non-weather related information to pilots. Contract Section J, Attachment J-X identifies the Government Furnished Information provided for development of the database. The Contractor must:

(a) Develop the OASIS database and 56-day update, including incorporation of FAA unique database inputs as required;

(b) Test the update;

(c) Provide a copy of the proposed update to the William J. Hughes Technical Center (AJW-

171) for testing;

(d) Deliver the database to the OASIS sites after AJW-171 successfully tests and approves the update.

A Technical Interchange Meeting will be conducted at the William J. Hughes Technical Center to assist in understanding and describing the 56-day database effort. The Contractor must submit a Database Management Specification defining the 56-day process and roles and responsibilities

(CDRL DB001).

The FAA (AJW-171) will be responsible for providing the FAA unique 56-day update inputs to the Contractor in accordance with (IAW) the schedule identified in the IMS (CDRL PM006).

AJW-171 will also test the advance copy of the 56-day update provided by the Contractor and provide results of the T&E to the Contractor IAW the schedule in the IMS.

CDRL DB0001 Database Management Specification and Reports

C.3.3.3.1.3 28-Day Adaptation Releases

The Contractor must deliver a 28-day adaptation release every 28 days. The 28-day adaptation release consists of:

(a) Anti-virus updates

(b) Weather camera clear-day photo updates

(c) Sectional chart updates

(d) IFR Enroute chart updates

(e) Airport diagram updates

The Contractor must deliver the 28-day adaptation release to the FAA (AJW-171) for testing prior to delivery and installation in the field.

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 12

C.3.3.3.1.4 56-Day Out of Cycle and Software Emergency Update Releases

The Contractor must make Out of Cycle (OOC) database changes outside the 56-day Database Charting Cycle as requested by the CO. Typically, these OOC changes will be identified as necessary for the OASIS to support National Weather Service initiated changes to World Meteorological Organization (WMO) message headers or new weather reporting stations that cannot be postponed until the next 56-day database submission.

In addition to the OOC database changes, the Contractor must support minor emergency software changes necessary to support the required OOC changes to include critical patches for identified vulnerabilities. The Contractor must assign this the highest priority and must have a goal to correct the database or software problem within 72 hours of notification. After the Contractor receives notice of an emergency database or emergency minor software change from the CO, discussions will be held between the Contractor and CO to determine if the emergency database or emergency minor software change will cause an impact in the time required for performance of any part of the work under this contract. Up to four (4) OOC database changes and associated emergency minor software changes may be required each year.

C.3.3.3.1.5 System Refresh and Upgrade

The Contractor must notify the FAA before incorporating any adaptation, update, or upgrade of commercially available hardware, software, or firmware. The Contractor must conduct a risk benefits analysis to include life-cycle and transition planning prior to the notification to the FAA.

A summary of the risk analysis must be provided as part of the monthly PSR (CDRL PM002).

The Contractor must notify the CO thirty (30) business days in advance of implementing any changes to the system that could negatively impact the NAS or degrade operations. After testing at the William J. Hughes Technical Center (WJHTC), the FAA will advise the Contractor of its approval of the change prior to the Contractor implementing the change at all sites.

C.3.3.3.2 Software Metrics The Contractor must track the software metrics as indicated in the Software Development Plan.

C.3.4 Quality Assurance and Control

The Contractor must provide and maintain a documented quality system as a means of assuring compliance with the requirements of the contract. The quality system must provide for the following and be described in the PMP:

(a) The granting of independent responsibility and authority to assigned personnel sufficient to ensure that quality problems can be identified, evaluated, and reported; and solutions recommended; without fear of reprisal, intervention, or other adverse actions;

(b) The performance of tests and inspections in compliance with contract requirements and the assurance that all test data are complete, correct, traceable, repeatable, and acceptable.

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 13

C.3.5 Safety

An approved Safety Risk Management Document (SRMD) is required prior to operational use of OASIS in the NAS. Any changes to OASIS including software maintenance releases also require development and approval of an SRMD. To support the generation of the SRMD, the Contractor must conduct safety hazard analysis as identified in the Safety Risk Management Guidance for System Acquisitions. The Contractor must develop and provide a System Safety Assessment Report (SSAR) and a System Hazard Analysis (SHA). The Contractor must also support activities necessary in the Government's development of the SRMD such as testing support to show that any hazards identified in the SHA are mitigated.

CDRL SA001 System Safety Assessment Report (SSAR)

CDRL SA002 System Hazard Analysis (SHA)

C.3.6 Document Library

The Contractor must maintain a library containing all documents developed by the Contractor and its subcontractors and all Government Furnished Information (GFI). The list of documents included in the library must be available upon FAA request. At a minimum, the Contractor's Document Library must contain:

(a) Copies of all correspondence between the Contractor and the FAA;

(b) The latest internally controlled version of all specifications, drawings, databases and software that define or implement the system;

(c) All tools used to generate documents in the database;

(d) Copies of all briefings to the FAA;

(e) All configuration management documentation;

(f) A PTR Database;

(g) Site Hardware and Software Inventory Lists; and

(h) All CDRL documentation.

The Contractor must place a document in the Contractor's library within fifteen (15) calendar days of its availability to Contractor personnel. The Document Library must be made available to authorized FAA personnel upon request. For electronic media, the Contractor must provide on-line access to authorized FAA personnel (read only mode is acceptable).

Copies of all documents in the library must be transferred to the FAA upon completion of the contract or when requested by the FAA.

C.3.7 Interface Requirements

The Contractor must develop, update, and deliver Interface Control Documents (ICDs) that documents the design of each interface developed in response to requirements contained in the IRDs listed in Contract Section J, Attachment(s) J-4, J-5, J-6, and J-7. The Contractor must follow the guidance provided by FAA-STD-025 in creating or modifying each ICD.

CDRL IC001 Interface Control Document (ICD)

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 14

C.3.8 Test and Evaluation (T&E)

The Contractor must plan for and conduct testing of OASIS and support the FAA T&E program.

The purpose of Contractor testing is to verify that OASIS meets specification requirements.

The Contractor must develop and deliver a Contractor Master Test Plan (CMTP). The Contractor must document the integrated test and evaluation program in the CMTP. The CMTP must describe the Contractor's overall test philosophy, define the test program, and serve as the controlling document for the test program once approved. The Contractor must ensure that all testable requirements from the specifications and other requirement documents are allocated to at least one CMTP test or inspection. All requests to declare a requirement untestable must be approved in writing by the Government. Individual test plans, procedures, and reports for CMTP required tests/inspections must clearly indicate where the particular CMTP allocated requirements are being met within the individual test plan/procedure. Upon approval, the Contractor must maintain the CMTP. All changes to the CMTP must be approved in writing by the Government.

Within the CMTP, the Contractor must prepare a Verification Requirements Traceability Matrix (VRTM) for all formal test activities that delineates requirements traceability to the OASIS Specification and the specific requirements of this SOW. The VRTM must allocate test requirements to specific test procedures. The VRTM must include the OASIS Specification and SOW paragraph reference(s), qualification method(s), and verification level for each requirement.

CDRL TE001 Contractor Master Test Plan

C.3.8.1 Preparation for Formal Testing

Prior to the start of formal testing, the Contractor must complete certification testing for connectivity of OASIS to the NAS. The Contractor must submit required service requests to the FAA and conduct associated interoperability testing for connectivity to specific NAS systems.

Service requests may be required for the following, at a minimum:

(a) FAA Telecommunication Infrastructure (FTI);

(b) NAS Data Interchange Network (NADIN) Message Replacement (NMR); and

(c) Weather Message Switch Center Replacement (WMSCR).

CDRL TE002 Service Requests

C.3.8.2 Test Phase Requirements During each test phase, the Contractor must:

(a) Conduct and/or support all T&E program activities described within this SOW;

(b) Advise the FAA at least seven (7) calendar days prior to the commencement of all formal

Contractor conducted T&E;

(c) Conduct a Test Readiness Review (TRR) prior to the start of Contractor conducted tests;

(d) Permit the FAA to witness the Contractor conducted formal T&E procedures;

(e) For all Contractor conducted tests, identify the system configuration to be tested and not change or modify this configuration without FAA concurrence;

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 15

(f) For all Contractor conducted tests, record all start and stop times, inputs, outputs, anomalies, test deviations, test equipment substitutions and all other relevant events for each test procedure;

(g) Perform all data reduction and furnish analysis methods and results to support claims of T&E success;

(h) Provide and maintain a single point of contact for the T&E program;

(i) Fix and verify problems identified in the Contractor’s PTR database and the FAA DR database prior to entering into regression testing or the next phase of testing, whichever comes first, unless otherwise directed by the FAA;

(j) For all Contractor-conducted tests, provide properly calibrated fully operational test equipment and/or validated software test and analysis tools. The Contractor must obtain written approval from the FAA before using unique or modified commercial test equipment not specified in the approved test plans and procedures; and

(k) For all FAA conducted tests and other T&E activities, provide on-site support as requested by the FAA.

C.3.8.3 Test Readiness Review The Contractor must conduct a TRR prior to all Contractor testing. As a minimum, the TRR must include the following topics:

(a) Overview of the testing to be performed;

(b) Status of Contractor development and integration milestones and checkpoints;

(c) Status of all applicable test documentation;

(d) FAA and Contractor personnel and other resources required for the test;

(e) Configuration control and validation of test tools and test items (both hardware and software) and any other items necessary for successful testing, including Data Reduction and Analysis (DR&A) tools and equipment;

(f) Prior test results, including those from any test dry runs;

(g) Summary of all PTRs, including status of relevant hardware, firmware, and software problems;

(h) Review of test baseline, configuration, and environment;

(i) System CM status;

(j) Government Furnished Equipment (GFE), GFI, and Government Furnished Property

(GFP) status (if applicable);

(k) Traceability between requirements and their associated tests using the Verification

Requirements Traceability Matrix (VRTM) found in the OASIS Specification;

(l) Test schedules; and

(m) Test entrance and exit criteria.

C.3.8.4 Pre-Test Briefings Prior to each formal test the Contractor must conduct a pre-test briefing for test participants and observers. The purpose of this briefing is to ensure that accomplishment of the test objectives will be verified during the test and post-test activities. It must identify all of the information, personnel, and equipment required to conduct the test. In addition, each pre-test briefing must:

(a) Explain how test objectives will be addressed;

(b) Explain how the test will satisfy contract requirements;

(c) Identify success criteria;

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 16

(d) Identify the test configuration versions of the hardware (H/W) and software (S/W) including, as a minimum, configuration files and required test tools;

(e) Include a walkthrough of the test process;

(f) Identify test limitations, deviations, and required or anticipated workarounds;

(g) Identify and describe all anomalies impacting the test;

(h) Identify all approved waivers or deviations applicable to the test;

(i) Identify results of any dependent testing that demonstrate readiness for test conduct;

(j) Identify Test personnel assignments and Government and contractor resources; and

(k) Describe Data Reduction and Analysis (DR&A) methods.

C.3.8.5 Post-Test Briefings The Contractor must conduct a post-test briefing for test participants and observers after each formal test or group of formal tests. The purpose of the post-test briefing is to:

(a) Verify that DR&A activities are completed and verified;

(b) Verify that the test satisfied contract requirements;

(c) Provide details concerning start and stop times;

(d) Verify configuration and configuration changes;

(e) Verify that test objectives, as specified in the test plans and procedures, have been met;

(f) Describe the test results in detail;

(g) Status the test steps and test procedure changes;

(h) Assure that all PTRs or discrepancies are fully described and documented;

(i) Describe all workarounds, deviations, and anomalies; and

(j) Verify that all exit criteria for the test are satisfied.

C.3.8.6 Solution Implementation Test Phase Solution implementation testing consists of four components:

(a) Development Test (DT);

(b) Operational Test (OT);

(c) Production Acceptance Test (PAT); and

(d) Site Acceptance Test (SAT)

C.3.8.6.1 Development Test (DT) DT is a formal test that must be conducted by the Contractor and witnessed by the FAA at the Contractor location. DT consists of the following tests:

(a) Integration testing; and

(b) System testing.

DT must demonstrate that all technical and performance requirements for OASIS hardware and software specified in the contract have been met. The Contractor must provide the FAA with DT plans, procedures, and reports.

CDRL TE003 Development Test (DT) Plan CDRL TE004 Development Test (DT) Procedures CDRL TE005 Development Test (DT) Reports

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 17

C.3.8.6.2 Operational Test (OT) The Contractor must support the OT, which includes formal testing conducted by the FAA at the WJHTC and Key Site. OT consists of the following two major test activities:

(a) NAS integration testing; and

(b) Operational effectiveness and suitability testing.

A Key Site test will be a subsequent component of OT and will be conducted by the FAA at OASIS site(s) designated by the FAA. The estimated duration for the FAA’s conduct of OASIS OT is sixty (60) business days. The Key Site test is estimated to take five (5) business days.

C.3.8.6.3 Production (or Integration) Acceptance Test (PAT) PAT is a formal test that must be conducted by the Contractor on each OASIS before it leaves the Contractor factory or integration site. The FAA will witness the Contractor PAT. The purpose of the PAT is to verify that the Contractor is producing units that meet OASIS requirements and are defect free before shipment. The Contractor must provide the FAA with PAT plans, procedures, and reports.

CDRL TE006 Production Acceptance Test (PAT) Plans CDRL TE007 Production Acceptance Test (PAT) Procedures CDRL TE008 Production Acceptance Test (PAT) Reports

C.3.8.6.4 Site Acceptance Test (SAT) Site Acceptance Tests (SATs) are formal tests that must be conducted by the Contractor at each FAA designated site and witnessed by the FAA. The SAT must verify that OASIS is installed and functioning properly and integrates with other NAS, applicable non-NAS, and site equipment in preparation for site acceptance. All requirements designated by the DT VRTM for verification during SAT must be verified. The Contractor must provide the FAA with SAT plans, procedures, and reports.

CDRL TE009 Site Acceptance Test (SAT) Plans CDRL TE010 Site Acceptance Test (SAT) Procedures CDRL TE011 Site Acceptance Test (SAT) Reports

C.3.8.7 Regression Testing The Contractor must correct all software and hardware discrepancies and verify, through regression testing, that the corrections are effective and do not alter system performance or functions outside the discrepancy correction area. The Contractor must recommend the level of regression testing as part of the recommended corrective action. The recommendation is based on the level of complexity of the deficiency and its degree of involvement with other system components. The Contractor must provide the FAA with regression test plans, procedures, and reports and must not proceed with regression testing without FAA concurrence on the regression test plan and test procedures.

CDRL TE012 Regression Test Plan CDRL TE013 Regression Test Procedures CDRL TE014 Regression Test Report

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 18

C.3.8.8 In-Service Test Phase The Contractor must plan for and conduct tests of modifications and updates to OASIS after initial deployment and must support FAA testing of these modifications and updates throughout the life of the contract. Such testing consists of Development Test (DT) and System Test (ST).

C.3.8.8.1 In-Service DT In-Service DT is a formal test that must be performed by the Contractor and witnessed by the FAA at the Contractor facility. DT must be conducted to verify that modifications to OASIS meet specified requirements and interrelated functions are not adversely affected. The Contractor must provide the FAA with In-service DT plans, procedures, and reports.

CDRL TE015 In-Service Development Test (DT) Plan CDRL TE016 In-Service Development Test (DT) Procedures CDRL TE017 In-Service Development Test (DT) Reports

C.3.8.8.2 In-Service System Test (ST) The Contractor must support the In-Service ST, which is a formal test conducted at the WJHTC by the FAA.

C.3.8.9 Key Site Tests

Key Site Testing is conducted by the FAA at a designated site prior to deployment to other operational sites. Its purpose is to verify within the actual environment where OASIS will be used that all requirements including those which cannot be fully tested during OT are satisfied. It is also conducted during In-Service to verify that modifications to OASIS meet the user’s needs.

The Contractor must support Key Site Testing as requested by the FAA.

C.3.9 Transition, Site Implementation, and Activation

C.3.9.1 Transition Implementation Plan (TIP) The Contractor must prepare and deliver a plan for an orderly and effective transition from the existing automation system to the OASIS. At a minimum, this plan must:

(a) Identify each transition action and/or event necessary to achieve a successful transition to full live operations at all 17 FSSs. Full live operation means that OASIS is installed and operational at all operational positions and provides all capabilities required for conduct and support of flight service operations;

(b) Provide a schedule of critical milestones;

(c) Describe how Air Traffic Control Specialists and Technical Operation Services personnel will be trained to operate and maintain OASIS;

(d) Explain the Contractor’s strategy for transitioning to full live operations of OASIS at the facility level; and

(e) Explain the Contractor’s strategy for minimal disruption to on-going flight service operations during the transition.

CDRL IM001 Transition Implementation Plan (TIP)

Operational and Supportability Implementation System (OASIS) STATEMENT OF WORK –DRAFT 19

C.3.9.2 Installation Sites The Contractor must install and integrate OASIS hardware and software at each location listed in Contract Section J, Attachment J-X. The Contractor must ensure that OASIS does not degrade the performance, reliability, maintainability, availability, security, or safety of any collocated system or equipment in those facilities.