Attach1_FMDS SOW_DRAFT.pdf

FMDS Statement of Work [DATE] i

Table of Contents

C.1.0 INTRODUCTION

C.1.01 Background

C.1.02 TFMS

C.1.03 FMDS Evolution C.1.04 FMDS Steps

C.2.0 APPLICABLE DOCUMENTS

C.3.0 FMDS REQUIREMENT

C.3.01 FMDS Services- Agile, DevSecOps, Scrum, Test-Driven C.3.02 FMDS Program Requirements C.3.03 FMDS Systems Engineering C.3.04 FMDS Software Design & Development C.3.05 Test and Evaluation (T&E) Program C.3.06 Implementation C.3.07 Contractor-Assisted Operations and Maintenance C.3.08 Training C.3.09 Future FMDS Support C.3.010 Technical and Innovation Services

C.4.0 GOVERNMENT-FURNISHED ITEMS (GFI), GOVERNMENT FURNISHED

EQUIPMENT (GFE), AND GOVERNMENT RESPONSIBILITIES

C.4.01 Government-Furnished Items (GFI) C.4.02 Government Furnished Equipment (GFE) C.4.03 Government Responsibilities

C.1.0 INTRODUCTION

The objective of the Flow Management Data and Services (FMDS) contract is to design, develop, test, implement and maintain FMDS. FMDS is the replacement for the Traffic Flow Management System

(TFMS).

C.1.01 Background Every day, the Federal Aviation Administration (FAA) provides air traffic service to more than 45,000 flights and 2.9 million airline passengers traveling across the more than 29 million square miles that make up the National Airspace System (NAS). To meet its mission of providing the safest, most efficient aerospace system in the world, the Agency works in cooperation with the airlines and other NAS users to implement Traffic Flow Management (TFM) programs which reduce delays to ensure smooth and efficient traffic flow through FAA-controlled airspace. TFM promotes safe, orderly, and expeditious flow of traffic that minimizes delays through coordination, utilization, and analysis of Traffic Management Initiatives (TMIs) that modify demand to account for changes in capacity. FAA Decision Support Systems (DSS) programs include the Terminal Flight Data Manager (TFDM) System, which integrates traffic flow data into other FAA systems and supports the Collaborative Decision Making (CDM) process, the Time Based Flow Management (TBFM) system, which covers traffic flow in the terminal areas and the Traffic Flow Management System (TFMS) which covers traffic flow in the en route airspace.

C.1.02 TFMS

C.1.02.1 TFMS History TFMS is the result of modernization of the Enhanced Traffic Management System (ETMS). ETMS was a prototype developed organically from the late 1980s through the early 2000s to support TFM functions conducted by traffic managers at Air Route Traffic Control Centers (ARTCCs) and the Air Traffic Control System Command Center (ATCSCC). It evolved into the framework for conducting CDM and therefore expanded its user base to include Terminal Radar Approach Controls (TRACONs), Air Traffic Control Towers (ATCTs), NAS users, and international air traffic control (ATC) organizations. The data produced by ETMS and, later, TFMS, became crucial to NAS users, other external organizations, and the flying public to maintain awareness of NAS operations and status.

The transition from ETMS to TFMS was approached incrementally during the timeframe of 2007 through 2010, reducing risks by postponing modernization of some of the complex functions, while establishing the foundation for a modular, open architecture. Once the foundation was established, incremental system enhancements continued through the development of defined work packages, adding new capabilities for the operational users that would not have been possible under the ETMS infrastructure.

Though the centralized processing in ETMS was replaced by TFMS, it is important to note that the user applications were never modernized, and to this day, continue to provide the end user functionality. A complex architecture of adapters exists between the modernized TFMS Core and the legacy applications to facilitate data exchange.

The TFMS system boundary is shown in Figure 1. Within the TFMS boundary are the TFM Production Center (TPC), the various TFMS Remote Sites (TRS), ATCSCC, and the Disaster Recovery Center (DRC).

The current infrastructure includes three general classes of installation. The first is the TPC and the DRC, which are the centralized sites for the receipt, processing, and synchronization of data. Users of TFMS primarily interact with the TPC/DRC by a remote site configuration, or TRS, the second class of installation. The third type of installation is specific to the ATCSCC, which is a special case of a TRS, requiring more processing capabilities to support a higher number of users with advanced functionality requirements.

Figure 1. TFMS System Boundary

C.1.02.2 TFMS Applications The software installed at both the TPC and the TRSs are in whole designed to support a required set of user functionality. Today that functionality is provided via several different applications, some of which run on a TRS workstation, while others are web-based. Though there are many different applications, six key desktop applications are used for monitoring the NAS, modeling and issuing TMIs, and logging and communicating the TMIs across facilities. These desktop applications are:

• Traffic Situation Display (TSD): User interface (UI) for all TFMS functions except those provided by Flight Schedule Monitor (FSM) and the National Traffic Management Log (NTML). It provides numerous displays to a traffic manager, including geospatial data (e.g., flight data, weather data, aeronautical data), text reports, alerts, and Flow Evaluation Area (FEA)/Flow Constrained Area (FCA) timelines and bar charts. The TSD is also used to model and issue FEA/FCAs, Reroutes, and Collaborative Trajectory Options Programs (CTOPs). Flight operators and other users external to TFMS have access to selected TSD functions through the “thin–client” TSD–C.

