NWP Section C.docx

DOCX document 193 KB Posted

Attached to
Request for Information - Brand New Air Traffic Control System
Solicitation number
693KA7BNATCS
Issued by

About this file

This document is a Statement of Work (SOW) for the NextGen Weather Processor (NWP) contract for the Federal Aviation Administration (FAA). The contract focuses on developing and implementing a new weather processing and display system to improve aviation weather information capabilities, with the primary goal of transforming the National Airspace System (NAS) by providing more accurate, timely, and precise weather products to air traffic management professionals.

The contract involves designing, developing, testing, and deploying two key components: the NextGen Weather Processor (NWP) and the Aviation Weather Display (AWD). The base period is 4 years, with six potential 1-year option periods. Key deliverables include software and hardware development, system integration, test and evaluation activities, configuration management, security implementation, human factors engineering, and transition training. The contractor will be responsible for implementing the system at multiple FAA facilities, including Air Route Traffic Control Centers in Atlanta, Salt Lake City, Chicago, Washington, Cleveland, and Minneapolis, with a focus on improving weather-related air traffic routing, airport capacity, and overall aviation safety by providing enhanced meteorological information and display capabilities.

View the file

Other files

File Type Posted
Notice 6.18.25.pdf PDF
BNATCS Industry Day Attendees.docx DOCX document
BNATCS Industry Day videos.docx DOCX document
Industry Day 2 Briefings.pdf PDF
Industry Day 1 Briefings.pdf PDF
RFI System Providers 1.docx DOCX document
Question for one on ones 6.6.2025.docx DOCX document
2025.06.05 Industry Day Agendas.docx DOCX document
STARS Section C.docx DOCX document
RFI Brand New ATC System A1.docx DOCX document
TFDM Section C.docx DOCX document
ETR Section C.pdf PDF
TBFM Section C.pdf PDF
ILS-420 Section C.pdf PDF
ALSF -2 SLEP SOW 5-28-25.pdf PDF
DNTS Section C.pdf PDF
IVSR Section C.pdf PDF
VSBP Section C.pdf PDF
DME Contract Section C_P18 Final.pdf PDF
CTD Section C_AMEND 0001.docx DOCX document
MEVA 3 NetworkSection C.pdf PDF
TFM2 Section C.pdf PDF
ETVS RDVS STVS Section C.pdf PDF
SMR4 Section C ASDE-3 SMR Replacement.pdf PDF
CSS-Wx Section C.docx DOCX document
STARS Section C.docx DOCX document
APCS Section C.docx DOCX document
ASSC Section C.pdf PDF
DCIS Section C Award Mod 0143.docx DOCX document
NEXCOM Section C.docx DOCX document
RFI Brand New ATC System.docx DOCX document
WSIC Section C.pdf PDF
E-IDS Section C.docx DOCX document
EIS Section C.pdf PDF
MSBRS Section C.pdf PDF
CCS-W Bridge Section C.pdf PDF
MCT SECTION C.pdf PDF
NVR Section C.pdf PDF
FENS Section C.docx DOCX document
AIMMS2 Section C.pdf PDF
WMSS3 Section C.docx DOCX document
NEXCOM V2 Section C.pdf PDF
RVR Section C.pdf PDF
ERAM Section C.docx DOCX document
Show all 44

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

DTFAWA-15-D-00004

Option Year 3+ Mod P00052 October 2022

Federal Aviation Administration

NextGen Weather Processor

Option Year 3+

Part I, Section C: Statement of Work

Federal Aviation Administration 800 Independence Avenue, SW

Third Party Proprietary - Need to Know

Third Party Proprietary - Need to Know

Washington, DC 20591

Export Controlled – See Sheet 1

Page C-2

Third Party Proprietary - Need to Know

THIS PAGE INTENTIONALLY LEFT BLANK

Page C-1

TABLE OF CONTENTS

