Attachment S-1 Section C - SOAR Statement of Objectives.pdf

Attachment S-1 SIR 693KA9-22-R-00016

C.1 STATEMENT OF OBJECTIVES (SOO)

The System of Airports Reporting (SOAR) is the primary, but not exclusive, system services requirement under this solicitation.

PART I

C.1.1 BACKGROUND

The Federal Aviation Administration (FAA) has legislative mandates to undertake specific activities to plan and develop a national system of airports in the United States under United States (US) Code Title 49 § 47101. To fulfill our mission, the organization developed SOAR, a custom software that automates approximately 80 percent of our critical job functionality and associated data requirements. SOAR automates mission-critical business functions in the program areas of National Plan of Integrated Airport Systems (NPIAS), Air Carrier Activity Information System (ACAIS), Airport Improvement Program (AIP), Supplemental AIP, three COVID-Relief grant programs, Airport Improvement Grants (AIG) and Airport Terminal Program (ATP) under the Bipartisan Infrastructure Law (BIL) and the Passenger Facility Charge (PFC) program. For more information on these programs, see Airport Programs & Guidance (faa.gov).

SOAR also incorporates business intelligence tools to transform the data into critical information needs to respond to Congress and the public on mission status and trends.

The Office of Airports (ARP), Airport Planning and Programming (APP) implemented SOAR in 2000. In 2019, APP began a ‘transformation process’, evaluating, selecting, and implementing new technologies to address security, usability, sustainability and performance issues associated with the legacy system.

This Statement of Objectives (SOO) covers SOAR Program Management, operations and maintenance, enhancements, continued transformation, security, data analysis/reports, change management, user support, and other support needs for SOAR or other ARP systems (see section C.2).

C.1.2 SOAR TECHNICAL OVERVIEW

SOAR operates as the primary mission support system for ARP/APP as described in section C.1.1.

SOAR consists of two (2) major sub-systems:

1. SOAR Internal supports planning, financial assistance, and compliance activities for the internal organization users. Internal modules cover business functions for NPIAS, Air Carrier, AIP (and other airport grant programs), and PFC. Other modules include support functions such as Sponsor, Public Agency, and Airport contact management, user management, prior year archives, reporting, issue reporting, and notifications. ARP staff as well as various stakeholder organizations (e.g., Office of the Secretary of Transportation (OST), Office of Finance and Management (AFN), Office of Government and Industry Affairs (AGI)) are authorized to access SOAR on a job function basis.

SOAR Internal uses FAA’s MyAccess for authentication.

2. SOAR External (hereinafter referred to as Airports External Portal (AEP)) supports external organizations responsible for providing or confirming data provided to ARP. External modules include AIP for sharing information about proposed and ongoing projects, Air Carrier and Cargo data upload functions supporting filing requirements, and PFC to report collection and disbursement information. AEP is accessed via the Internet by authorized users based on system assigned user name and user-specified 12 character passwordi.

https://www.faa.gov/airports/

AEP and SOAR synchronize data nightly via database connection controlled from the secured internal site.

See Section J – S-7 SOO Artifacts Workbook Tabs 1a and 1b for SOARii high level functions and features by module or component as well as non-functional requirements. Tab 1c of the same reference provides the application site map.

SOAR is considered a major application from the FAA perspective, and categorized as Moderate according to FIPS-199 definitions. It is owned by FAA, with contractor support for operations and maintenance, and is hosted in the FAA domain (with current contractor site exceptions as shown in Section J – S-7 SOO Artifacts Workbook Tab 2 for SOAR System Architecture, location, and related information). Authority to Operate (ATO), originally authorized in 2001, is affirmed and renewed through continuous security assessments. The most recent ATO is dated 09/07/2022.

In addition to development environments currently hosted outside FAA, there are three lower-level environments (Demo, Test and Training) plus Production. Demo and Test are hosted through FAA Cloud Services in Amazon Web Services (AWS-East). Demo and Test do not include AEP functionality. Training, which is hosted by Office of Information and Technology (AIT) at the William J. Hughes Technology Center (WJHTC), is used for training and familiarization as well as for pre-production User Acceptance Testing (UAT). Production (Internal and External) as well as External “Proto” (used for Test and Training) is currently hosted at WJHTC. See Section J – S-7 SOO Artifacts Workbook Tab 2 for SOAR System Architecture, location, and related information.