• Flight Schedule Monitor (FSM): Application used by traffic managers to create, issue, and maintain Ground Delay Programs (GDPs), Ground Stops (GSs), and Airspace Flow Programs (AFPs). Flight operators also use this application to view the impact of these TMIs on their fleet.

• National Traffic Management Log (NTML): Application used by traffic managers to enter and coordinate restrictions and log other significant events and actions affecting the NAS.

• Enhanced Status Information System (ESIS): System used to communicate TFM–related NAS status information within a facility. It is integrated with the NTML such that restrictions entered via NTML can optionally be posted to the ESIS display.

• Route Management Tool (RMT): Provides three separate sets of capabilities with different user bases. First is a non-operational capability to manage and coordinate the creation of routes such as preferred routes and playbook routes. Second is an operational capability to search for and display specific routes, along with determining which route avoids weather. Third is an administrative capability to export specific data for use in adaptation data sets for other systems.

• Surface Viewer (SV): Provides situational awareness of aircraft locations on the ground at a select number of airports.

These desktop applications are supported by some ancillary applications available on the TFMS Workstation along with upwards of 30 web applications, many available via fly.faa.gov.

C.1.02.3 TFMS Architecture The TFMS architecture is complex, involving different facilities, networks, communication protocols, hardware, and software. Some aspects of this architecture have been modernized, primarily the services within the TPC, while other elements still utilize older legacy technologies, to include applications, communication protocols, and data exchange processes. These legacy elements are primarily in the TRSs, though there are some in the TPC as well, such as legacy adapters. This mix of modernized and legacy architecture elements is a key factor affecting TFMS Reliability, Maintainability, Availability (RMA) and performance.

A simplistic view of today’s TFMS architecture is shown in Figure 2. The TPC is further decomposed into the Data, Application, Portal, Transition, and Auxiliary Subsystems. The Application and Data Subsystems, referred to as the “Core”, host all the centralized functionality of the system to include data management and TMI processing. The Portal Subsystem hosts the functions responsible for data ingest and publication. Four of the key types of interfaces for data exchange are the External Data Ingest (interfaces to external data sources), TRS interfaces (responsible for data exchange with the remote sites to support the applications), TFMData (the System Wide Information Management (SWIM) services for TFM data exchange), and TFMS Support Subsystem (TSS) Forwarders (responsible for providing data from the core to the Auxiliary Subsystem). The interface to the TRS applications requires legacy adaptors that are hosted in the Transition Subsystem. The Auxiliary Subsystem hosts the various TFMS web applications along with the NTML servers. The top of the figure shows the key applications in use at the TRSs, described in the previous section.

The software running at the TPC was the focus of the modernization effort over approximately the last decade. Very little legacy ETMS software remains as part of the TPC. Exceptions include the Transition Subsystem, needed to support data exchange with legacy applications.

Figure 2. Today’s TFMS Architecture

The software at the TRS sites, however, is still based on the legacy software developed under the ETMS program. The only exception is the recently deployed Surface Viewer. The TRS software is installed on two types of hardware:

• Workstations running the primary TFMS applications, which include the TSD, FSM, NTML, ESIS, SV, and RMT, along with other secondary applications.

• File Servers provide data interfaces between the TRS and TPC/DRC, among other key services.

Note that File Servers can also be concurrently used as Workstations at some sites.

The TFMS program will soon be rehosting the Web Applications portion of the Auxiliary Subsystem in a virtual environment called Flow Management Web Services (FMWS) (see Figure 3). FMWS will utilize the existing TFM Support System (TSS) Forwarders to obtain the needed data for the rehosted web applications, which will have little to no changes in their software.

Figure 3. Baseline TFMS architecture after Web Application Rehosting

C.1.03 FMDS Evolution

C.1.03.1 FMDS Concept FMDS will provide a reliable TFM automation system with a modernized architecture that will increase reliability and reduce response time. A microservices architecture will provide flexibility to the FAA for implementing capabilities and leveraging enterprise services. A modernized architecture will also support future enhancements. To support the transition to a services-based NAS, functions needed by multiple applications (and automation systems) will be implemented as shared services. This will avoid duplication of functions and data across services, applications, and automation systems, which will simplify development and maintenance. A modernized architecture will also improve the processes for providing system support, from reducing the need for synchronizing data on the backend to providing visibility into system and component performance to prevent system failures.

TFM automation system functions will be implemented in a streamlined interface that will improve the user experience. The consolidated application suite and improved performance of FMDS will allow traffic managers to view all traffic, TMIs, and weather in one integrated application, allowing for more proactive and efficient execution of TFM actions. Today, traffic managers collect information electronically but manually log it. FMDS will support automated logging of common information, reducing traffic manager workload associated with entering duplicate data across applications.

Automated logging will also make it easier for traffic managers to share information with multiple facilities, improving electronic coordination.