C.1 Introduction9
C.1.1 Purpose9
C.1.2 Background9
C.1.3 Mission Need9
C.1.4 NextGen Weather Processor10
C.1.5 Aviation Weather Display10
C.2 Applicable Documents11
C.2.1 FAA Specifications and Standards11
C.2.2 FAA Orders11
C.2.3 Other FAA Documents12
C.2.4 Other Government Documents13
C.2.5 Industry Standards14
C.2.6 Availability of Documents14
C.3 Government-Furnished Information, Data, and Services15
C.3.1 Software15
C.3.2 Telecommunications15
C.4 Scope of Work15
C.5 Task Orders16
C.6 Period of Performance16
C.7 Place of Performance16
C.8 Requirements16
C.8.1 Program Management16
C.8.1.1 Program Management Organization and Coordination17
C.8.1.2 Quality Management17
C.8.1.3 Earned Value Management System17
C.8.1.4 Monitoring and Reporting17
C.8.1.5 Program Reviews and Conferences17
C.8.1.5.1 Post Award Conference18
C.8.1.5.2 Integrated Baseline Review18
C.8.1.5.3 Program Management Review19
C.8.2 Systems Engineering and Design19
C.8.2.1 Systems Engineering Management19
C.8.2.2 System Requirements Analysis20
C.8.2.3 Interface Requirements Analysis and Design20
C.8.2.4 System Architecture Definition21
C.8.2.5 Software Design and Development21
C.8.2.5.1 Software Development Plan21
C.8.2.5.2 Software Design22
C.8.2.5.3 Open Source Software Verification22
C.8.2.5.4 Software Testing22
C.8.2.5.5 Software Quality Measurement23
C.8.2.5.6 Software Products and Deliverables23
C.8.2.6 Hardware Selection23
C.8.2.7 NDIs and COTS Hardware and Software24
C.8.2.8 Technical Reviews24
C.8.2.8.1 Combined System Review24
C.8.2.8.2 Preliminary Design Review25
C.8.2.8.3 Critical Design Review26
C.8.2.8.4 Software Build Reviews26
C.8.2.8.5 Standard System Design Reviews27
C.8.3 Test and Evaluation27
C.8.3.1 Test Process28
C.8.3.2 Formal Test Activities31
C.8.3.2.1 Formal Test Entrance Criteria31
C.8.3.2.2 Formal Test Exit Criteria32
C.8.3.3 Contractor Master Test Plan33
C.8.3.4 Test Plans and Procedures33
C.8.3.5 Test Readiness Review33
C.8.3.6 Pre-Test Briefing34
C.8.3.7 Test Execution35
C.8.3.8 Test Reports35
C.8.3.9 Post-Test Briefing35
C.8.3.10 Program Trouble Reports36
C.8.3.11 Test Bed Development37
C.8.3.11.1 Factory Development Test System37
C.8.3.11.2 WJHTC Test System37
C.8.3.11.3 Test Tool Accreditation38
C.8.3.12 Contractor-Supported Tests39
C.8.3.13 Maintenance Release Testing (During SW Maintenance Transition Phase)43
C.8.3.13.1 MRT Test Plans and Test Procedures43
C.8.3.13.2 MRT Pre-Test Briefing43
C.8.3.13.3 MRT Test Execution44
C.8.3.13.4 MRT Test Reports44
C.8.3.13.5 MRT Post-Test Briefing44
C.8.3.14 Government Test Meetings44
C.8.4 Implementation44
C.8.4.1 Implementation Planning44
C.8.4.1.1 Site Survey45
C.8.4.2 Equipment Delivery46
C.8.4.2.1 Sites Installed by Contractor46
C.8.4.2.2 Sites Installed by Government46
C.8.4.3 Installation47
C.8.4.3.1 Installation Activities in Operational Facilities48
C.8.4.3.2 Lead Paint Protection48
C.8.4.3.3 Hazard Prevention and Warning48
C.8.4.3.4 Site Clean Up48
C.8.4.3.5 Damages to Facilities48
C.8.4.3.6 Auxiliary Equipment48
C.8.4.4 Reserved49
C.8.4.5 Reserved49
C.8.5 Technical Interchange Meeting49
C.8.6 Configuration Management49
C.8.6.1 Configuration Management Planning49
C.8.6.2 Configuration Status Accounting System50
C.8.6.3 System Documentation50
C.8.6.4 Configuration Audits50
C.8.6.5 Configuration Change Control51
C.8.6.5.1 Change Proposal and Notices51
C.8.6.5.2 Configuration Control Board52
C.8.7 Security52
C.8.7.1 Information System Security52
C.8.7.1.1 Access Control52
C.8.7.1.2 Audit53
C.8.7.1.3 Security Configuration Management53
C.8.7.1.4 Identity Management54
C.8.7.1.5 Media Protection54
C.8.7.1.6 System and Communication Protection54
C.8.7.1.7 System and Information Integrity55
C.8.7.2 Security Authorization Program55
C.8.7.3 Security Training56
C.8.8 Human Factors Engineering57
C.8.8.1 HFE Program57
C.8.8.2 HFE Design Approach Documents57
C.8.8.3 HFE Reviews57
C.8.8.4 HFE AWD Displays57
C.8.9 Environmental, Occupational Safety and Health58
C.8.9.1 EOSH Program Plan58
C.8.9.2 EOSH Training58
C.8.9.3 Use of Protective Equipment59
C.8.9.4 Program Documentation59
C.8.9.5 Hazardous Materials59
C.8.9.6 Hazard Identification59
C.8.10 Safety Risk Management59
C.8.11 Integrated Logistics Support60
C.8.11.1 ILS Planning60
C.8.11.1.1Logistics Management Information60
C.8.11.2 Provisioning Conference61
C.8.11.3 Technical Documentation61
C.8.11.4 Reliability, Maintainability, and Availability62
C.8.11.5 Reserved63
C.8.11.6 Reserved63
C.8.11.7 Maintenance63
C.8.11.7.1 Software Maintenance63
C.8.11.7.2 Hardware Maintenance64
C.8.11.7.3 Maintenance Reporting64
C.8.11.7.4 Reserved64
C.8.11.7.5 Reserved64
C.8.11.7.6 Bar Code Asset Tracking System64
C.8.11.7.7 On-Site Contractor Support65
C.8.11.8 Transition65
C.8.11.8.1 Depot Support Transition Plan65
C.8.11.8.2 Software Transition Plan65
C.8.11.8.3 Transition Technical Data Package66
C.8.11.8.4 Transition of Supply Support66
C.8.11.9 Transition Training69
C.8.11.9.1 Training Development69
C.8.12 Reserved74
C.8.13 Cloud Migration Services74
C.8.14 Engineering Support Services74
C.8.14.1 Additional Systems74
C.8.14.1.1 NWP System Extension74
C.8.14.1.2 Additional NWP Support System75
C.8.14.1.3 Additional AWDs75
C.8.14.2 Equipment Relocation75
C.8.14.2.1 Relocation of Equipment within the Same Facility75
C.8.14.2.2 Relocate Equipment to Other Facilities75
C.8.14.3 Mobile Display Application75
C.8.15 NWP Enhancement 176
C.8.15.1 Additional Types of NWP Input Data76
C.8.15.2 NWP Geographic Coverage Areas76
C.8.15.3 Additional NWP Products76
C.8.15.4 NWP Algorithm Refinement76
C.8.15.5 AWD Software Enhancements76
C.9 ACRONYMS77

Table of Tables

Table 1: DT Activities27
Table 2: Test Readiness Criteria33
Table 3: Contractor-Supported Test Activities38
Table 4: Maintenance Release Test (MRT) Activities41
Table 5: Integrated System Implementation Milestones43
Table 6: Transition Training69

THIS PAGE INTENTIONALLY LEFT BLANK

Option Year 3+ Mod P00052

Page C-9

C.1 Introduction C.1.1 Purpose This Statement of Work (SOW) sets forth the requirements for the Next Generation Air Transportation System (NextGen) Weather Processor (NWP) contract.