In addition to the internal system connection between AEP and SOAR, SOAR has Memoranda of Understanding or other interconnection agreements or utilizes vendor based Application Program Interface (APIs) between a handful of systems. There are also several data loads from publically available data, data provided from ARP program staff, or other approved sources. Data loads are performed via scripts. See Section J – SOO Artifacts Workbook Tab 3 for system interconnect descriptions and status of interconnect agreements, information about recurring data loads, and sample descriptions of ad hoc requests.

ARP purposefully designed and built SOAR using commercially available products to deliver custom business features. The selection criteria for new components emphasized the following criteria: align with FAA Enterprise Architecture (EA) and technology roadmap wherever possible, be sustainable from a cost perspective (including availability of competitively priced labor), and allow full integration within the legacy SOAR application during transformation unless technical and cost benefits significantly outweigh integration benefits. See Section J – S-7 SOO Artifacts Workbook Tab 4 for current SOAR technology stack.

SOAR Production and Training operate 24/7/365 except for defined maintenance periods (currently after 9 pm Eastern Time, or as schedule for weekends and holidays). The SOAR Core Group (SCG) manages and tracks defects and change request through a Change Control Board (CCB) with members from the various APP program office, chaired by the SOAR Business Lead and supported by a contractor Secretariat. See Section J – S-7 SOO Artifacts Workbook Tab 5 for additional information on current operational processes and team structure.

C.1.3 OBJECTIVES AND SCOPE OF WORK

ARP objectives are stated by work areas outlined in section C.2.1 below. The overall objective of SOAR is to deliver 100 percent of business mission functions, security, and applicable data/records management through a user experience that enhances productivity. The purpose of this SOO is to provide contractor support to achieve that objective through the sub-objectives described in each of the work areas. Briefly stated, the work areas include:

Work Area 1 -- The contractor must provide project resource management necessary to on- and off-board project team members, interface with client, stakeholders and other service providers as necessary to transition-on, transition-off and provide services through the life of the resulting contract.

The contractor must also provide oversight, management and coordination across multiple projects within the entire scope of work (all work areas) as needed.

Work Area 2 -- The contractor must operate and maintain SOAR environments coordinating as needed with other team members where services are provided by other vendors (e.g., information technology office and its contractors, cloud service providers, or others such as OST contractors and staff).

Full life cycle support includes cradle to grave operations and maintenance, bug and data fixes, change requests as required for new or modified business requirements, configuration control, security compliance, testing, and user support. It includes the current functionality in SOAR and the future requirement that may be mandated by Congress or deemed necessary by the business to fulfill the organization mission. The contractor must also provide system and program related services to include data and information analysis, audit support, technical analysis, update training, communication and systems documentation, on an as needed basis.

Work Area 3 – The contractor must complete transforming SOAR from legacy platform to a new transformation technology stack. Transformation includes approved functionality in the legacy environment (i.e., there is no requirement to transform functionality that is no longer deemed relevant or useful) as well as enhancements that are standard Transformation paradigms and additional improvements as may be accommodated under approved budgets. The contractor must also create new training, communications, system, and security documentation as needed. When a project completes in this Work Area, it is transferred in its entirety to Work Area 2 and becomes part of operational SOAR.

NOTE: The contractor must not provide programmatic input to specific policy or guidance in the fulfillment of the organization's mission. Nor can the contractor perform inherently governmental functions.

PART II

C.2.1 TECHNICAL OBJECTIVES

This section outlines the technical and business objectives by Work Area. The order in which these objectives are presented does not infer program priority or importance. Readers should review the List of Deliverables (Section J – S-7 SOO Artifacts Workbook Tab 8) for an understanding of required documentation/deliverables associated with each of the work areas.

C.2.1.1 PROGRAM MANAGEMENT (Work Area 1)

This area includes transition, program, and staff management.

Objectives:

• Key staff are fully on-boarded with the exception of government furnished equipment (GFE) within 10 daysiii of contract award.

• All other positions proposed or later added are fully staffed within 15 days of resume approval by the Contracting Officer, exclusive of delays due to governmental processes.