NAS users will access information about NAS operations and collaborate with traffic managers in new ways. The various TFMS web applications that NAS users must currently monitor separately will be streamlined and accessible via a centralized portal. NAS users will be able to subscribe to notifications of changes in TMIs, operations plans, and other information, relieving them from the need to poll or scrape several websites. CDM members will transition away from the use of local instances of the FSM application, as its functionality will be included in the integrated situation awareness display application.

To support this transition, FMDS may provide application programming interfaces (APIs) that will allow CDM members to access data and services they can use to model the impact of TMIs on their flights.

Alternatively, or in addition, FMDS may provide CDM members access to a web-based version of the integrated situation awareness display that will allow them to perform similar tasks as they can do today via FSM and the remote desktop version of the TSD application.

Post-event analysis will be supported by a searchable store of the data FMDS presents to users, data exchanged among FMDS users/facilities, and data exchanged among the underlying software services and automation systems. The data store will support better understanding of series of events and their impacts on NAS operations and will provide improved replay capabilities.

FMDS will use NAS enterprise services and standard industry data formats when appropriate to minimize the number of different data structures utilized and duplicate functionality across systems.

This will allow for simplified internal maintenance and updates and will streamline data sharing across NAS automation systems. The full FMDS Concept of Operations is included as Attachment J.2.

C.1.03.2 FMDS High-Level Architecture FMDS will provide a reliable automation system to support traffic flow management functions in a modernized, service-based architecture using industry standards. Modernization will increase reliability and reduce response time for users, and a standards- and service-based architecture will provide flexibility to the FAA for implementing capabilities as well as extensibility to future enhancements. As much as possible, functions needed by multiple applications will be implemented as services, keeping the business logic in each application as minimal as possible.

FMDS comprises three distinct subsystems: Operations, Maintenance, and Testing and Training, shown as follows in Figure 4.

Figure 4. FMDS High-Level Architecture

The Operations Subsystem includes three Computer Software Configuration Items (CSCIs): FMWS, Flow Management Services (FMS), and Flow Management Data (FMD). The FMD CSCI will provide common services for ingesting, matching, processing, updating, and managing flight data, along with trajectory modeling and trajectory conformance monitoring. The FMS CSCI will be composed of back-end services and front-end applications to provide various TFM-specific functionality, including demand monitoring, and alerting, as well as TMI modeling, coordination, and implementation. To promote common situational awareness and facilitate collaboration, the FMWS CSCI will provide operational information to external users via a series of web application portals. The distinction between FMD, FMS, and FMWS is summarized in Table 1.

Table 1. FMDS Operations Subsystem CSCIs

Flow Management Data (FMD) Flow Management Services and Applications (FMS)

Flow Management Web Services (FMWS)

• Ingests, processes, matches, and updates flight data from the following sources:

o NAS flight data o International flight data o CDM flight data o Flight schedule data o TMIs issued via FMS.

• Performs trajectory modeling and conformance monitoring.

• Publishes and archives flight data

• TFM-specific functions, such as demand/capacity monitoring and TMI modeling and implementation.

• Centralized architecture, minimizing footprint at remote sites.

• New thin client Situation Display integrating TSD, FSM, NTML, ESIS, RMT, and SV

• Public-facing APIs and data publication services

• Modernized and integrated web application portals leveraging FMS microservices

The FMDS Testing and Training Subsystem is made up of three CSCIs: Scenario Manager (SM), System Connections (SC), and Simulation Engine (SE). The goal is to support identical FMDS applications in both the operational and testing/training environments, differing only in the underlying data source. In lieu of the live data feeding the operational environment, the FMDS testing/training environment would be served by emulated and simulated data. Emulated data is a set of messages injected into the system as if they were coming from an external source, like weather data from Common Support Services- Weather (CSS-Wx) or flight plans from En Route Automation Modernization (ERAM). Simulated data is initiated using historical data from a point in time in the past and is then changed based on actions taken by users. For example, if a user issues a TMI that delays the departure of a flight, the simulation engine will not rely on historical data for flight events but will simulate the departure time and position updates of the flight to comply with the TMI.

The third subsystem, FMDS Maintenance, is composed of Identity Access Management (IAM), Monitor and Control (M&C), and Support Data Management (SDM). The IAM CSCI will manage user profiles, to include which users have access to which system services and capabilities. IAM requirements may be partially met via enterprise services. The M&C CSCI encompasses all functions for conducting monitor and control activities of the system along with system event logging. The SDM CSCI includes the offline data archive of past operational data along with the services to create and maintain future adaptation data releases.

FMDS will be implemented on top of underlying computation, storage, and networking infrastructure.

The software will be containerized, and the hardware will run in a virtual server environment.

C.1.04 FMDS Steps FMDS will be implemented in three clearly defined steps.

C.1.04.1 Step One- FMDS Situation Display In the first step, shown in Figure 5, the FMDS Situation Display (SD) will be deployed, replacing all the applications and supporting infrastructure currently at the remote sites. (Note that the supporting infrastructure currently at the remote sites is envisioned to be retired and the FMDS SD infrastructure will be transitioned to FAA owned-supported infrastructure and may not form a part of this effort).

Figure 5. FMDS Step 1: Remote Site Replacement