C.1.2 Background Delays in the National Airspace System (NAS) are primarily attributable to weather. Based on Operations Network, which is the official source of NAS air traffic operations and delay data, 68 percent of air traffic delays over 15 minutes for 2003-2012 were due to weather. In addition 73 percent of delayed flights and 86 percent of delay minutes for CY 2010-2012 have weather as the primary cause. Weather also impacts NAS safety. Weather was cited as a cause or factor in over 20 percent of the accidents investigated by the National Transportation Safety Board (NTSB) in 2007-2009.

Air traffic delays due to weather are compounded because most NAS decision tools (both manual and automated) do not utilize weather information effectively, or at all. The aviation weather processing infrastructure and capabilities are inadequate to meet the needs of Air Traffic Management (ATM), Decision Support Tools (DSTs), and operational decision makers. Existing aviation weather products lack the spatial resolution and time accuracy needed for decision making relative to key weather phenomena that impacts aviation. Also, current legacy software is inefficient, difficult to modify, and unable or incompatible to serve users across multiple domains.

Due to these concerns, the Federal Aviation Administration (FAA) has begun implementing a multi-agency (e.g., National Oceanic and Atmospheric Administration (NOAA), Department of Defense (DoD)) initiative called NextGen in order to transform the NAS into a flexible air transportation system that will support improved safety, efficiency, and capacity needs. By 2025, the demand for airline services is expected to double, producing capacity constraints that are significantly greater than those experienced today. The NextGen vision is to provide performance-based operations with an infrastructure that supports trajectory-based operations, high-density operations, collaborative ATM, and NextGen aviation weather capabilities.

C.1.3 Mission Need The FAA has identified a need for more accurate, timely, and improved weather information. To address this need, the FAA and NextGen created the NWP program to establish a common weather processing platform that functionally replaces the legacy FAA weather processor systems and hosts new capabilities. The NWP solution will also access the latest FAA and NOAA weather information and use sophisticated algorithms to create highly accurate, aviation-specific, weather products. The Common Support Services - Weather (CSS-Wx) System will provide this information to legacy and NextGen user systems including DSTs via the System Wide Information Management (SWIM). The new weather display system, the Aviation Weather Display (AWD), will replace legacy weather displays and provide enhanced display capabilities.

C.1.4 NextGen Weather Processor NWP transforms meteorological weather information, including forecast model data, into aviation-specific weather information. These enhanced capabilities produce greater situational awareness relative to the location, movement, and severity of convective weather. Improved weather information, provided by NWP, allows air traffic control specialists to manage air traffic more efficiently around hazardous weather areas.

Once implemented, NWP will ultimately:

· Improve strategic and tactical air traffic routing decisions for Traffic Flow Management (TFM) specialists and en route controllers.

· Provide more effective application of strategic air traffic management initiatives to improve airport capacity.

· Provide a common weather processing platform and infrastructure to improve, consolidate, and assimilate outputs from weather models and real-time sensor data, to produce more accurate aviation weather products.

· Replace and improve the functions of several legacy FAA weather systems and host new, advanced, aviation weather products.

NWP will be implemented in two main program phases. NWP Work Package 1 will encompass near-term capabilities, according to how the Government prioritizes the NWP capabilities. NWP Enhancement 1 will encompass future capabilities. See Attachment J-01, NWP System Specification Document and Attachment J-02, AWD System Specification Document for a more detailed breakdown of the capabilities associated with each program phase.

C.1.5 Aviation Weather Display The AWD will provide weather and aeronautical information through dedicated displays and web technology to internal FAA and external users, respectively. The AWD will improve the situational awareness for users by providing access to aviation weather information. The AWD will be implemented concurrently with NWP Work Package 1.

C.2 Applicable Documents The documents listed in this section are referenced in this SOW. When a referenced document is in conflict with the requirements in this SOW, this SOW takes precedence. If two or more referenced documents are in conflict or two or more sections of this SOW are in conflict, the Contractor must notify the Contracting Officer (CO) to resolve the conflict.

Referenced documents are applicable to the extent specified herein. If applicability is not further specified in the text of the requirement, then the entire document is applicable.

C.2.1 FAA Specifications and Standards

Document Identifier
Document Title
FAA-G-2100H
Electronic Equipment, General Requirements
FAA-STD-002F
Standard Engineering Drawing Preparation and Support
FAA-STD-019E
Lightning and Surge Protection, Grounding, Bonding and Shielding Requirements for Facilities and Electronic Equipment
FAA-STD-021A
Configuration Management (Contractor Requirements)
FAA-STD-025F
Preparation of Interface Documentation
FAA-STD-028C
FAA Standard Contract Training Programs
FAA-STD-026A
Software Development for the NAS System
FAA-D-2494B
Technical Instruction Book Manuscript Guidance: Electronic, Electrical, and Mechanical Equipment, Requirements for Preparation of Manuscript and Production of Books
HF-STD-001
Human Factors Design Standard for Acquisition of Commercial Off The Shelf (COTS) Subsystems, Non-Developmental Items (NDI), and Developmental Systems
HF-STD-004
Requirements for a Human Factors Program

C.2.2 FAA Orders

Document Identifier
Document Title
FAA Order JO 1000.37A
Air Traffic Organization (ATO) Safety Management System
FAA Order 1050.10C
Prevention, Control, and Abatement of FAA Environmental Pollution
FAA Order 1100.161 CHG 1
Air Traffic Safety Oversight
FAA Order 1370.82A
Information Systems Security (ISS) Program
FAA Order JO 1370.96
ATO System Access Control
FAA Order JO 1370.97
ATO Use of Non-FAA Workstations
FAA Order JO 1370.100
Media Sanitizing and Destruction Policy
FAA Order JO 1370.106
ISS Awareness and Training Policy
FAA Order JO 1370.46
NAS Information Security Incident Detection, Reporting, and Response
FAA Order 1370.103
Encryption Policy
FAA Order JO 1370.111
Removable Media Security Policy
FAA Order JO 1370.114
Implementation of FAA Telecommunications Infrastructure (FTI) Services and Information Security Requirements in the NAS
FAA Order 1600.75
Protecting Sensitive Unclassified Information (SUI)
FAA Order 1800.66 CHG 3
Configuration Management Policy
Order 3000.22
Air Traffic Organizations Outcomes – Based Technical Training
FAA Order 3000.57
ATO Technical Operations Training and Personnel Certification Programs
FAA Order 3900.19B
FAA Occupational Safety and Health Program