• Knowledge transfer is sufficiently complete to allow new staff to independently perform their duties within 45 days from award of contract, not including functions that are delayed due to GFE provisioning.

• Documentation and orientation artifacts are verified and/or updated during the transition or knowledge transfer period as agreed to or defined by Contracting Officer Representative (COR).

• Labor categories, if applicable, are sufficiently defined to facilitate COR review for compliance and ensure skills necessary under the scope of this solicitation.

• The Program Manager is able to start guiding the team to align with a strategic vision for SOAR in the context of ARP-wide Information Technology (IT) within 90 days from contract award.

The contractor must provide support to enable a seamless transition of responsibilities from the current contractor at the onset of contract, transition-out at the end of contract, as well as transition required by staffing changes throughout the life of the contract. As part of this effort the contractor must provide transition planning to effect a timely transition of knowledge and responsibilities (See Section J – S-7 SOO Artifacts Workbook Tab 8 List of Deliverables). This transition planning must not cause an interruption of service and must protect and preserve data integrity, including access to contractor-site project data and artifacts. If unable to overlap transition with government fiscal year, the contractor must independently perform a simulated year end exercise during the transition period. The contractor must provide a detailed transition plan showing the specific tasks and milestones for transition-in and transition-out activities. The contractor must perform transition service and tasks necessary to ensure an effective transition-in and transition-out of contractor support and continued system operations and maintenance.

The contractor must support the requirements of staff and sub-contractor on- and off-boarding throughout the life of the contract in a manner consistent with FAA policies and procedures included in the contract and as revised through the life of the contract. The contractor is responsible for keeping current on the evolution of FAA policy (e.g., security policy, training policy, GFE and travel policy affecting contractors, on- and off-boarding procedures) though FAA intranet postings and email announcements.

The SOAR Program Management Plan (PMP) must encompass all relevant processes and include transition and staff management. Program management services must also include integrated master schedules or action items or plans, budgetary forecasting assistance, and other cross-program, medium or long-term planning needs.

Additionally, the contractor must designate a single key individual to oversee all work and contractor’s personnel and any subcontractors or vendors under this contract. Other activities that the designated individual must be responsible for include: program planning, quality control/assurance, project tracking and reporting, risk identification and management, and knowledge sharing/communication across work areas.

C.2.1.2 MAINTAIN AND OPERATE SOAR ENVIRONMENTS (Work Area 2) This work area covers all environments and full life-cycle support for SOAR. This section focuses primarily on system and database administration, monitoring, and maintenance.

Objectives:

• Develop and provide metrics documenting the extent to which non-functional requirements are fulfilled

• Reduce time to implement standard services through improved understanding of AIT processes and services or other methods

• Improve system monitoring and communications to achieve zero user reported outages in Production, except where attributable to non-SOAR components (e.g., FAA network, MyAccess)

• Maintain a reliable bench of subject matter experts (SMEs) for recurring tasks that do not require full time resources so that contractors can build program and system knowledge over time

The contractor must operate and maintain SOAR in all environments, potentially in parallel with developing new functionality (see C.2.1.4) and SOAR Transformation (see C.2.1.8). The contractor must provide services to support, maintain, and operate SOAR system, databases, and interconnections.

[Note: In some cases, system maintenance may be provided by other organizations (e.g., AIT, AWS). In these cases, the contractor must communicate and track problem resolution with the proper organization.]

System maintenance and support includes monitoring system operations, troubleshooting and repair, administering system services, maintaining asset, coordinating with the COR (or other designated buyer) on budgeting and purchase of existing and new assets, addressing and correcting system issues, incorporating new functionality resulting from congressional mandate or governmental policy changes (e.g., security, privacy).

The contractor must deliver operations and maintenance services in a manner consistent with FAA AIT policies and guidance and within the bounds set in SOAR Functional and Non-Functional Requirements (see Section J – S-7 SOO Artifacts Workbook Tabs1a and 1b, respectively). Tab 1c also provides a site map to give operational context for functional requirements.

See also Section J – S-7 SOO Artifacts Workbook Tab 6 for descriptions of current environments and current assignment of maintenance responsibilities.