C.1.04.2 Step Two- FMDS System Deployment (TFMS Retirement) FMDS will be deployed and assume all flight data management functions, including ingest and processing, trajectory modeling, and publication. Separately, additional services will be deployed in FMS to replace other critical TFMS Core functionality, such as TMI modeling and implementation. The legacy web applications will be retired and replaced by the new modernized applications in FMWS. FMS will interface with FMD to exchange flight data updates and FMWS to exchange required information to/from the hosted web applications. When all the existing TFMS functionality has been accounted for and deployed, a complete switchover to the new FMDS environment can take place. This is shown in Figure 6.

Figure 6. Step 2 – FMDS Standup and TFMS Retirement

C.1.04.3 Step Three- FMDS Future Enhancements FMDS will also begin developing and implementing new capabilities. The following new capabilities are included with the existing System Specification Document (SSD) Attachment J.3:

• Improved Demand Prediction (IDP):

• Improved Departure Time Prediction

• Improved Trajectory Model

• Probabilistic Demand Predictions

• Restriction and TMI Modeling

• Integrated Departure Route Planning (IDRP)

• Automated Problem Resolution

• Alternatives Modeling

Additional new capabilities are anticipated to be approved for future Government investment. When those capabilities are approved the SSD will be updated accordingly, and those capabilities will form a part of this requirement.

C.2.0 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.

Inclusion of an applicable law or regulation in the below list does not imply exemption from any applicable law or regulation. To the maximum extent possible, hyperlinks are provided to internet sites where copies of the documents may be obtained.

Copies of FAA specifications and interface documents may be obtained from the Federal Aviation Administration, Headquarters Public Inquiry Center, APA-230, 800 Independence Avenue SW, Washington, DC 20591, 202-267-3484. Requests should fully identify the material desired and cite the solicitation or contract number.

Requests for copies of documents not covered in the preceding paragraph should be addressed to the Contracting Officer (CO). Contractor requests should fully identify material desired and cite the solicitation or contract number.

Configuration Management:

• FAA Order 1800.66A Configuration Management Policy

• FAA-STD-021A CHG1, Configuration Management

• FAA-STD-058, Standard Practice Facility Configuration Management

• MIL-HDBK-61B, Configuration Management Guidance

Human Factors:

• DOT/FAA HF-STD-001B, Human Factors Design Standard

• DOT/FAA HF-STD-003, Alarms and Alerts in the Technical Operations Environment

• DOT/FAA HF-STD-004A Human Factors Engineering Requirements

• DOT/FAA HF-STD-008, Air Traffic Control Traffic Control Tower Alert Standard

• DOT/FAA HF-STD-009, Technical Operations Graphical User Interface Standard

• Human Interface Guidelines

Integration and Implementation:

• FAA Order 1050.1F, Environmental Impacts: Policies and Procedures

• FAA-G-2100G Rev 2 Application Handbook for Electronic Equipment, General Requirements

Logistics, Operations, and Maintenance:

• FAA Order 6000.15J, General Maintenance Handbook for NAS Facilities

• FAA Order JO 6000.53E Remote Maintenance Monitoring and Control Interface Development and Implementation

• FAA-HDBK-006C, Reliability, Maintainability and Availability (RMA)

Program Management

• EIA Standard 748D, Earned Value Management Systems (EVMS)

• FAA Order 1350.14B, Records Management

• DOT PMO-PLN-0002 Rev 2 “PMO Risk, Issue, and Opportunity (RIO) Management Plan (RMP)” https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1034069 https://www.tc.faa.gov/its/worldpac/techrpt/faa-std-021A1.pdf https://www.tc.faa.gov/its/worldpac/standards/faa-std-058.pdf https://quicksearch.dla.mil/Transient/E99B67D23967413B8AB19FA519614203.pdf https://hf.tc.faa.gov/publications/2016-12-human-factors-design-standard/ https://https/www.tc.faa.gov/its/worldpac/standards/faa-hf-std-003.pdf https://hf.tc.faa.gov/publications/2016-09-human-factors-engineering-requirements/HF-STD-004A.pdf https://www.tc.faa.gov/its/worldpac/standards/FAA-HF-STD-008.pdf https://www.tc.faa.gov/its/worldpac/standards/FAA-HF-STD-008.pdf https://www.tc.faa.gov/its/worldpac/techrpt/ct01-8.pdf https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1027826 https://www.tc.faa.gov/its/worldpac/standards/faa-g-2100gAppHB.pdf https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1039679 https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.list/?q=6000.53&documentTypeID=&statusID=2 https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.list/?q=6000.53&documentTypeID=&statusID=2 https://www.tc.faa.gov/its/worldpac/standards/faa-hdbk-006c.pdf https://www.sae.org/standards/content/eia748d/ https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1022926

• National Defense Industrial Association (NDIA) IBR Guide

Quality Assurance:

• FAA Order JO 7210.634A, ATO Quality Control

• FAA Order JO 7210.633A CHG 1, Air Traffic Organization Quality Assurance

Safety and Health:

• FAA Order JO 1000.37C, Air Traffic Organization Safety Management System

• FAA Order 8040.4B, Safety Risk Management Policy

• FAA Order 8000.369C, Safety Management System

• SRMGSA Safety Risk Management Guidance for System Acquisitions

• ATO/SMS Safety Management System Manual