FAA Order JO 3900.57A

Environmental and Occupational Safety and Health (EOSH) Requirements in the Planning and Execution of Construction and Maintenance Activities at NAS Facilities

FAA Order 3900.63
ATO Fall Protection Program
FAA Order 4600.27B CHG 1
Personal Property Management
FAA Order 6000.15G
NAS General Maintenance Handbook for NAS Facilities
FAA Order 8040.4A
Safety Risk Management Policy

C.2.3 Other FAA Documents

Document Identifier
Document Title
N/A
ATO Safety Management System (SMS) Manual, July 2017
N/A
Fiscal Year 2020 (FY2020) ISS Authorization Handbook
N/A
FY20 ATO System Security Plan Moderate Workbook v1.0_19-1028
N/A
Safety Risk Management Guidance for System Acquisitions (SRMGSA), April 2017
N/A
NAS External Boundary Protection Guidelines
N/A
Technical Operations Safety Risk Management Policy Memorandum of March 2008
N/A
Air Traffic Organization The Technical Training Directorate /Analysis Guide (AJI-2)
N/A
Air Traffic Organization The Technical Training Directorate/Design Guide (AJI-2)
N/A
eLearning Design and Style Guide
N/A
FAA eLMS Content Integration Guide
N/A
Written Test Blueprint_Final
N/A
Performance Test Blueprint_Final
N/A
National Air Traffic Program/Analysis Report
N/A
National Air Traffic Training Program/Course Design Guide (CDG) Template
N/A
Development Guide for Instructor-Led Training Materials
N/A
Training Materials Template V.2019-06

C.2.4 Other Government Documents

Document Identifier
Document Title
29 CFR 1910
Occupational Safety and Health Standards (General Industry)
Federal Information Processing Standards (FIPS) Publication 200
Minimum Security Requirements for Federal Information and Information Systems
National Institute of Standards and Technology (NIST) SP 800-53, Rev 4
Security and Privacy Controls for Federal Information Systems and Organizations
Title III, Pub. L. No. 107-347
Federal Information Security Management Act of 2002

C.2.5 Industry Standards

Document Identifier
Document Title
EIA 649C
Configuration Management Standard
American National Standards Institute (ANSI)/Electronic Industry Alliance (EIA) Standard 748-C
Earned Value Management Systems
ANSI/International Organization for Standardization (ISO)/American Society for Quality (ASQ) Q9001:2015
Quality Management Systems – Requirements
Institute of Electrical and Electronics Engineers (IEEE) Standard 1003.1, 2004 Edition
Standard for Information Technology - Portable Operating System Interface (POSIX)
National Fire Protection Association (NFPA) 70
National Electrical Code
NFPA 70E
Standard for Electrical Safety in the Workplace
NFPA 101
Life Safety Code
Web Map Services (WMS) 1.3
Open GIS® WMS Interface Standard

C.2.6 Availability of Documents

Document Name
Access to Document Information
FAA Documents
Copies of FAA specifications, standards, and publications may be obtained from the CO noted in Section G. Requests should clearly identify the desired material by name and number (when applicable) and state the intended use of the material. Requested copies will be provided in digital format.
Federal Documents
Copies of federal publications may be obtained from the U.S. Government Printing Office, 710 North Capitol Street, Washington DC, 20401, by calling (202) 512-0132, or through the Web site http://bookstore.gpo.gov/.
NIST Documents
Copies of National Institute of Standards and Technology documents may be obtained through the Web site http://csrc.nist.gov/publications/PubsSPs.html.
ANSI Documents
Copies of ANSI documents may be obtained through the Web site http://webstore.ansi.org/.

C.3 Government-Furnished Information, Data, and Services The Government will furnish the information, software code, and software documentation listed in Section J to the NWP Contractor. The Government will provide telecommunications services to support the operation of NWP.

C.3.1 Software The Government will provide software per Attachment J-19, NWP Information - GFI Software and Reference Documents List to the selected vendor after contract award. Use of this software does not relieve the Contractor of responsibility for meeting the requirements in this SOW, in the NWP System Specification Document (SSD), or in the AWD SSD.

C.3.2 Telecommunications The Government will furnish telecommunications and messaging services through the FAA Telecommunication Infrastructure (FTI) programs to support the development and operation of NWP and AWD. The Contractor will be responsible for determining the telecommunication and messaging services needed.

C.4 Scope of Work The scope of work of the NWP procurement consists of the design and implementation of NWP and AWD in accordance with Attachment J-01, NWP System Specification Document (SSD) and Attachment J-02, AWD SSD. It also includes the selection of hardware, the development of software, integration, testing, deployment, and operational support, and maintenance of the system hardware and software. The scope of work also includes additional engineering services as required by the Government.

C.5 Task Orders Some work performed under this contract will be authorized by Task Order. Task orders are allocated to program phases. Attachment J-01, NWP SSD and Attachment J-02, AWD SSD, shows the allocation of requirements to both program phases; Enhancement 1 requirements are in C.8.15.

C.6 Period of Performance The base period of the NWP contract is 4 years. The base period may be followed by six 1-year options, if exercised.

C.7 Place of Performance The Contractor is responsible for providing facilities for the development of NWP and AWD.