Some examples of infrequent tasks include:

Training support – SOAR may require maintenance and updating of training tools such as videos, quick reference guides, or step-by-step instructions. The contractor must provide resources to elicit requirements, design, develop and deliver training and knowledge building materials. The contractor must maintain and deliver applicable training aids in order to help users quickly become familiar with SOAR modules, made accessible on the internet by applying Web technologies. Tasking may also support logistics plans, presentations and training delivery for SOAR, other systems or ARP program components.

Communications support – SOAR has established patterns of communication through release notifications that ARP wishes to continue in the future. While many of these materials are written by ARP staff, contractor support ranges from first draft to simple formatting final product. Other communication products, for SOAR or other needs, might include briefings, graphics, draft articles, and technical or non-technical editing. The contractor must provide resources to fulfill communication needs.

Technical analysis and evaluation – SOAR, in particular, has made a commitment to reassess the technology stack on a periodic basis to avoid obsolesces and evaluate potential benefits from new technologies. Tasking could also be ad hoc, driven by a new requirement or tool that may have broader use across ARP or the enterprise. The contractor must provide resources to develop evaluation methodology and criteria, survey technology options, and assess the applicability and benefits for SOAR or other uses.

Comment Collector support – The ARP Business Plan Comment Collector resides inside the SOAR system boundary. F&I was designed to prove code reusability within the ARP environment, and was subsequently adopted to facilitate exposing the ARP business goals to our staff and obtain feedback for the purposes of refining goals and target due dates. Activities for the next fiscal year typically start in June or July, with data being loaded in August or September for comments. It is not unusual to have a few change requests and one or two deviations to data extracts from Spire (the agency Business Plan reporting system) each year. Once employee’s input their comments, the system is shut down except for goal lead access. Goal Leads typically have a week to respond to feedback and make changes to target descriptions. The system is reopened for a few weeks after the plan is finalized so that users can see feedback to their comments. The contractor must support the Comment Collector, and perhaps subsequent reuse of F&I that does not conflict with the SOAR security status.

C.2.1.3 MANAGE SYSTEM CHANGE AND CONFIGURATION (Work Area 2) This section focuses on managing software changes and deployments, system configuration settings, and other related services. It includes system and database administration, project management, release and ad hoc deployments, and other services. In addition to requirements outlined in each section for Work Area 2, the contractor must provide project schedules, burn down charts, or other methods of determining milestones and deliverable dates necessary for overall program management.

Objectives:

• Provide metrics to show the extent to which approved change requests and system defects are addressed within timeframes defined by contractor and agreed to by SOAR System Owner and/or CCB

• Track and manage SOAR configuration in a method that allows roll back and does not reintroduce deprecated code/function

• Track and manage SOAR technology stack to adopt new product versions at least six months prior to start of end of life as described in FAA technology roadmap, unless timeframe is excepted by System Owner and COR

The contractor must provide Change and Configuration planning, management and control throughout the life cycle of system operations, maintenance or development services. Change and configuration management practices must transition as currently provided under the SOAR Configuration

Management Plan (CMP). However, the contractor may provide alternatives plans and tools or provide improvement suggestions or plans that reflect best practices, improve services, or reduce costs. Change to the CMP is subject to System Owner and COR acceptance of a formal plan and schedule and must, at a minimum, support the following configuration areas.

• Network topology and addresses

• Component models, inventory IDs, specifications, locations, and system owners

• Source codes, scripts, database schemas, canned queries and reports, application programming interfaces, external interfaces

• Backup and recovery plans

• Continuity of operations plans

As part of providing change and configuration management services, the contractor must provide secretariat services to the CCB and Reports Management Board (RMB) (see Section J – S-7 SOO Artifacts Workbook Tab 5).

C.2.1.4 SOAR APPLICATION CHANGE MANAGEMENT (Work Area 2) This section focuses on managing software changes after CCB/RMB approvals, to include work such as requirements or user story documentation, design, development, testing, deployment and documentation updates. Work overlaps with Change Management, but is distinct in that this deals specifically with managing the CCB/RMB approved changes through the development life-cycle to affect changes to data, reports, code and to ensure testing and deployment.

Objectives:

• Establish baseline, metrics, and monitoring for communications and reporting for all approved CCB requests

• Reduce backlog of approved items (not including deferred due to transformation) by 20 percent in first year of contract, and 30 percent per year thereafter

Currently, operational SOAR is changed through CCB or RMB review and approval of user submitted findings and ideas. Once given board approval, the contractor must meet with the Business Lead or designee if there are questions of priority conflicts and immediate needs. Changes are addressed depending on priority and time of year. This practice, coupled with the large number of defects, data issues, and new mandated functionality, results in a large backlog of aging requests. Additionally, the current processes do not provide data (e.g., frequency of occurrence, root cause analysis or potential cost) needed to make sound business decisions regarding application changes.

The contractor must propose changes to current tracking tools, integration methods, meetings or other processes needed to achieve objectives. In addition, the contractor must assess, define and obtain approval as needed to ensure that design/development meets change request or fully addresses the defect. The contractor must confirm user acceptance based on user testing by the Findings and Ideas (F&I) submitter, CCB member, or Business Lead or designee. Deployment must be scheduled and approved with the Business Lead or System Owner or designee.

C.2.1.5 REPORTING AND BUSINESS INTELLIGENCE (BI)

This section, continuing Work Area 2, focuses on reporting and business intelligence outputs. Changes to existing reports can be necessitated due to application changes or developed as part of new or replacement functionality under Work Area 3, Transformation. Reporting/BI is included as a separate section to stress the importance of data and information output and the need to ensure accuracy and validation of externally provided data sources and outputs.

Objectives:

• Allow user access to all SOAR data including historical data and transaction information, unless specifically excluded by SOAR Core Team, through the Data Exploreriv by Fiscal Year End 2024

(FYE)

• Establish baseline, metrics, and monitoring for communications and reporting for all approved RMB activities

• Retire/decommission all legacy reports code no later than calendar year end 2026

• Develop a strategy for integrating external data for SOAR reports versus providing SOAR data for external use in conjunction with the ARP Alteryx team and the RMB so there is identifiable responsibility and ownership for data use and a method to retire unused reports going forward.

Data and information analysis – Despite best efforts at providing reports, Tableau workbooks with drill down capabilities, and ad hoc query tools, there is an ongoing and recurring need to answer public, industry and congressional inquiries. This need may focus only on SOAR data or may span other system data. It may spawn a need to add easily accessible and reproducible reports or may fulfill a one-time query. The contractor must provide resources to work with an identified tool and data set or, perhaps, collect and organize data, to present the requested information.

Data analysis and entry – There are a variety of situations that result in the need to consolidate data via spreadsheet or other reporting mechanism only to have that data need to be entered into a system or systems at a later point. Sometimes this can be done via automated tools such scripting or Robotic Automation Tools (aka BOTS), but sometimes it requires analyzing and potentially correcting the data prior to or during entry. The contractor must provide resources to perform analysis and entry tasks such as, grant close out, matching fund processing, and contact information.

C.2.1.6 HELPDESK (Work Area 2) This section, continuing Work Area 2, focuses on helpdesk aspects of operational support.

Objectives:

• Reduce the frequency of SOAR helpdesk support through improvements in application functions and self-help tools

• Improve delivery of helpdesk for just in time response to time critical items

• Improve transparency of helpdesk to SOAR management team

Currently, users contact the SOAR helpdesk by a group email box or by phone to contractor providers.

Help requests are also received via Team chat, email, and phone to members of the SOAR Core Team.

Sometimes these communications are forwarded to the SOAR helpdesk, other times they are resolved by ARP staff or communicated directly with the contractor staff who can respond immediately, and sometimes the user is asked to enter into F&I. While helpdesk logs are provided after the fact on a monthly basis, the SOAR Core Team has little or no insight into help tickets and handling. Additionally, there is no feedback loop, aside from ARP SOAR Core Team observation, to improving SOAR or SOAR related materials as a method of reducing helpdesk dependencies.

A key tenet of SOAR Transformation is built in functions for user configuration and feature management, so that the need for contractor support for frequent requests is reduced/eliminated. Nevertheless, there is a need to continually look at both defects and requests for support to provide insights into changes that could improve user experience and reduce support inquiries.