Security:

• FAA Order 1600.69C, Facility Security Management Program

• FAA Order 1600.1F, Personnel Security Program

• FAA Order 1600.75, Protecting Sensitive Unclassified Information (SUI)

• FAA Order 1370.121B, FAA Information Security and Privacy Program & Policy

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

Organizations

• NIST FIPS 199, Standards for Security Categorization of Federal Information and Information

Systems

• NIST SP 800-18, Guide for Developing Security Plans for Federal Information Systems

Software / Systems Engineering:

• FAA-STD-026A, DOT/FAA Standard: Software Development for the National Airspace System

(NAS)

• FAA SWIM Governance Policies version 3.1

• FAA SWIM-002, Syntax and Processing of XML-Based Documents in the Context of SWIM-

Enabled Services, Software Specification Version 1.0

• FAA-STD-075, Creating Service Identifiers

• RTCA/DO-278A, Software Integrity Assurance Considerations for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) Systems

• IEEE 1517-2010, Software Life Cycle Reuse Processes Information Technology – System and

Software Life Cycle Processes – Reuse Processes

• IEEE/ISO/IEC 12207:2017 Systems and Software Engineering – Software Life Cycle Processes

• ISO/IEC/IEEE 29148:2018 Systems and Software Engineering – Lifecycle Processes –

Requirements Engineering

• IEEE Standard 1016-2009 IEEE Standard for Information Technology – Systems Design –

Software Design Description https://www.ndia.org/-/media/sites/ndia/divisions/ipmd/division-guides-and-resources/ndia-ipmd-ibr-guide-rev-3-sep-11-2019.ashx https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1038154 https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1038153 https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1040348 https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1031187 https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1037699 https://www.faa.gov/air_traffic/publications/media/srmgsa.pdf https://www.faa.gov/air_traffic/publications/media/ATO-SMS-Manual.pdf https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1029860 https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1040448 https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/14210 https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1040976 https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf https://csrc.nist.gov/pubs/sp/800/18/r1/final https://www.tc.faa.gov/its/worldpac/standards/faa-std-026a.pdf https://www.tc.faa.gov/its/worldpac/standards/faa-std-026a.pdf https://www.faa.gov/sites/faa.gov/files/air_traffic/technology/swim/governance/SWIM%20Governance%20Policies%20v3.1_20200206_Final.pdf https://www.faa.gov/sites/faa.gov/files/air_traffic/technology/swim/governance/Syntax%20and%20Processing%20of%20XML-Based%20Documents%2006162015.pdf https://www.faa.gov/sites/faa.gov/files/air_traffic/technology/swim/governance/Syntax%20and%20Processing%20of%20XML-Based%20Documents%2006162015.pdf https://www.faa.gov/sites/faa.gov/files/air_traffic/technology/swim/governance/FAA-STD-075%20FINAL%206-29-2021.pdf https://standards.globalspec.com/std/1460365/RTCA%20DO-278 https://standards.globalspec.com/std/1460365/RTCA%20DO-278 https://standards.ieee.org/ieee/1517/4603/ https://standards.ieee.org/ieee/1517/4603/ https://www.techstreet.com/ieee/standards/ieee-iso-iec-12207-2017?product_id=1907731 https://standards.ieee.org/ieee/29148/6937/ https://standards.ieee.org/ieee/29148/6937/ https://standards.ieee.org/ieee/1016/4502/ https://standards.ieee.org/ieee/1016/4502/

• AS9100D Quality Management Systems – Requirements for Aviation, Space, and Defense Organizations

• ISO/IEC/IEEE 90003:2018, Software Engineering- Guidelines for the application of ISO 9001:2015 to Computer Software

Test and Evaluation:

• Federal Acquisition System (FAS) Acquisition Management System (AMS) Guidance, Test and Evaluation Process Guidelines

• FAA AMS Policy, Section 4.4, Test and Evaluation

• FAA William J. Hughes Technical Center Test and Evaluation Handbook, Version 5.0

• FAA Order NG 1810.8B, William J. Hughes Technical Center’s Test and Evaluation Policy

Training

• FAA Order JO 3000.57B, ATO Technical Operations Training and Personnel Certification

• FAA Order JO 3120.4R, Air Traffic Technical Training

• FAA-STD-028C, Contract Training Programs

• FAA Order JO 7110.65AA, Air Traffic Control

• FAA Order JO 3000.22B Air Traffic Organization Technical Training Management

C.3.0 FMDS REQUIREMENT

The contractor must design, develop, test, implement, integrate, and maintain the FMDS solution using a microservices architecture that meets all functional requirements in the SSD (Attachment J.3) and in accordance with this Statement of Work (SOW). The contractor must provide training for the system and support FMDS operations after implementation. The infrastructure/hardware requirements for the system will be fulfilled using FAA enterprise resources. The contractor assumes responsibility for the functional software requirements and platform compatibility. This approach leverages the FAA’s enterprise investments, maximizes compatibility between systems, and delivers working software quickly which can evolve rapidly to meet changing requirements.

C.3.01 FMDS Services- Agile, DevSecOps, Scrum, Test-Driven

