NWP Section C.docx
DOCX document 193 KB Posted
- Solicitation number
- 693KA7BNATCS
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
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 Introduction | 9 | |
| C.1.1 Purpose | 9 | |
| C.1.2 Background | 9 | |
| C.1.3 Mission Need | 9 | |
| C.1.4 NextGen Weather Processor | 10 | |
| C.1.5 Aviation Weather Display | 10 | |
| C.2 Applicable Documents | 11 | |
| C.2.1 FAA Specifications and Standards | 11 | |
| C.2.2 FAA Orders | 11 | |
| C.2.3 Other FAA Documents | 12 | |
| C.2.4 Other Government Documents | 13 | |
| C.2.5 Industry Standards | 14 | |
| C.2.6 Availability of Documents | 14 | |
| C.3 Government-Furnished Information, Data, and Services | 15 | |
| C.3.1 Software | 15 | |
| C.3.2 Telecommunications | 15 | |
| C.4 Scope of Work | 15 | |
| C.5 Task Orders | 16 | |
| C.6 Period of Performance | 16 | |
| C.7 Place of Performance | 16 | |
| C.8 Requirements | 16 | |
| C.8.1 Program Management | 16 | |
| C.8.1.1 Program Management Organization and Coordination | 17 | |
| C.8.1.2 Quality Management | 17 | |
| C.8.1.3 Earned Value Management System | 17 | |
| C.8.1.4 Monitoring and Reporting | 17 | |
| C.8.1.5 Program Reviews and Conferences | 17 | |
| C.8.1.5.1 Post Award Conference | 18 | |
| C.8.1.5.2 Integrated Baseline Review | 18 | |
| C.8.1.5.3 Program Management Review | 19 | |
| C.8.2 Systems Engineering and Design | 19 | |
| C.8.2.1 Systems Engineering Management | 19 | |
| C.8.2.2 System Requirements Analysis | 20 | |
| C.8.2.3 Interface Requirements Analysis and Design | 20 | |
| C.8.2.4 System Architecture Definition | 21 | |
| C.8.2.5 Software Design and Development | 21 | |
| C.8.2.5.1 Software Development Plan | 21 | |
| C.8.2.5.2 Software Design | 22 | |
| C.8.2.5.3 Open Source Software Verification | 22 | |
| C.8.2.5.4 Software Testing | 22 | |
| C.8.2.5.5 Software Quality Measurement | 23 | |
| C.8.2.5.6 Software Products and Deliverables | 23 | |
| C.8.2.6 Hardware Selection | 23 | |
| C.8.2.7 NDIs and COTS Hardware and Software | 24 | |
| C.8.2.8 Technical Reviews | 24 | |
| C.8.2.8.1 Combined System Review | 24 | |
| C.8.2.8.2 Preliminary Design Review | 25 | |
| C.8.2.8.3 Critical Design Review | 26 | |
| C.8.2.8.4 Software Build Reviews | 26 | |
| C.8.2.8.5 Standard System Design Reviews | 27 | |
| C.8.3 Test and Evaluation | 27 | |
| C.8.3.1 Test Process | 28 | |
| C.8.3.2 Formal Test Activities | 31 | |
| C.8.3.2.1 Formal Test Entrance Criteria | 31 | |
| C.8.3.2.2 Formal Test Exit Criteria | 32 | |
| C.8.3.3 Contractor Master Test Plan | 33 | |
| C.8.3.4 Test Plans and Procedures | 33 | |
| C.8.3.5 Test Readiness Review | 33 | |
| C.8.3.6 Pre-Test Briefing | 34 | |
| C.8.3.7 Test Execution | 35 | |
| C.8.3.8 Test Reports | 35 | |
| C.8.3.9 Post-Test Briefing | 35 | |
| C.8.3.10 Program Trouble Reports | 36 | |
| C.8.3.11 Test Bed Development | 37 | |
| C.8.3.11.1 Factory Development Test System | 37 | |
| C.8.3.11.2 WJHTC Test System | 37 | |
| C.8.3.11.3 Test Tool Accreditation | 38 | |
| C.8.3.12 Contractor-Supported Tests | 39 | |
| C.8.3.13 Maintenance Release Testing (During SW Maintenance Transition Phase) | 43 | |
| C.8.3.13.1 MRT Test Plans and Test Procedures | 43 | |
| C.8.3.13.2 MRT Pre-Test Briefing | 43 | |
| C.8.3.13.3 MRT Test Execution | 44 | |
| C.8.3.13.4 MRT Test Reports | 44 | |
| C.8.3.13.5 MRT Post-Test Briefing | 44 | |
| C.8.3.14 Government Test Meetings | 44 | |
| C.8.4 Implementation | 44 | |
| C.8.4.1 Implementation Planning | 44 | |
| C.8.4.1.1 Site Survey | 45 | |
| C.8.4.2 Equipment Delivery | 46 | |
| C.8.4.2.1 Sites Installed by Contractor | 46 | |
| C.8.4.2.2 Sites Installed by Government | 46 | |
| C.8.4.3 Installation | 47 | |
| C.8.4.3.1 Installation Activities in Operational Facilities | 48 | |
| C.8.4.3.2 Lead Paint Protection | 48 | |
| C.8.4.3.3 Hazard Prevention and Warning | 48 | |
| C.8.4.3.4 Site Clean Up | 48 | |
| C.8.4.3.5 Damages to Facilities | 48 | |
| C.8.4.3.6 Auxiliary Equipment | 48 | |
| C.8.4.4 Reserved | 49 | |
| C.8.4.5 Reserved | 49 | |
| C.8.5 Technical Interchange Meeting | 49 | |
| C.8.6 Configuration Management | 49 | |
| C.8.6.1 Configuration Management Planning | 49 | |
| C.8.6.2 Configuration Status Accounting System | 50 | |
| C.8.6.3 System Documentation | 50 | |
| C.8.6.4 Configuration Audits | 50 | |
| C.8.6.5 Configuration Change Control | 51 | |
| C.8.6.5.1 Change Proposal and Notices | 51 | |
| C.8.6.5.2 Configuration Control Board | 52 | |
| C.8.7 Security | 52 | |
| C.8.7.1 Information System Security | 52 | |
| C.8.7.1.1 Access Control | 52 | |
| C.8.7.1.2 Audit | 53 | |
| C.8.7.1.3 Security Configuration Management | 53 | |
| C.8.7.1.4 Identity Management | 54 | |
| C.8.7.1.5 Media Protection | 54 | |
| C.8.7.1.6 System and Communication Protection | 54 | |
| C.8.7.1.7 System and Information Integrity | 55 | |
| C.8.7.2 Security Authorization Program | 55 | |
| C.8.7.3 Security Training | 56 | |
| C.8.8 Human Factors Engineering | 57 | |
| C.8.8.1 HFE Program | 57 | |
| C.8.8.2 HFE Design Approach Documents | 57 | |
| C.8.8.3 HFE Reviews | 57 | |
| C.8.8.4 HFE AWD Displays | 57 | |
| C.8.9 Environmental, Occupational Safety and Health | 58 | |
| C.8.9.1 EOSH Program Plan | 58 | |
| C.8.9.2 EOSH Training | 58 | |
| C.8.9.3 Use of Protective Equipment | 59 | |
| C.8.9.4 Program Documentation | 59 | |
| C.8.9.5 Hazardous Materials | 59 | |
| C.8.9.6 Hazard Identification | 59 | |
| C.8.10 Safety Risk Management | 59 | |
| C.8.11 Integrated Logistics Support | 60 | |
| C.8.11.1 ILS Planning | 60 | |
| C.8.11.1.1 | Logistics Management Information | 60 |
| C.8.11.2 Provisioning Conference | 61 | |
| C.8.11.3 Technical Documentation | 61 | |
| C.8.11.4 Reliability, Maintainability, and Availability | 62 | |
| C.8.11.5 Reserved | 63 | |
| C.8.11.6 Reserved | 63 | |
| C.8.11.7 Maintenance | 63 | |
| C.8.11.7.1 Software Maintenance | 63 | |
| C.8.11.7.2 Hardware Maintenance | 64 | |
| C.8.11.7.3 Maintenance Reporting | 64 | |
| C.8.11.7.4 Reserved | 64 | |
| C.8.11.7.5 Reserved | 64 | |
| C.8.11.7.6 Bar Code Asset Tracking System | 64 | |
| C.8.11.7.7 On-Site Contractor Support | 65 | |
| C.8.11.8 Transition | 65 | |
| C.8.11.8.1 Depot Support Transition Plan | 65 | |
| C.8.11.8.2 Software Transition Plan | 65 | |
| C.8.11.8.3 Transition Technical Data Package | 66 | |
| C.8.11.8.4 Transition of Supply Support | 66 | |
| C.8.11.9 Transition Training | 69 | |
| C.8.11.9.1 Training Development | 69 | |
| C.8.12 Reserved | 74 | |
| C.8.13 Cloud Migration Services | 74 | |
| C.8.14 Engineering Support Services | 74 | |
| C.8.14.1 Additional Systems | 74 | |
| C.8.14.1.1 NWP System Extension | 74 | |
| C.8.14.1.2 Additional NWP Support System | 75 | |
| C.8.14.1.3 Additional AWDs | 75 | |
| C.8.14.2 Equipment Relocation | 75 | |
| C.8.14.2.1 Relocation of Equipment within the Same Facility | 75 | |
| C.8.14.2.2 Relocate Equipment to Other Facilities | 75 | |
| C.8.14.3 Mobile Display Application | 75 | |
| C.8.15 NWP Enhancement 1 | 76 | |
| C.8.15.1 Additional Types of NWP Input Data | 76 | |
| C.8.15.2 NWP Geographic Coverage Areas | 76 | |
| C.8.15.3 Additional NWP Products | 76 | |
| C.8.15.4 NWP Algorithm Refinement | 76 | |
| C.8.15.5 AWD Software Enhancements | 76 | |
| C.9 ACRONYMS | 77 |
Table of Tables
| Table 1: DT Activities | 27 |
| Table 2: Test Readiness Criteria | 33 |
| Table 3: Contractor-Supported Test Activities | 38 |
| Table 4: Maintenance Release Test (MRT) Activities | 41 |
| Table 5: Integrated System Implementation Milestones | 43 |
| Table 6: Transition Training | 69 |
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 .