The Contractor must implement NWP at the FAA facilities cited in C.8.4.1.1 and C.8.3.11.2. The Government reserves the right to change the selection of these locations as late as the Preliminary Design Review (PDR).

The contractor must install AWDs at the facilities that currently have a legacy weather display as identified in Table B-3 of Attachment J-07, NextGen Weather Systems Description Document.

C.8 Requirements This section contains the requirements for the services performed by the NWP Contractor. Attachment J-04, Contract Data Requirements List (CDRL) contains additional requirements with respect to required deliverables.

C.8.1 Program Management The Contractor must manage the activities, personnel, resources, and subcontracts involved in the performance of the NWP contract so as to mitigate risk, meet requirements, and achieve the program’s schedule milestones. The Contractor must monitor and control the effort in accordance with Government approved work plans and schedules. The Contractor must also provide the FAA with clear, timely, and proactive communication on the status of planned and completed activities. The Contractor must describe their approach to managing the effort, mitigating risk, and delivering high-quality products and services that meet requirements in a Program Management Plan (CDRL PM01).

C.8.1.1 Program Management Organization and Coordination The Contractor must establish a business model that fosters collaborative relationships with the FAA and with other FAA contractors. In particular, the interdependencies of NWP, AWD, and CSS-Wx System, combined with similar implementation schedules, require close coordination between the programs’ vendors from architecture to deployment to increase innovation, optimization, and performance; minimize costs and risks; and integrate and deliver the systems efficiently. The Contractor must designate a Program Manager (PM) to manage, coordinate, and communicate with the Government and other FAA contractors. The PM must have sufficient corporate authority to direct, execute, and control all elements of the program.

C.8.1.2 Quality Management The Contractor must develop and implement a plan for managing the quality of NWP and AWD hardware, software, systems, data items, and services required under this contract in accordance with ANSI/ISO/ASQ Q9001:2015, Quality Management Systems – Requirements. The Contractor must also ensure the quality of the products and services provided by subcontractors and third party contractors. The Contractor must submit a Quality Management Plan (QMP) (CDRL PM02) that describes the Contractor’s plan for managing quality.

C.8.1.3 Earned Value Management System The Contractor must utilize an Earned Value Management System (EVMS) that complies with ANSI/EIA Standard 748-C, Earned Value Management Systems, to plan, control, and report the status of the effort. The Contractor must develop a Contractor Work Breakdown Structure (CDRL PM03) for approval by the Government. The Contractor must submit an Integrated Program Management Report (CDRL PM04) to provide earned value information.

C.8.1.4 Monitoring and Reporting The Contractor must continuously monitor performance under this contract and all subcontracts. The Contractor must develop and maintain a risk database to manage the categorization, reporting, tracking, and resolution of risks identified and documented. The Contractor must provide read only access to the risk database to the Government, thereby allowing the Government to maintain awareness of and generate reports of risks as needed. The Contractor must provide the FAA with an assessment of project progress, risks, issues, and proposed resolutions in a Project Status Report (CDRL PM05).

C.8.1.5 Program Reviews and Conferences The Contractor must plan, host, conduct, and attend meetings and conferences to discuss topics and communicate issues related to this effort as requested by the Government. The Contractor may be required to prepare materials for presentation and distribution prior to meetings and conferences; FAA and the Contractor will mutually agree on agendas prior to the meetings. The Contractor must prepare an agenda prior to a contractor facilitated meeting or conference and submit via email to the FAA. The Contractor must prepare and submit Meeting Minutes (CDRL PM07) for Government approval following a meeting, conference, or review. The Contractor must submit meeting minutes for all Contractor facilitated meetings. The FAA will provide meeting minutes for all FAA facilitated meetings.

C.8.1.5.1 Post Award Conference The Contractor must plan, host, and participate in a post-award conference at the Contractor's facility. The Government will determine the actual date of the post-award conference within 30 business days after the contract start date. The purpose of the post-award conference is for the Contractor and the Government to:

· Reach a mutual understanding of the contract requirements; and

· Review the Integrated Baseline Review (IBR) preparations and EVMS tailoring.

C.8.1.5.2 Integrated Baseline Review The Contractor must plan, host, and participate in an IBR within 6 months of contract award. The purpose of the IBR is to:

· Evaluate the Contractor’s implementation of the performance measurement baseline;

· Ensure that the Government and Contractor mutually understand program scope, schedule, resources, inherent risk, and program management processes;

· Establish a schedule for Program Management Reviews (PMRs);

· Ensure early and adequate planning;

· Identify risks to be tracked; and

· Ensure appropriate reporting levels have been identified and variance thresholds are agreed to by the Government and Contractor.

The Contractor must provide access to the records and data that support the cost and schedule data reported. The Contractor must conduct the IBR until such time as the Government determines that it can be integrated into PMRs. The Contractor may also be required to participate in an IBR within four months of a major design or requirements change that dictates a re-baselining of the program or after major modifications to the contract or after the Government exercises a new contract option. The Government may choose to tailor the IBR to meet the scope of work.

C.8.1.5.3 Program Management Review The Contractor must convene PMRs at least quarterly through the completion of Integration Testing / System Testing to update the Government on the status of Contractor efforts and project milestones. After that, the PMRs will be conducted three times a year. At each PMR, the Contractor must review the project status report with the Government. The Contractor must propose the dates of the PMRs for Government approval. The PMRs will normally be conducted at the Contractor's facility; however, the location of a PMR may be changed through mutual agreement between the Government and the Contractor. PMRs may also be held virtually, through mutual agreement between the Government and the Contractor.

C.8.2 Systems Engineering and Design The Contractor must develop NWP in accordance with Attachment J-01, NWP SSD, which will produce the weather products identified in Attachment J-07, NextGen Weather Systems Description Document. The Contractor must plan and conduct the design and development of NWP capabilities according to Program Phase identified in the NWP SSD .