The contractor must utilize a "Team of Teams" approach that incorporates the Agile Philosophy using Development/ Security/ Operations (DevSecOps), Scrum, and Test-Driven Design (TDD)/ Acceptance Test Driven Development (ATDD) methodologies, processes, and meetings.

C.3.01.1 Agile Philosophy

The four values of the agile philosophy are:

1. Individuals and interactions over processes and tools.

2. Working software over comprehensive documentation.

3. Customer collaboration over contract negotiation.

4. Responding to change over following a plan.

https://www.sae.org/standards/content/as9100d/ https://www.sae.org/standards/content/as9100d/ https://standards.ieee.org/ieee/90003/7197/ https://standards.ieee.org/ieee/90003/7197/ https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Ffast.faa.gov%2Fdocs%2Fteguidelines.docx&wdOrigin=BROWSELINK https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Ffast.faa.gov%2Fdocs%2Fteguidelines.docx&wdOrigin=BROWSELINK https://fast.faa.gov/docs/acquisitionManagementPolicy/AcquisitionManagementPolicy4.4.pdf https://www.faa.gov/about/office_org/headquarters_offices/ang/library/events/v_vsummits/documents/media/TEHandbook.pdf https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1036741 https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1041530 https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1038435 https://www.tc.faa.gov/its/worldpac/standards/FAA-STD-028C.pdf https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1029467 https://www.faa.gov/regulations_policies/orders_notices/index.cfm/go/document.information/documentID/1037513

C.3.01.2 DevSecOps

DevSecOps pulls together development, operations, and security (personnel and capabilities) to automate and optimize the delivery of applications and infrastructure. It promotes collaboration and information sharing, enabling solutions to be delivered quickly, efficiently, and with a higher level of security compliance and lower technical debt (i.e., the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time). This approach involves the following sequential functions, which are performed iteratively throughout the entire software lifecycle:

• Planning new features and functionality

• Coding and building the new features based on user stories.

• Integrating new code into the existing code base (known as Continuous Integration/ Continuous

Delivery (CI/CD))

• Deploying into a runtime environment

• Monitoring feature performance, identifying incidents, and applying fixes

• Gathering of feedback from end users to incorporate into the next development cycle.

The following functions are performed continuously during each sequence of functions above, embedded into the entire process:

• Test & Evaluation

• Security (including safety)

• Compliance (i.e., performance reporting, earned value management, risk management, configuration management, safety)

C.3.01.3 Scrum Scrum is a specific framework with established terms (definitions), roles, processes, and ceremonies.

The basic scrum framework as it applies to this effort is:

• The Product Backlog is developed based on the specifications within the FMDS SSD, which is maintained by the Product Owner (i.e., the FAA). The backlog is emergent and refined continuously to add detail, estimates and order.

• The FAA has organized the FMDS SSD into three fixed steps as outlined in paragraph C.1.4 FMDS Steps and described in the Release Plan (attachment J.4). Within these steps the product backlog must be further allocated into planned releases, builds, and sprints.

o Releases are deployed iterations of the FMDS solution that meet a subset of the Backlog, called Prioritized Epics. Within FMDS, each release is envisioned to encompass a set of functions that encompasses the capabilities of a single legacy application or capability. Each release will go through the typical operational deployment process.

o Builds are discrete elements of each release that meet a subset of the prioritized epic and are comprised of sprints. Within FMDS each build is a set of functions that encompasses a single FMDS capability.

o Sprints are increments i.e., a sum of functional requirements from the prioritized epic from the build and are completed by the team to meet the definition of done.

o A sprint backlog is established by the team for each sprint and when complete is defined as an increment.

o A user story is an informal, general explanation of a software feature written from the perspective of the end user.

• The quantity and size of releases, builds, and sprints are variable and dependent on progress made in the previous increments, builds and releases in meeting the functional requirements outlined in the product backlog/FMDS SSD. The skill and experience of the development team is an additional driving factor in the quantity and size of releases, builds and sprints.

C.3.01.4 Test Driven Design (TDD) / Acceptance Test-Driven Development (ATDD)

TDD requires the conversion of software requirements to test cases before the software is fully developed and tracks all development by repeatedly testing the software against the test cases. ATDD requires that acceptance tests with specific acceptance criteria are also developed in advance of development and implementation.

The Contractor must execute the TDD/ ATDD approach to software development by implementing appropriate levels of unit testing, coding, and refactoring of source code.

C.3.01.5 Iterative Development

The FMDS effort is iterative at multiple levels. Throughout the remainder of this SOW, specific requirements (i.e., data deliverables, audits, reviews) are specified as applying at either the step, release, build, or sprint level. While there are three separate FMDS steps, the step level equates to the program level- as such, program level requirements (i.e., Contract Data Requirements List (CDRLs) and reviews) are required for application to the entire program and should be submitted or conducted once and updated as necessary. To the extent a requirement (i.e., CDRLs and reviews) applies at the release, build or sprint level it will apply in each instance of a release, build and/or sprint. The overarching program compliance requirements (e.g., quality assurance, safety, risk management) apply continuously throughout the entire effort and are embedded in the team processes to the maximum extent possible.

Attachment J.5, “FMDS Approach to Development and Related Documentation” provides an illustration of the Agile process and several deliverables for the FMDS program at the sprint through step levels.