The contractor must analyze and assume the current level of helpdesk support and must provide suggestions for reducing or eliminating frequently occurring requests. The contractor must use a ticket tracking system (F&I is option) to intake, log, and track all tickets through resolution. The contractor must respond to ticket requests which can include issues such as: system error messages (i.e., 500 or 404 errors), system access problems and application defects, SOAR error messages, permissions, data issues, and performance issues.

C.2.1.7 SECURITY COMPLIANCE (Work Area 2) This section, continuing Work Area 2, focuses on system security. While patching and configuration management may deploy and monitor security related configuration items, this section is focused on scanning and compliance activities as well as security-specific application changes (such as changing authentication methods or implementing new security tools).

Objectives:

• Provide metrics to show the extent to which SOAR resolves Plan of Action and Milestones (POA&Ms) and vulnerabilities within the government prescribed timeframes

• Remove all code-based vulnerabilities within 12 months from contract award

• Reduce the number of open POA&Ms by at least 50% per year during the first three years of contract, and by 70% per year thereafter, with none aging beyond targeted timeframe

The contractor must support monthly scans from the Security Operations Center (SOC), scan findings from Department of Homeland Security (DHS), and support a minimum of two, maximum of four continuous security assessments or audits provided by third party agencies or contractors. Support tasks include attending meetings, providing monthly briefings, reviewing scan logs and addressing findings, responding to audit requests for information, maintaining or providing input into schedules, scheduling scans, updating security and system documentation required for assessments, and other tasks as may be required to identify, remediate, and report on security vulnerabilities. The contractor must maintain and keep current all required security related documentation defined by the governmental policy.

Audit support – As with all federal programs, ARP programs undergo regular and ad hoc audits. Support services for regular auditing is generally covered by focused contracts. However, occasionally there is an unplanned audit that requires significant effort to coordinate and collect data. The contractor must provide resources to support ARP in responding to audit requests such as devising methods for data collection, coordinating meetings, and analyzing data requirements.

C.2.1.8 TRANSFORM LEGACY SOAR (Work Area 3) This work area is focused on transforming and deprecating/decommissioning all legacy SOAR code from SOAR, including reports but with the possible exception of database components and some interconnections. Since work on transformation continues through the end of the current contract, the exact status of remaining modules and code is not exact. However, the intent is to have no “in flight” code at the time of transfer. (See Section J – S-7 SOO Artifacts Workbook Tab 1a where blue color coded indicates remaining modules and Tab 7 for high level process description currently used for SOAR Transformation projects.)

Objectives:

• Complete SOAR Transformation by calendar year end 2026

• Maintain number and severity of post-production release corrective maintenance items to work that can be accomplished in no more than two week sprint

• Reduce the need for existing cuff records by at least 20 percent through Transformation

• Retire/decommission all remaining legacy code no later than March 2027

• Retire/decommission transformation focused environments

• Develop a reliable bench of subject matter experts (SMEs) for recurring tasks that do not require full time resources so that contractors can build program and system knowledge over time

The contractor must have the understanding of ARP programs, capacity and skills to provide requirements/user story definition, design, development, configuration management, testing, and iterative deployments. Unless specifically approved by the SOAR Core Team, the contractor must follow existing transformation application standards, design and development guidelines, technology stack, configuration management and other applicable practices currently used for Transformation. The contractor must demonstrate ability to utilized established Agile-like methodology as adopted for SOAR Transformation. However, the contractor may propose modifications or changes to the processes and tools provided such change does not negatively impact objectives and offers benefits to the transformation outcomes or costs and resource use.

The contractor must develop a high level schedule to complete the remaining modules; modules may be undertaken concurrently given the availability of ARP staff. The contractor must identify and document risks and contingency plans prior to pilot deployment in the event that the pilot is not successful outlining corrective action plans for the project, if necessary and the contractor must coordinate with Work Area 1 for overall program management.

Some examples of infrequent tasks include:

Training support –SOAR Transformation may require development and delivery of training tools such as videos, quick reference guides, or step-by-step instructions. The contractor must provide resources to elicit requirements, design, develop and deliver training and knowledge building materials. The contractor must develop and deliver applicable training aids, such as demonstration videos, reference guides, and step-by-step procedures, in order to help users quickly become familiar with SOAR modules, made accessible on the internet by applying Web technologies. Tasking may also support logistics plans, presentations and training delivery for SOAR, other systems or ARP program components.