The Contractor must develop an AWD in accordance with Attachment J-02, AWD SSD. The Contractor must design and develop AWD to display the products identified in the AWD SSD. For all other products identified in the J-02, AWD SSD, but not identified as the Program Phase for Work Package 1, the Contractor must develop AWD to support these products in NWP Enhancement 1.

The NWP software and system design must be scalable to accommodate additional meteorological algorithms, additional geographic locations and an expanded geo-spatial coverage of the generated weather products. The AWD software and system design must be scalable to accommodate increases in the number of dedicated displays and Web browser clients. The AWD software and system design must be scalable to accommodate additional display views and new products.

C.8.2.1 Systems Engineering Management The Contractor must develop and implement a Systems Engineering Management Plan (SEMP) (CDRL SE01) that will establish a systems engineering management program for the definition, design, development, verification, integration, and testing of NWP and AWD requirements. System engineering efforts must consider all aspects of performance, quality, lifecycle cost, maintainability, reliability, schedule, risk, data processing reserves, and future growth requirements.

The SEMP must clearly delineate between AWD, and NWP Work Package 1 capabilities. The SEMP must address how the AWD, and NWP Work Package 1 approach will affect the definition, design, development, verification, integration, and testing of the NWP and AWD requirements.

C.8.2.2 System Requirements Analysis During the base period the Contractor must conduct a System Requirements Analysis, as described in the SEMP, in accordance with Attachment J-01, NWP SSD and Attachment J-02, AWD SSD. The Contractor must assess and refine the A-level requirements in Attachment J-01, NWP SSD and Attachment J-02, AWD SSD and submit a revised NWP System Specification Document (Revision) (CDRL SE02) and AWD System Specification Document (Revision) (CDRL SE03) to the Government.

Throughout development the Contractor must decompose the requirements in the revised SSD to define the lower-level (B-level) requirements of the NWP and AWD, define the functional subsystems and components of NWP and AWD, and allocate the B-level requirements to the subsystems and components. The Contractor must develop a System/Subsystem Specification (CDRL SE04) that documents the allocation of B-level requirements to subsystems and components and demonstrates the traceability of the B-level requirements to the A-level requirements in the NWP and AWD SSDs.

C.8.2.3 Interface Requirements Analysis and Design The Contractor must develop the interface design documents for NWP and AWD listed in Attachment J-05, NWP System Interface Deliverables. The Contractor must develop each Interface Design Description (IDD) (CDRL SE05) in accordance with FAA-STD-026A, Software Development for the NAS. The Contractor must develop each Interface Control Document (ICD) (CDRL SE06) in accordance with the referenced attachment and with FAA-STD-025F, Preparation of Interface Documentation.

The Government will provide the Contractor with the initial Product Description Documents (PDDs) for NWP-generated products within Attachment J-06, NextGen Weather Processor Product Description. The Contractor must review the PDDs provided by the Government and provide feedback, As applicable, in accordance with the original system baseline, the Government will provide the Contractor with Attachments J-48, Draft CSS-Wx / NWP ICD, and J-49, Final CSS-Wx / NWP ICD . The Contractor must review these Interface Control Documents (ICDs) provided by the Government, participate in any relevant Technical Interchange Meetings (TIMs) (two per NWP Build), and incorporate design impacts into the Contractor’s proposed interface design.

The Government will provide the Contractor with Attachments J-63, System Wide Information Management (SWIM) NAS Enterprise Messaging Service (NEMS) Solace ICD and J-65, CSS-Wx Java Messaging Service Description Document (JMSDD). The Contractor must review these documents provided by the Government, participate in any relevant TIMs (quantity 2) and incorporate design impacts into the Contractor’s proposed design.

C.8.2.4 System Architecture Definition The Contractor must define and develop NWP and AWD architecture baselines and allocated baselines. The Contractor must develop a Software Requirements Specification (SRS) (CDRL SE08), Interface Requirements Specification (IRS) (CDRL SE09), and System/Subsystem Design Description (SSDD) (CDRL SE10) that describe all allocated subsystems and segments. The Contractor must document the interrelationships between the system, subsystem, and equipment drawings in an Engineering Drawing Tree (CDRL SE11).

The Contractor must propose a failover procedure, for government approval, that will function with the redundant component concept described in Attachment J-7 NextGen Weather Systems Description Document, Section 2.2 Systems and Operations. The failover procedure may be automated with manual initiation.