This document identifies the program level requirements (i.e., requirements applicable continuously throughout the DevSecOps process) in SOW paragraph C.3.02 Program Requirements and Management, the FMDS Systems Engineering design and development requirements in SOW paragraph C.3.03, the software development requirements in SOW paragraph C.3.04, the test and evaluation requirements in SOW paragraph C.3.05, and the training requirements in SOW paragraph C.3.06.

C.3.02 FMDS Program Requirements

C.3.02.1 Program Management

The Contractor must manage the contract in accordance with the terms and conditions of this contract.

The Contractor must establish and maintain a Contractor Program Management Organization (CPMO) to manage all Contractor resources, personnel, subcontractors, and activities involved in the delivery of the FMDS solution. The Contractor must perform Program Management to support and coordinate the work performed under this contract to ensure compliance with all terms and conditions and, to drive technical excellence and ensure the team meets schedule(s).

C.3.02.1.1 Program Management Plan

The Contractor must develop, deliver, and implement an integrated Program Management Plan (PMP) (CDRL M001). The PMP must integrate the management of all functional areas (e.g., Program Management, System Engineering, Software Development, Test and Evaluation, Implementation, Maintenance) and define the specific objectives to be accomplished for the successful execution of the program.

C.3.02.1.2 Performance Management System and Reporting Metrics

The Contractor must establish and maintain a performance-management system to ensure that the appropriate metrics are in place to manage, monitor, and report program performance. The performance metrics defined by the Contractor must be tied to the Work Breakdown Structure (WBS) (C.3.02.3.1) and must support effective program monitoring by the FAA and the Contractor. The Contractor must also define specific performance metrics as part of their PMP. Minimum mandated metrics are outlined in the Performance Requirements Summary (PRS), Attachment J.14. The contractor must report on the performance metrics in the Integrated Program Management Reports (IPMRs) (CDRL M003 and C.3.02.3). The Contractor must delete, modify, or implement new performance metrics as required by the FAA.

C.3.02.2 Meetings and Reviews

The Contractor must support one-time and recurring meeting and evaluations with the Government to discuss program progress and identify potential problems and resolve identified issues. The Contractor must ensure that appropriate Contractor personnel from various and relevant functional disciplines attend FAA meetings. The meetings are outlined in this paragraph and throughout the SOW.

C.3.02.2.1 Meeting Agendas, Presentation Materials Minutes, and Decisions

The Contractor must prepare Agendas, Presentation Materials, Meeting Minutes, and Action Item Lists as directed for each meeting, conference, review, and evaluation to maximize the benefits of any meetings held with the FAA. The Contractor must provide an agenda and notify the CO of its readiness five (5) business days prior to the start of each meeting, conference, review, and evaluation. All CDRL items required for a meeting, conference, review, or evaluation are to be delivered in accordance with the (CDRL M002) requirements.

The following instructions are applicable to all meetings, reviews, conferences, and evaluations:

1. All Program Management Reviews (PMRs) will be held at a Contractor-provided facility within thirty (30) miles of Washington, DC, unless otherwise directed by or approved by the government. All other meetings, conferences, and evaluations will be held at the Contractor’s facility unless otherwise directed by or approved by the Government. The Contractor must provide teleconferencing capability, internet access, and facility locations to accommodate necessary participation as requested by the Government. The Contractor must propose a date for the meeting, review, conference, or evaluation for the Contracting Officer’s Representative (COR's) approval.

2. The Government reserves the right to revise and to direct the Contractor to revise all agendas and presentation materials. The Contractor must provide appropriate Contractor personnel to respond to Government questions. The Contractor must prepare and deliver a summary of open, pending, and closed action items and presentation materials prior to the start of each scheduled meeting, conference, review, and evaluation. The Government will revise the delivery times when necessary.

C.3.02.2.2 Post Award Conference

Within 3 weeks of contract award, the Contractor must actively participate in a post-award conference (program kickoff meeting) with the FAA, at the Washington, DC, headquarters facility. Prior to the meeting, the Contractor must develop and deliver an agenda and meeting materials (CDRL M002) based on the Contractor’s experience, lessons learned and Program-Management best practices. The meeting must also include the following agenda items:

• Establishing a collaborative team environment and clear communication paths

• Discussion of contract and technical transition-in activities, including issues, risks, and mitigations

• Discussion of FAA FMDS near-term and longer-term activities and clarifying objectives, challenges, relevant stakeholders, and specific expectations

The Contractor must provide a report on the meeting in accordance with CDRL M002.

C.3.02.2.3 Program Management Reviews (PMRs)

The Contractor must support the Government’s conduct of quarterly PMRs that address the following on a contract-wide basis:

• The Contractor’s accomplishments since the previous review.

• The Contractor’s plans for the next 90 days.

• Quarterly and year-to-date metrics summarizing the support services provided.

• Earned Value Management System (EVMS) status including identification of major drivers behind schedule variances and the action plans to resolve any variances, if applicable (C.3.02.3.3)

• Review of all open actions from previous PMRs and actions closed since the most recent PMR.

• A summary of the risks, issues, and opportunities (RIO) management activities for the previous

90 days (C.3.02.5); and

• Any risks, issues and concerns outside of the RIO process, that should be brought to the

Government’s attention, including recommended actions to mitigate any risks, issues and concerns that are identified.

The Contractor must submit PMR presentation materials (CDRL M002) to the Government at least seven

(7) calendar days prior to the scheduled start of the review. PMRs may be held at a Government or a Contractor facility as determined by the Government.

C.3.02.2.4 Scrum Ceremonies and Technical Interchange Meetings (TIM) The contractor must lead and support all scrum ceremonies including:

• Sprint Planning- establishes a sprint goal, breaks down user stories into tasks, estimates the associated level-of-effort, and understand dependencies between them.

• Daily Scrum- identify completed tasks and next steps and team provides advice on tasks.

• Weekly Status Meeting- primary project control meeting between the business and technical team. The purpose is to maintain a prioritized backlog (refined and clarified in the meeting), share current metrics, and to coordinate action needed from the business partner.

• Monthly Status Meeting- takes the place of the scheduled weekly meeting with the addition of financial status review and overall roadmap. Support required from outside the team is identified, stakeholder concerns are discussed, and future milestones confirmed.

• Sprint Review- provides a demonstration of the product increment and a review of what was accomplished during the sprint.

• Sprint Retrospective- reflects on the sprint concluded and identifies improvements for implementation during the next sprint.

• Release Review- reviews all development efforts in each environment (including testing) and all associated CDRLs. (SOW C,3,06.1.2).

Attachment J.6 FMDS Meetings provides additional guidance on attendees, inputs, outputs, and best practices for each of the scrum ceremonies. The required deliverables and associated CDRLs for each meeting are also identified in the attachment. The Government will indicate whether the meetings will be held at a Government facility or a Contractor facility. In addition, the Government will indicate whether Contractor participation must be in-person or whether it may be via teleconference depending on the nature of the meeting.

In addition to the scrum ceremonies and as requested by the Government, the Contractor must attend and participate in TIMs to address specific technical issues that are outside of the scope of the sprint teams. The Government will indicate whether the meeting will be held at a Government facility or a Contractor facility. In addition, the Government will indicate whether Contractor participation must be in-person or whether it may be via teleconference depending on the nature of the meeting. The personnel representing the Contractor must have the requisite knowledge, skills, and experience to discuss the topics identified on the meeting agenda. As requested by the Government, the Contractor must coordinate the scheduling of meetings with required participants, issue calendar invitations, and prepare agendas, presentation materials, meeting minutes, and action item lists to support the conduct of the meetings.

If the Contractor holds technical interchange meetings with its major subcontractors, the Contractor must allow Government points of contact to participate in the portions of the meetings related to FMDS services.

C.3.02.3 Program Control & Integrated Program Management Reports

The Contractor must implement and conduct a program control activity that ensures efficient and timely program execution, software-engineering, and development processes. The Contractor must maintain effective control over the software engineering and design-development processes, including subcontract items and services, to ensure cost, performance, and schedule requirements are met; to provide early detection and resolution of problems; and to reduce risk. The program-control activity must be designed in a way that allows identification of program anomalies and correction plans in a timely manner. The Contractor must provide Integrated Program Management Reports (IPMR) (CDRL M003). The Government will have the opportunity to respond to the IPMR report after submission by the contractor within a mutually agreed period. Responses would normally be provided two weeks after submission by the Contractor. If it is necessary for the Contractor to provide additional information to Government representatives, this period may be extended as appropriate. Any discrepancies and/or significant issues must be addressed in the PMRs (C.3.02.2.3).

The Contractor must provide ongoing access to pertinent records and data, including those supporting the cost data reported, during each program phase and throughout performance of the entire contract.

The Contractor must track FAA decisions and action items outside of the scope of the agile development ceremonies until the disposition of any action is mutually agreed to by the Contractor and the Government and include these in each IPMR.

C.3.02.3.1 Contract Work Breakdown Structure (CWBS)

The Contractor must generate and maintain a CWBS and CWBS Dictionary for this effort that is a WBS tailored to the FMDS contract and that aligns with the WBS created during the integrated baseline review. The CWBS is the basis for the Contractor-defined lower-level CWBS elements, cost accounts, and work packages during the performance of the contract.

The Contractor must use the CWBS as the framework for reporting contract planning, budgeting, and schedule status. Contract modifications that modify, add, or delete scope of work under the contract must be incorporated into appropriate CWBS cost accounts for work package identification, definition, and procurement-request relationships, as in the basic contract.

During the performance of the contract, no change to the approved CWBS, associated definitions, or any of the reporting elements may be made by the Contractor without prior written approval from the Government Contracting Officer. The CWBS must be managed and submitted as part of the PMP (CDRL M001).

C.3.02.3.2 Integrated Master Program Schedule

The Contractor must develop, update, maintain, and deliver an integrated master program schedule for discussion at the quarterly PMRs for the FMDS program. The initial schedule is included as part of the PMP (M001 and C.3.02.1.1) and the updates are included as part of the IPMR (M003 and C.3.02.3) The Contractor must portray an integrated schedule for the design, development, integration, test, delivery, deployment (releases), training, and support of FMDS…