Communications support –SOAR Transformation has established patterns of communication through release notifications that ARP wishes to continue in the future. While many of these materials are written by ARP staff, contractor support ranges from first draft to simple formatting final product. Other communication products, for SOAR or other needs, might include briefings, graphics, draft articles, and technical or non-technical editing. The contractor must provide resources to fulfill communication needs.

C.2.2 QUALITY OF PERFORMANCE

C.2.2.1 Monitoring Performance

C.2.2.1.1 During the life of the contract, the contractor must monitor the system operations, development, configuration management, change management, security and all facets of system life cycle to assure that the quality of services and materials used is adequate to meet the objectives established by agreed on quality performance measures. (See Section J – S-7 SOO Artifacts Workbook Tab 8 Example Quality Assurance Surveillance Plan.)

C.2.2.1.2 Maintain control of cost to ensure that annual budgetary estimates are not exceeded and provide mid-course adjustments if needed to maintain service levels within cost constraints.

C.2.2.1.3 Provide metrics for task categories as proposed or agreed to post award. Example metrics are included in Section J – S-7 SOO Artifacts Workbook Tab 9 Sample Metrics. The contractor may propose modifications or additions to these measures in the best interest of achieving the objectives and monitoring performance.

C.2.2.1.4 The Offeror must provide a Quality Control Plan (QCP) detailing the methodology the Contractor will use to assure services, including deliverables, are satisfactorily (as a minimum) provided.

The QCP must be provided as an attachment to the proposed QASP and must be updated as applicable through the life of the contract.

C.2.2.2 Improving Performance

C.2.2.2.1 The contractor must act to improve or eliminate errors resulting from system failure or process gaps.

C.2.2.2.2 The contractor must meet with the COR and SOAR Core Team at least quarterly regarding updating, changes or modifications of materials presented. However, no changes involving additional cost to the Government shall be made except pursuant to the changes clause of the contract.

C.2.3 CONTRACTOR-FURNISHED MATERIALS (CFM)

The contractor must provide the professional services of experts and related support services to development and system support for SOAR consistent with the proposed labor categories. There is no requirement for contractor-furnished materials. However, if the contractor proposes such materials (e.g., development and unit test environments, development support software, proprietary studies) they must be clearly identified in the PWS and Price Proposal.

C.2.4 GOVERNMENT-FURNISHED PROPERTY AND SERVICES (GFE or GFI) The government will furnish the following:

1. SOAR environments within the FAA as described in Section J – S-7 SOO Artifacts Workbook Tab 6 Current Environments

2. Laptops for all contractor staff requiring direct access to FAA resources, SOAR and other systems

3. SOAR and related system source code

4. Required commercial software licenses running within the FAA environment only

5. Life cycle and security documentation in “as is” state at end of current contract

6. Data in “as is” state for both historical and current system work (e.g., Jira tickets, project schedules)

C.2.5 MEETINGS AND TRAVEL

The contractor point of contact must meet with the COR and SOAR Core Team in person or by video conference at least quarterly for status and planning purposes. There is no requirement for the contractor to provide services at government sites, however, the government may require travel on a reimbursable basis, see Section L for further instructions.

Contractors are responsible for staff onboarding including obtaining access to FAA systems and procedures, coordinating with the COR.

i There is a current POA&M and an intent to adopt FAA two factor solution for external systems for AEP.

ii SOAR refers to both internal and external subsystems unless otherwise stated or when referenced in conjunction with AEP.

iii See section H.13 for definition of Days.

iv Data Explorer is a menu selection within SOAR that accesses SOAR Tableau server and allows users to create, explore and view data sets and workbooks for the purpose of ad hoc or specialized needs. Data Explorer is not intended to duplicate Reports and Workbooks within the SOAR application.

The contractor must analyze and assume the current level of helpdesk support and must provide suggestions for reducing or eliminating frequently occurring requests. The contractor must use a ticket tracking system (F&I is option) to intake, log, and t...