C.8.2.5 Software Design and Development The Contractor must, design, code, integrate, install, test, and deliver NWP and AWD software according to the priority set forth in Section 8.2 to meet the requirements of NWP and AWD SSDs and in accordance with FAA-STD-026A, Software Development for the NAS. The Government will monitor software design and development. The Contractor must provide delivery of software artifacts (e.g., design and development source code, scripts, procedures, source code Configuration Management (CM) information, as well as System Architecture (SRS, IRS), Interface (IDD, ICD, PDD), and Software Design (Software Design Description (SDD) content) to the Government. The Government reserves the right to audit the software artifacts at any time.

C.8.2.5.1 Software Development Plan The Contractor must develop a Software Development Plan (CDRL SE12) that describes the Contractor’s plan for designing and developing NWP and AWD software. The Software Development Plan must clearly delineate between AWD, and NWP Work Package 1 capabilities.

C.8.2.5.2 Software Design The Contractor must design, develop, integrate, and document new and modified software in accordance with the Government-approved Software Development Plan. The Contractor must submit a Software Design Description (CDRL SE13) for Government approval. The Contractor must prepare or update all software documentation for developmental and modified software to show how the developmental software is integrated with the non-developmental software in accordance with the Software Development Plan. If any commercial software is used to satisfy requirements, the Contractor must submit corresponding commercial documentation, licensing agreements, and usage limitations to the Government for approval. The Contractor must ensure that the Government has unrestricted access to additional copies of commercial software documentation.

The Contractor must design NWP and AWD software to be hardware platform independent and compatible with the IEEE Standard 1003.1, 2004 Edition, Standard for Information Technology - Portable Operating System Interface (POSIX). The Contractor must develop NWP software and AWD Web display software that can operate on virtualized platform that has been approved by the Government. The AWD, both dedicated and Web implementation must reuse or share software code whenever possible. The Contractor must propose in the software design description the version of the World Wide Web Consortium (W3C) standards that have recommended status for the AWD Web display software, any NDI and Commercial, Off-The-Shelf (COTS) software used for the AWD Web Site.

C.8.2.5.3 Open Source Software Verification The Contractor must identify Open Source Software (OSS) used in the development of NWP and AWD. The Contractor is responsible for resolving any OSS issues that affect performance NWP and AWD.

C.8.2.5.4 Software Testing The purpose of software testing is to verify specifications at the B level (subsystem level). Software testing must address new and modified software decomposed into Computer Software Configuration Items (CSCI), computer software components, and functional design components (i.e., unit testing and software integration testing). The Contractor must conduct software testing at the Contractor’s site or at the William J. Hughes Technical Center (WJHTC) in accordance with the Government-approved Contractor Master Test Plan (CMTP).

The Government will make input and output test point data available to the selected vendor after contract award. The Contractor must conduct a comparison of the NWP output data against the Government provided output test data. The Contractor must supply the NWP output data to the Government, and explain deviations between the NWP output data and Government provided output test data during Technical Interchange Meetings (TIM) prior to Test Readiness Review (TRR).

C.8.2.5.5 Software Quality Measurement The Contractor must measure the quality of NWP and AWD software at the method/function, class, and file level, including shared library routines and weather library routines.

One month after a Standard System Design Review (SSDR), Raytheon will provide a Coverity output to the FAA (non-CDRL).

C.8.2.5.6 Software Products and Deliverables The Contractor must provide the software deliverables for requirements allocation, design, test, quality assurance, delivery, installation, operation, maintenance, and support of each configuration item of the Contractor-developed software. The Contractor must submit the following software deliverables to the Government for review and approval:

· Software Product Specification (CDRL SE15) that contains or references the executable software, source files, and software support information, including "as built" design information and compilation, build, and modification procedures, for a CSCI;

· Software User Manual (CDRL SE16) that describes how to install and use a CSCI, a group of related CSCIs, or a software system or subsystem. It may also cover a particular aspect of software operation, such as instructions for a particular administrative task; and

· Software Version Description (CDRL SE17) that identifies and describes a software version consisting of one or more CSCIs. It is used to release, track, and control software versions.

C.8.2.6 Hardware Selection The Contractor must select the hardware to be used in the system design to meet the requirements in the NWP and AWD SSDs. The Contractor must conduct analysis to justify the proposed hardware approach to the Government. The Government will provide power constraints and weight limitations of the hardware to the Contractor prior to PDR or Standard System Design Review, as applicable.

C.8.2.7 NDIs and COTS Hardware and Software The Contractor must identify NDIs and COTS hardware and software used in the development of NWP and AWD. The Contractor is responsible for resolving any issues associated with the NDIs and COTS items that affect NWP and AWD performance. The Contractor must provide the Government with all applicable licenses and agreements.

C.8.2.8 Technical Reviews The Contractor must plan and participate in technical reviews to obtain approval for NWP and AWD specifications and designs and to provide the FAA with insight into the Contractor’s progress. The Contractor must notify the CO of readiness for a technical review at least 20 business days (i.e., Monday-Friday, excluding Federal holidays) in advance of the planned start date. The Contractor must submit all deliverables required for the review at least 10 business days in advance of the planned start date. At each review, the Contractor must be prepared to present and discuss the content of required data items, the assumptions made, and the methodologies used to arrive at specific designs, plans, recommendations, and conclusions. The Contractor must make qualified personnel available to respond to Government questions.

The Contractor must obtain Government permission to proceed before conducting a technical review. The Contractor must close all action items or obtain Government approval for any open action items prior to conducting a technical review. If the Contractor has not submitted all required documents or if the preceding technical review has not been approved by the Government, the Government can postpone a technical review without prejudice to other contractual requirements. The Contractor must not consider formal reviews complete until the Government has granted approval in writing.

The Contractor must be prepared to conduct Standard System Design Reviews, Combined System Reviews, Preliminary Design Reviews (PDR), Critical Design Reviews (CDR), and Software Build Reviews (SBR) for the AWD, and NWP Work Package 1.

C.8.2.8.1 Combined System Review The Contractor must conduct a System Requirements Review (SRR), System Design Review (SDR), and System Specification Review (SSR) as a single, combined review. The purpose of this combined review is for the Government to:

· Determine whether the system requirements are consistent, achievable, and complete, and whether the Government and the Contractor have a clear, mutual understanding of the system requirements;

· Evaluate the status and maturity of the system design; and

· Evaluate the Software Requirements Specification.

The Contractor must submit an SRR/SDR/SSR Data Package (CDRL SE18) prior to the combined review. During the combined review, the Contractor must be prepared to present and discuss:

· The revised NWP SSD, and the allocation and traceability of requirements from the revised NWP SSD to the preliminary system/subsystem specifications, interface requirements, and configuration items;

· The revised AWD SSD, and the allocation and traceability of requirements from the revised AWD SSD to the preliminary system/subsystem specifications, interface requirements, and configuration items;

· The results of functional analyses, syntheses, and trade studies;

· The Software Requirements Specification;

· The final System/Subsystem Specification;

· The System/Subsystem Design Description;

· The Software Development Plan; and

· Initial comparison of the NWP algorithm output data as it may be impacted by the Contractor’s overall design approach.

C.8.2.8.2 Preliminary Design Review The purpose of the PDR is for the Government to evaluate the Contractor’s system architecture and design approach to determine whether the Contractor is prepared to begin detailed design. Prior to the PDR, the Contractor must submit a PDR Data Package (CDRL SE19). During the PDR, the Contractor must demonstrate how the process used to arrive at the design meets the functional and performance requirements for each configuration item. The Contractor must also demonstrate that the requirements in the functional baseline are traceable to the requirements in the revised NWP and AWD SSDs, IRDs, and PDDs. The Contractor must be prepared to present and discuss the most recent System Design, Software Design, Hardware Design, Human Factors, Telecommunications, Interface Design, Test Plans, and comparison of the NWP algorithm output data as it may be impacted by the Contractor’s overall design approach. At PDR, the Contractor must also provide the Government with the CMTP, Verification Requirements Tractability Matrix (VRTM), and estimated telecommunication requirements for the solution in accordance with Attachment J-08, FTI Operational Network IP Users' Guide.

C.8.2.8.3 Critical Design Review The purpose of the CDR is for the Government to determine whether the Contractor’s detailed design meets the requirements specified in the NWP and AWD SSDs, and whether the design is complete and ready to be implemented. Prior to CDR, the Contractor must submit a CDR Data Package (CDRL SE20). During the CDR, the Contractor must be prepared to present and discuss the final approach for System Design, Hardware Design, Human Factors, Telecommunications, Interface Design, Test Plans, and comparison of the NWP algorithm output data as it may be impacted by the Contractor’s overall design approach. The Contractor must be prepared to present and discuss the current Software Design approach.

In addition, the Contractor must demonstrate that:

· All software requirements are mapped to the build level;

· The detailed designs reflect an architecture that satisfactorily meets the IRDs and PDDs and minimizes risk; and

· The Contractor has analyzed the impact of changes to requirements on the detailed system design, including interfaces.

C.8.2.8.4 Software Build Reviews The purpose of the SBRs is for the Government to determine whether the Contractor’s as-built detailed software design for the software features in the previous build meets the requirements specified in the functional and allocated baselines and is complete and implemented in the software product baseline. Except for Build 7, a SBR must be held after the testing for each NWP build is complete. During each SBR, for features in the as-built design, the Contractor must be prepared to present the build test results, requirements changes identified during sprints, and discuss the detailed software design in the following areas: system/software architecture and design, software interfaces, software CM, adaptation, performance, deployment, design trade-offs, and validation. The Contractor must discuss changes to those areas indicated in SE21 that have been modified since the last review. The Contractor must review test and regression test results from the sprints associated with the most recently completed software build. The Contractor must demonstrate that all software requirements are allocated and traceable to the computer software unit level. The Contractor must demonstrate that the database design is complete and meets all requirements. The Contractor must demonstrate the impact of changes to requirements on the detailed software design. The Contractor must discuss the revised software build plan for all upcoming builds. At each SBR the Contractor must complete updates to all requirement and design documents containing finalized as-built content for all features developed during all prior builds. The Contractor must provide electronic access to changes in software and system requirements and design artifacts in conjunction with each software build.

C.8.2.8.5 Standard System Design Reviews The purpose of the Standard System Design Review (SSDR) is for the Government to determine if system design changes subsequent to CDR meet the requirements specified in the NWP and AWD SSDs, and whether the design is complete and ready to be implemented. Prior to SSDR, the Contractor must submit a Data Package (contractor format) that describes the system design changes and the impacts to baseline design documents such as the System/Subsystem Design Description. During the SSDR, the Contractor must be prepared to present and discuss affected aspects of the NWP or AWD systems such as System Design, Hardware Design, Human Factors, Telecommunications, Interface Design, Test Plans, and Software. The schedule for the delivery of the SSDR Data Package and meeting conduct will be included in the contractor IMS. Delivery of the package must occur at least 5 days prior to the event. The package can be provided via e-mail to the FAA via the CO and Contracting Officer’s Representative (COR) at a minimum.

In addition, the Contractor must demonstrate that:

· The updated design reflects an architecture that satisfactorily meets the IRDs and PDDs and minimizes risk;

· The Contractor has analyzed the impact of changes to requirements on the detailed system design, including interfaces; and

· The Contractor has analyzed the impacts of system design changes to cost and schedule.

In order to receive SSDR approval, the Contractor must perform the following:

· The Review Package must be included with the minutes CDRL and subject to review and approval at that time

· The Review Package must reflect actual changes that are being recommended for the SSDD (SE10) C.8.3 Test and Evaluation The Contractor must establish a test and evaluation program for NWP and AWD consistent with the Government’s Test and Evaluation Master Plan (TEMP) to verify that NWP, AWD, and their components, meet the physical, functional, interface, and performance requirements contained in the NWP and AWD SSDs, referenced IRDs, and referenced Web service requirements documents prior to putting the systems in service.

C.8.3.1 Test Process The Contractor’s test and evaluation program must include the Development Testing (DT) activities described in Table 1. The Contractor must perform DT activities as indicated in the table below to demonstrate that all specified technical and performance requirements have been met.

Table 1: DT Activities

DT Activity
Description
Functional Qualification Testing (FQT)
The purpose of FQT is to verify that the partially integrated hardware and software subsystem components of NWP and AWD, including COTS/modified COTS items and non-developmental items (NDI)/modified NDI, meet NWP’s and AWD’s A-level and B-level requirements. FQT may be conducted at a Contractor facility, subcontractor facility, or at the WJHTC. The Government will witness FQT and will review test plans, procedures, and reports. FQT will be conducted on a Software Build basis, as proposed by the Contractor and approved by the Government, if requirement signoff is intended. The Government will have access to preliminary qualification test activities, plans, procedures, and reports. Preliminary qualification test access data will include product generation statistics including intermediate timing on logical threads, based on the Contractor system design.
Factory Acceptance Testing (FAT)
The purpose of FAT is to verify that NWP and AWD meets NWP’s and AWD’s A-level and B-level requirements including hardware, firmware, COTS items, and non-developmental subsystem components. FAT may be conducted at the Contractor’s facility or at the WJHTC. FAT must include a 48-hour stability test period with the system running with an operational load. The FAA will witness FAT.
Candidate Release Test (CRT)

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated .