NSST_DO1_SOW_210024A(23MAY2023)FINAL.pdf

SOW 210024A

23 MAY 2023

SUPERSEDING

SOW 210024

21 SEP 2022

STATEMENT OF WORK

FOR

NAVIGATION, SEAMANSHIP, AND SHIPHANDLING TRAINING SYSTEMS

INDEFINITE DELIVERY/INDEFINITE QUANTITY CONTRACT

DELIVERY ORDER 1 (NSS IDIQ DO1)

DEPARTMENT OF THE NAVY

NAVAL AIR WARFARE CENTER

TRAINING SYSTEMS DIVISION

12211 SCIENCE DRIVE

ORLANDO, FL 32826

APPROVED BY:

Luis DeJesus Project Manager, Surface Warfare Training Products Branch

Daniel Chwalisz Head, Surface Warfare Training Branch

Chad Guillet Navy Integration Management Branch Head/APML (GT411)

DISTRIBUTION STATEMENT D - Distribution authorized to the Department of Defense and U.S. DoD contractors only (Administrative or Operational Use) (21 SEP 2022). Other requests for this document shall be referred to Commander, Naval Air Warfare Center Training Systems Division (NAWCTSD), 12211 Science Drive, Orlando, FL 32826.

DESTRUCTION NOTICE - For unclassified, limited distribution documents, destroy by a method that prevents disclosure of contents or reconstruction of the document.

ii

Table of Contents

Section Title Page

1. SCOPE

1.1 Definitions

2. APPLICABLE DOCUMENTS

2.1 Government Documents

2.2 Non-Government Documents

3. REQUIREMENTS

3.1 General Requirements

3.2 Detailed Tasks

3.2.1 Training System Installations

3.2.1.1 NSST Baseline 2

3.2.1.1.1 Software Technology Refresh

3.2.1.1.2 NSST Technical Data Package (TDP)

3.2.1.2 Yokosuka Site Specific Installations

3.2.2 Systems Engineering Processes

3.2.2.1 System Requirements Definition

3.2.2.1.1 System Requirements Analysis

3.2.2.1.2 Traceability

3.2.2.1.3 System Architectural Design

3.2.2.2 Software Engineering

3.2.2.2.1 Software Requirements Analysis

3.2.2.2.2 Software Requirements Verification

3.2.2.2.3 Software Architectural Design

3.2.2.2.4 Software Architectural Design Verification

3.2.2.2.5 Software Detailed Design

3.2.2.2.6 Software Detailed Design Verification

3.2.2.2.7 Software Implementation

3.2.2.2.8 Software Construction and Unit Testing

3.2.2.2.9 Software Code Verification

3.2.2.2.10 Software Integration

3.2.2.2.11 Software Integration Verification

3.2.2.2.12 Software Qualification Testing

3.2.2.3 System Implementation

3.2.2.4 System Integration

3.2.2.5 System Verification Testing

3.2.2.5.1 Contractor Regression Testing

3.2.2.6 Systems Transition

3.2.2.6.1 Software Installation

3.2.2.6.1.1 Software Product

3.2.2.6.1.1.1 Media and Storage Devices

3.2.2.6.1.1.2 Automated Processes

Table of Contents

Section Title Page iii

3.2.2.6.1.2 Contractor Cold Start Execution and Validation

3.2.2.6.1.3 Government Cold Start Execution

3.2.2.7 System Validation

3.2.2.7.1 Software Acceptance Support

3.2.3 Electromagnetic Environmental Effects (E3) Engineering

3.2.4 Reliability and Maintainability (R&M) Engineering

3.2.5 Human Systems Engineering (HSE)

3.2.6 Systems Engineering Technical Review (SETR)

3.2.6.1 System Requirements Review II-System Functional Review (SRR-

SFR)

3.2.6.1.1 SRR-SFR Entry Criteria

3.2.6.1.2 SRR-SFR Exit Criteria

3.2.6.2 Critical Design Review (CDR)

3.2.6.2.1 CDR Entry Criteria

3.2.6.2.2 CDR Exit Criteria

3.2.6.3 T&E SETR Events and Audits

3.2.7 Logistics Conferences and Reviews

3.2.7.1 Logistics Guidance Conference (LGC)

3.2.7.2 Training Program Orientation Conference (TPOC)

3.2.7.3 Technical Manual Initial Guidance Conference (TMIGC)

3.2.7.4 Provisioning Item Selection Conference (PISC)

3.2.7.4.1 PISC Entry Criteria

3.2.7.4.2 PISC Exit Criteria

3.2.8 System Test and Evaluation

3.2.8.1 T&E Program Planning

3.2.8.2 Responsibility for Tests

3.2.8.3 Contractor’s Test Results

3.2.8.4 Test Resources and Facilities

3.2.8.5 Test Methods

3.2.8.6 Test Criteria

3.2.8.7 Alignment

3.2.8.8 Test Log

3.2.8.9 Changes During Testing

3.2.8.9.1 Software Changes During Government Testing

3.2.8.10 Changes After Testing

3.2.8.11 Government Regression Testing

3.2.8.12 T&E Non-Conformance Reporting System

3.2.8.13 Deficiency and Discrepancy Adjudication

3.2.8.14 T&E Program Components

3.2.8.14.1 Navy Preliminary Evaluation (NPE)

3.2.8.14.2 Contractor Preliminary Inspection (CPI)

Table of Contents

Section Title Page iv

3.2.8.14.3 Ready-to-Ship Evaluation

3.2.8.14.3.1 Ready-to-Ship Criteria

3.2.8.14.4 Test Readiness Review

3.2.8.14.4.1 TRR Entry Criteria

3.2.8.14.4.2 TRR Exit Criteria

3.2.8.14.5 Conformance Inspections

3.2.8.14.5.1 Functional Configuration Audit (FCA)

3.2.8.14.5.1.1 Government Preliminary Inspection (GPI)

3.2.8.14.5.1.1.1 GPI Exit Criteria

3.2.8.14.5.1.2 Joint Final Inspection (JFI)

3.2.8.14.5.1.2.1 JFI Exit Criteria

3.2.8.14.5.2 Physical Configuration Audit (PCA)

3.2.8.14.5.2.1 PCA Exit Criteria

3.2.9 Sustainment/Logistics Planning

3.2.9.1 Training System Sparing Product Data (TSSPD)

3.2.9.2 Bill of Materials (BOM) for Logistics and Supply Chain Risk

Management

3.2.9.3 Buy Through the Prime (BTTP)

3.2.9.4 Obsolescence Management/Diminishing Manufacturing Sources and Material Shortages (DMSMS)

3.2.9.5 Obsolescence Management Planning

3.2.9.6 Maintenance Planning

3.2.9.6.1 Supportability Analysis

3.2.9.7 Inventory Management

3.2.9.8 Technical Documentation

3.2.9.8.1 Warranty of Technical Documentation

3.2.9.8.2 Government Furnished Documents/Software and System Access

3.2.9.8.3 IETM Development

3.2.9.8.3.1 IETM General Content

3.2.9.8.3.2 IETM Parts Data

3.2.9.8.3.3 IETM Visual Display System Alignment and Maintenance

Procedures

3.2.9.8.3.4 IETM Runtime Files

3.2.9.8.3.5 IETM Maintenance and Operation Content

3.2.9.8.3.6 IETM XML Structure

3.2.9.8.3.7 IETM Maintainer Level of Detail

3.2.9.8.3.8 IETM Instructor Level of Detail

3.2.9.8.3.9 IETM Duplication of Data

3.2.9.8.3.10 IETM Functionality Requirements

3.2.9.8.4 Assignment of IETM Numbers

3.2.9.8.5 Development Data Module Requirements List (DMRL)

Table of Contents

Section Title Page v

3.2.9.8.6 Government Business Rules

3.2.9.8.7 Technical Data Content and Product Plan

3.2.9.8.7.1 TDCPP Coverage

3.2.9.8.7.2 TDCPP Contractor Recommendations

3.2.9.8.8 IETM Quality Assurance Requirements

3.2.9.8.8.1 Technical Content Validation

3.2.9.8.8.2 Technical Content Verification

3.2.9.8.9 COTS Documentation Requirements

3.2.9.8.9.1 COTS Documentation Integration

3.2.9.8.9.2 Legacy COTS Documentation

3.2.9.8.9.3 COTS System Interfacing

3.2.9.8.9.4 Identifying Technical Publication Sheet for Commercial Manuals

3.2.9.9 Hardware Warranties

3.2.10 Training Program

3.2.10.1 Instructor/Operator and Maintainer Training

3.2.11 Facility Requirements

3.2.11.1 Training System Installation Support

3.2.11.2 Facility safety

3.2.11.3 Equipment and Material Disposal

3.2.11.4 Facility Repair

3.2.11.5 Facility Clean Up

3.2.12 Item Unique Identifier (IUID) Assignment

3.2.13 Packaging Handling Storage and Transportation (PHS&T)

Statement of Work For

Navigation, Seamanship, and Shiphandling Training Systems Indefinite Delivery/Indefinite Quantity Contract

Delivery Order 1 (NSS IDIQ DO1)

1. SCOPE

This Statement of Work (SOW) establishes the contractor tasks for the delivery of Navigation, Seamanship, and Shiphandling (NSS) training systems to existing NSS training facilities and new facility in Yokosuka, Japan. The tasks required in this SOW are within the scope of the Navigation, Seamanship, and Shiphandling Training Systems Indefinite Delivery/Indefinite Quantity Contract (NSS IDIQ) SOW 210023. Each of the main requirement paragraphs in this SOW contains a reference to the applicable paragraphs of the Base IDIQ SOW.

1.1 Definitions

The following definitions apply to this SOW. Definitions in the Base IDIQ SOW apply.

1.1.4 Initial Support Kit (ISK)

The ISK includes:

a. The initial spares (repairable items) and repair parts that are manufactured, subcontracted, or modified by the prime contractor having the design control responsibility

b. The initial spares that support vendor hardware, utilized by the device, which can be procured on the open market or from established sources and for which the prime contractor is not the design activity

c. Support items that are not an integral part of the end item, but are required to inspect, test, calibrate, service, repair, or overhaul the end item, which are manufactured, subcontracted, or modified by the prime contractor having the design control responsibility

d. Items required for support of the trainer system (excluding common hand tools), which can be procured on the open market or from established sources and for which the prime contractor is not the design activity

2. APPLICABLE DOCUMENTS

The following documents of the issue listed form a part of this SOW to the extent specified herein. In the event of a conflict between documents referenced herein and the contents of this SOW, the contents of this SOW take precedence. Nothing in this SOW, however, supersedes applicable laws and regulations, unless a specific exemption has been obtained.

2.1 Government Documents

SPECIFICATIONS:

Naval Air Warfare Center Training Systems Division (NAWCTSD)

PRF 210025A - System Specification for Device 1B17 The Navigation, Seamanship, and Shiphandling Trainer (NSST), dated

STANDARD PRACTICES:

Department of Defense (DoD)

MIL-PRF-85337B - Manuals, Technical: Quality Assurance Program;

Requirements for

MIL-PRF-32216A - Evaluation of Commercial Off-the-Shelf (COTS) Manuals and Preparation of Supplemental Data

MIL-STD-130N - Identification Markings of U.S. Military Property (Available at quicksearch.dla.mil)

OTHER PUBLICATIONS:

Federal Acquisition Regulations (FAR)

FAR 46.105 - Contractor Responsibilities

Defense Federal Acquisition Regulations Supplement (DFARS)

DFARS 252.211-7003 - Item Identification and Valuation (Available at acquisition.gov/dfars)

NAVAIR Instructions

NAVAIRINST 4355.19E - Systems Engineering Technical Reviews, dated 6 FEB

NAVAIRINST 4120.11B - Policy for Preparation and Standardization of Naval air Systems Command Interactive Elective Technical Manuals, dated 24 JUL 2020

(Provided upon request)

NAWCTSD

SOW 210023 - Statement of Work for Navigation, Seamanship, And Shiphandling Training Systems Indefinite Delivery/Indefinite Quantity Contract (NSS IDIQ), dated 21 SEP 2022

2.2 Non-Government Documents

INDUSTRY STANDARDS

International Organization for Standardization (ISO)

ASD S1000D - International Specification for Technical Publications Utilizing a Common Source Database Issue 4.1, dated 31 DEC 2012

(Available from s1000d.org)

ANSI/Institute of Electrical and Electronics Engineers (IEEE)

IEEE Std 29148-2018 - Systems and Software Engineering – Life Cycle Processes – Requirements engineering

(Available from ieee.org) http://www.ieee.org/

3. REQUIREMENTS

3.1 General Requirements

General Requirements and associated CDRLs in SOW 210023 section 3.1 apply

3.2 Detailed Tasks

The contractor shall deliver NSST systems that meet performance requirements specified in Specification PRF 210025A. The contractor shall perform the following tasks.

3.2.1 Training System Installations

3.2.1.1 NSST Baseline 2

The contractor shall analyze, design, document, develop, fabricate, integrate, deliver, install, verify, and validate NSST Baseline 2 that meets requirements in Specification PRF 210025A.

The contractor shall modify systems specified in Specification PRF 210025A section 3.1.11 (with the exception of section 3.1.11.3), to conform to Specification PRF 210025A (with the exception of paragraph 3.1.10.1.f). The contractor shall plan and execute activities related to the transition of specified systems to NSST baseline 2 to meet the following training system availability thresholds:

a. NSST-1 (Norfolk/San Diego): At each site, maintain 50% continuous training system availability. 20 working days maximum total reduced availability per site.

b. NSST-4 (Norfolk/San Diego): At each site, maintain 50% continuous training system availability. 20 working days maximum total reduced availability per site.

c. NSST-5 (Norfolk/San Diego): Maintain 50% continuous training system availability. 30 working days maximum total reduced availability per site.

d. NSST-4/5/6 (Mayport): Maintain NSST-4 and NSST-6 training system availability during NSST-5 non-availability. Maintain NSST-5 training system availability during NSST-4 and NSST-6 non-availability. 30 working days maximum total reduced availability.

e. NSST-5A: 15 working days maximum total downtime per device

f. Other systems: 10 working days maximum total downtime per device

(Ref: SOW 210023, para. 3.2.3)

3.2.1.1.1 Software Technology Refresh

The contractor shall modernize and reestablish the NSST software baseline using current generation state-of-the-art software technology. The contractor shall prepare the Software Product Design (SPD) and the Software Version Description (SVD) IAW the CDRLs. The contractor shall incorporate the SPD and SVD into the Technical Data Package (TDP).

3.2.1.1.2 NSST Technical Data Package (TDP)

The contractor shall consolidate, restructure, and revise existing NSST technical data items to establish the NSST TDP that provides an authoritative technical description of NSST systems across the NSST enterprise. The contractor shall structure the NSST TDP into modular technical data items that match the modularity of NSST system. The contractor shall generate required technical data items that do not currently exist. The contractor shall revise the technical data items based on existing as-built NSST systems and NSST Baseline 2 modifications. The contractor shall prepare the Technical Data Package (TDP) IAW the Base IDIQ CDRL.

3.2.1.2 Yokosuka Site Specific Installations

The contractor shall design, fabricate, integrate, deliver, install, and verify NSST systems specified in Specification PRF 210025A section 3.1.11.3 (Yokosuka Site Specific Requirements) that meet the performance requirements in Specification PRF 210025A for the specified systems.

The contractor shall reuse components from the legacy NSST-5A system in Yokosuka, Japan for components that are transportable and have an anticipated remaining lifecycle of greater than 5 years. The contractor shall not remove components from the existing NSST-5A until the Government has accepted the NSST-4 and NSST-6 devices. The contractor shall plan and execute activities related to the transition of components from the legacy NSST-5A to the required NSST-5 such that that the training non-availability of NSST-5 type device does not exceed a total of 15 working days. (Ref: SOW 210023, para. 3.2.2)

3.2.2 Systems Engineering Processes

The contractor shall use the systems engineering processes to define the requirements for the system, to transform the requirements into an effective product, and to verify and validate the functionality of the delivered product. Standards cited in SOW 210023 section 3.2.7 apply to this SOW. (Ref: SOW 210023, para. 3.2.7)

3.2.2.1 System Requirements Definition

The contractor shall define, document, manage, and apply a requirements definition process to define the system requirements that satisfies performance requirements herein and in Specification PRF 210025A.

3.2.2.1.1 System Requirements Analysis

The contractor shall perform and document the system requirements analysis activities and tasks to transform the requirements specified in Specification PRF 210025A into a set of measureable and verifiable system requirements that specify characteristics of the system. The contractor shall analyze the requirements to decompose and derive lower level functional requirements.

The contractor shall analyze the interaction between the systems, subsystems, and components to derive the functional requirements. The contractor shall write system and functional requirement IAW requirements fundamentals in IEEE Std 29148-2018 section 5.2. The contractor shall document Specification PRF 210025A requirements, system requirements, and functional requirements in the Requirements Traceability Verification Matrix (RTVM).

3.2.2.1.2 Traceability

The contractor shall define, document, manage, and apply a process to accomplish traceability between the Specification PRF 210025A requirements, allocated design baseline, implementation configuration items, and test procedures. The contractor shall utilize an electronic tool to accomplish the requirement traceability function. The contractor shall provide the Government access to the traceability tool and its database. The contractor shall maintain top-down traceability that originate with Specification PRF 210025A requirements and flow down through lower-level requirements to the specific design element(s) that satisfy the requirements, and to the specific verification mechanism(s) that verifies the requirement is met.

The contractor shall maintain bottom-up traceability from system configuration items and test steps to the originating requirement. The contractor shall prepare the Scientific and Technical Reports (Requirements Traceability Verification Matrix (RTVM)) IAW the CDRL.

3.2.2.1.3 System Architectural Design

The contractor shall perform a system architectural design process to establish and update the system architectural design. The contractor shall implement a Modular Open System Architecture (MOSA) with non-proprietary standard interfaces. The contractor shall document the system architectural design in the SPD. The contractor shall prepare the Open System Management Plan (OSMP) IAW the CDRL.

3.2.2.2 Software Engineering

3.2.2.2.1 Software Requirements Analysis

The contractor shall perform software requirements analysis to establish the requirements of the software elements of the system. The contractor shall construct the software requirements IAW requirements fundamentals in IEEE Std 29148-2018 section 5.2. The contractor shall document software requirements in the RTVM.

3.2.2.2.2 Software Requirements Verification

The contractor shall perform software requirements verification.

3.2.2.2.3 Software Architectural Design

The contractor shall perform a software architectural design process to establish and update the software architectural design. The contractor shall implement a modular open software architecture with non-proprietary standard interfaces. The contractor shall document the software architectural design in the SPD.

3.2.2.2.4 Software Architectural Design Verification

The contractor shall perform software architectural design verification.

3.2.2.2.5 Software Detailed Design

The contractor shall perform software detailed design activities and tasks to establish a software design that is verifiable against the software requirements and software architectural designs, and is detailed to perform coding and testing activities and tasks. The contractor shall document the software detailed design in the SPD.

3.2.2.2.6 Software Detailed Design Verification

The contractor shall perform software detailed design verification.

3.2.2.2.7 Software Implementation

The contractor shall perform the software implementation activities and tasks to produce system elements that are implemented as software products.

3.2.2.2.8 Software Construction and Unit Testing

The contractor shall perform the software construction and unit testing activities and tasks to produce both source code and executable software units that conform to the software design and software requirements.

3.2.2.2.9 Software Code Verification

The contractor shall perform software code verification.

3.2.2.2.10 Software Integration

The contractor shall perform the software integration.

3.2.2.2.11 Software Integration Verification

The contractor shall perform software integration verification.

3.2.2.2.12 Software Qualification Testing

The contractor shall perform software qualification testing to confirm that the integrated software product meets its defined requirements.

3.2.2.3 System Implementation

The contractor shall perform system implementation activities and tasks to produce system elements.

3.2.2.4 System Integration

The contractor shall perform system integration activities and tasks to assemble a complete system that conforms to the system architectural design.

3.2.2.5 System Verification Testing

The contractor shall perform system verification testing to ensure that the implementation of each system requirement is tested for compliance and the system is ready for delivery. The contractor shall document system verification testing results in the TIR.

3.2.2.5.1 Contractor Regression Testing

The contractor shall perform regression testing to detect defects introduced by modification to the product baseline. The contractor shall conduct system-level regression testing IAW with Government-approved test procedures and test plans. The contractor shall document regression testing results in the Test/Inspection Report (TIR).

3.2.2.6 Systems Transition

The contractor shall perform the systems transition activities and tasks to install the verified system, together with enabling systems.

3.2.2.6.1 Software Installation

The contractor shall perform the software product installation activities and tasks to install the software product that meets the requirements in the target environment.

3.2.2.6.1.1 Software Product

The contractor shall define, document, control, maintain, validate, and prepare the trainer software. The contractor shall deliver the non-Commercial Item software and databases with corresponding source code, build tools, executable code, configuration information, and build procedures with specified rights. The contractor shall deliver the Commercial Item software and databases with the associated vendor manuals, documentation, physical media, warranty information, licenses, and installation procedures. The contractor shall transfer the Commercial Item software licenses to the Government at training system acceptance. The contractor shall provide sequencing instructions for the execution of cold start and installation starting with the formatting of each computational subsystem hard drives and resulting in a fully operational system using only delivered media, procedures, and systems. The contractor shall prepare the Scientific and Technical Reports (Software Product Package (SPP)) IAW the Base IDIQ CDRL.

3.2.2.6.1.1.1 Media and Storage Devices

The contractor shall provide a dedicated set of software media and storage devices required to perform the cold start and installation procedures. The Government will retain custody and control of the media and storage devices created or used by the Government to accomplish testing. The contractor shall provide the additional media and mass storage devices necessary for the contractor’s internal archiving, development, testing, and other engineering and CM purposes. The contractor shall provide the associated license(s), product key(s), activation code(s), and hardware key(s) of the software media. The contractor shall deliver the commercial and noncommercial software, databases and the build tools required to perform the cold start, installation, and firmware configuration procedures. The contractor shall mark each piece of software media with:

a. Device Name

b. Software Item Name(s)

c. Software Item Vendor Name

d. Software Item Version

e. Software Item Release Date

f. Security classification

g. Media piece number, for multiple piece items (e.g. Disk 1 of 3, Disk 2 of 3)

h. Contractor’s Configuration Management Identifier

i. Export Control Marking (if applicable)

j. Data Rights

3.2.2.6.1.1.2 Automated Processes

The contractor shall document, control, maintain, validate, use, and deliver computational automated processes (e.g., scripts, batch files, job control language, kick-start, and slipstreamed media) in the same manner as software items.

3.2.2.6.1.2 Contractor Cold Start Execution and Validation

Prior to the start of each Government run cold start, the contractor shall execute, validate, and document the results of each subsystem cold start, installation, and firmware configuration procedure. The contractor shall perform the entire cold start and installation procedure, step-by-step as written, and document the results of each step. The contractor shall present the results of each contractor-run cold start and installation procedure to the Government for review no later than one week prior to the start of each Government run cold start. The contractor shall execute, document, correct and validate each cold start and installation procedure until no discrepancies exist.

3.2.2.6.1.3 Government Cold Start Execution

The contractor shall make available personnel knowledgeable in the operation of the trainer’s computational systems during Government execution of the cold start, installation, and firmware configuration procedures. The contractor shall support Government execution and verification of the cold start, installation, and firmware configuration procedures during the Government acceptance test events. The contractor shall correct the cold start procedure until no discrepancies exist with the cold start procedure and the procedure is executable from beginning to end without contractor support. After the Government led execution of the cold start procedures, the contractor shall perform a system stability test with a complete system shutdown that removes power from all components followed by a complete system power up, Daily Operational Readiness Test (DORT), and stress test. If the system stability test identifies system instabilities or components of the system that are non-operational, the contractor shall remedy the instabilities and non-operational components and relevant portions of the cold start shall be repeated.

3.2.2.7 System Validation

The contractor shall perform the system validation activities and tasks to provide objective evidence that the performance of the installed system, when in use in an operational environment, meets the requirements of Specification PRF 210025A.

3.2.2.7.1 Software Acceptance Support

The contractor shall perform the software acceptance support activities and tasks to assist the Government in achieving confidence that the software product meets the requirements of Specification PRF 210025A.

3.2.3 Electromagnetic Environmental Effects (E3) Engineering

The contractor shall maintain an E3 and ESD control program that meets program objectives and ensures that the trainer meets the E3 requirements specified in the Specification PRF 210025A.

(Ref: SOW 210023, para. 3.2.9)

3.2.4 Reliability and Maintainability (R&M) Engineering

The contractor shall establish and maintain an effective R&M program that achieves Specification PRF 210025A R&M requirements. The contractor shall continually track and regularly report reliability and maintainability metrics. (Ref: SOW 210023, para. 3.2.10)

3.2.5 Human Systems Engineering (HSE)

The contractor shall integrate human factors into the trainer design. (Ref: SOW 210023, para.

3.2.11)

3.2.6 Systems Engineering Technical Review (SETR)

The contractor shall conduct and participate in SETR events chaired and attended by the Government. The applicable SETR events will be IAW NAVAIRINST 4355.19E. The contractor shall not use SETRs as a place for problem solving, but to demonstrate that problem solving has been accomplished. Each SETR shall be chaired and led by a Technical Review Board (TRB) Chairperson that is independent to the program team. The contractor shall conduct an event driven SETR that is independent of projected milestones in the schedule when the required system baseline has achieved a level of maturity for the intended review. The

Government will use SETR entry criteria fulfillment to determine if system baseline is mature.

The contractor shall meet contract requirements regardless of the SETR results. The contractor shall maintain design responsibility for the system without regard to the Government’s participation in the SETRs since the Government SETR participants are not authorized to change contract requirements. The contractor shall meet each SETR’s entry criteria prior to holding the SETR. The contractor shall perform the SETR tasks specified herein. (Ref: SOW 210023, para.

3.2.13)

3.2.6.1 System Requirements Review II-System Functional Review (SRR-SFR)

The contractor shall conduct a combined SRR-SFR for NSST baseline 2. The SRR-SFR is a multi-disciplined product and process assessment to ensure that the system under review can proceed into preliminary design, and that the system functional requirements, including derived and decomposed requirements, are defined and consistent with program schedule, risk, and other system constraints. In the SRR-SFR the contractor shall assess the system functional requirements and ensure that the required system performance is fully defined and is traceable to the functional baseline (Specification PRF 210025A). At the SRR-SFR, the contractor shall:

a. Review project organizational structure

b. Review project status and performance metrics

c. Review the project schedule:

1. Past performance against the baseline

2. Critical path and near critical paths

3. Resource allocation and availability

d. Review the Open System Management Plan

e. Show that the functional requirements are traceable to the system requirements

f. Show that the explicit and derived requirements are quantified and documented

g. Present the Software Development Plan and describe details of the plan’s implementation

h. Identify relevant contractor Subject Matter Experts (SMEs) to be used during development and testing

i. Address the following applicable functional areas:

1. Electromagnetic Environment Effects (E3)

2. Human systems integration

3. Environment, safety, and occupational health

4. Test and Evaluation

5. Logistics

6. Technical Documentation

7. Training site and facility constraints

8. Security and Cybersecurity

9. Quality Management

10. Configuration Management

11. Life Cycle Model Management

12. Infrastructure Management

13. Program Decision Management

14. Information and Data Management

15. Parts Management

j. Present the results of a comprehensive risk assessment for design, integration, and test

3.2.6.1.1 SRR-SFR Entry Criteria

Entry criteria for the SRR-SFR shall consist of Government concurrence with the following:

a. CDRL items required to be delivered prior to SRR-SFR have been delivered and accepted IAW CDRL requirements

b. The SRR-SFR presentation materials have been submitted and are acceptable

c. PAC exit criteria have been met

d. IMS is updated with realistic performance expectations and reasonable resourcing levels

e. Risks have been identified, assessed, and mitigation plans are in place

3.2.6.1.2 SRR-SFR Exit Criteria

Exit criteria for the SRR-SFR shall consist of Government determination of acceptable risk in the SRR-SFR elements listed above, and Government concurrence with the following:

a. The required technical competencies have been represented at the review

b. Processes, metrics, databases, and reporting methods are in place and being maintained

c. The project schedule is executable within the technical risks

d. Timeframes and assumptions for Government reviews and inspections are reasonable

e. The project is properly resourced

f. Functional requirements are traceable to the system requirements

g. Explicit and derived requirements are quantified and documented

h. Functional requirements, as disclosed, satisfy the training and system objectives

i. System functional definition and functional decomposition is detailed enough to support detailed design

j. System Functional Baseline has been established to enable preliminary design to proceed under CM

k. Open System Management Plan is complete, meets performance requirements, and aligns with program objectives for a Modular Open System Architecture (MOSA)

l. Risks have been properly identified, assessed, and mitigation plans are in place

m. SRR-SFR minutes and final presentation materials have been submitted and accepted

n. SRR-SFR action items and Requests for Action (RFA) have been successfully resolved and closed

3.2.6.2 Critical Design Review (CDR)

The contractor shall conduct a CDR for NSST Baseline 2 and for each site receiving new NSST systems. The purpose of the CDR is for the Government to formally review the activities and work products generated by the contractor during the performance of the critical design stage in order to develop the product baseline, and to verify that the system is ready to proceed into the hardware-software coding, assembly, and integration phase. The following items shall be topics of discussion and presentation at the CDR:

a. Present final designs

b. Review revisions to the Open System Management Plan

c. Address the following applicable functional areas:

1. Electromagnetic Environment Effects (E3)

2. Human systems integration

3. Environment, safety, and occupational health

4. Test and Evaluation

5. Logistics

6. Diminishing Manufacturing Sources and Material Shortages (DMSMS)

7. Technical Documentation

8. Training site and facility constraints

9. Security and Cybersecurity

10. Quality Management

11. Configuration Management

12. Life Cycle Model Management

13. Infrastructure Management

14. Program Decision Management

15. Information and Data Management

16. Parts Management

d. Review project status and performance metrics

e. Review the project schedule:

1. Past performance against the baseline

2. Critical path and near critical paths

3. Resource allocation and availability

f. Review project problem and risk areas, recommended solutions, and evaluation of alternatives

g. Present changes to the Software Development Plan since SRR-SFR and describe the current details of the plan’s implementation. Address the following applicable software development areas:

1. Software tools

2. Use of developmental, Commercial Item, and Non-Developmental Item (NDI) software and databases

3. Trainer databases

4. Software interfaces

5. Design modularity and commonality

6. Software configuration management plans and structures

3.2.6.2.1 CDR Entry Criteria

Entry criteria for the CDR shall consist of Government concurrence with the following:

a. CDRL items required to be delivered prior to CDR have been delivered and accepted IAW CDRL requirements

b. The CDR presentation materials have been submitted and are acceptable

c. SRR-SFR exit criteria have been met

d. IMS is updated with realistic performance expectations and reasonable resourcing levels

e. Risks have been identified, assessed, and mitigation plans are in place

3.2.6.2.2 CDR Exit Criteria

Exit criteria for the CDR shall consist of Government determination of acceptable risk in the CDR elements listed above, and Government concurrence with the following:

a. The required technical competencies have been represented at the review

b. The product baseline has been established, documented, and is acceptable

c. Traceability flows down through lower-level requirements to the specific design element(s) that satisfy the requirements

d. Open System Management Plan is complete, meets performance requirements, and aligns with program objectives for a Modular Open System Architecture (MOSA)

e. The project schedule is executable within the technical risks

f. Timeframes and assumptions for Government reviews and inspections are reasonable

g. The project is properly resourced

h. Risks have been properly identified, assessed, and mitigation plans are in place

i. Processes, metrics, databases, and reporting methods are in place and being maintained

j. CDR minutes and final presentation materials have been submitted and accepted

k. CDR action items and Requests for Action (RFA) have been successfully resolved and closed

3.2.6.3 T&E SETR Events and Audits

The contractor shall conduct Test Readiness Review (TRR), Functional Configuration Audit (FCA), and Physical Configuration Audit (PCA) SETR events and audits IAW the T&E program requirements.

3.2.7 Logistics Conferences and Reviews

The contractor shall conduct, attend, and participate in logistics conferences and reviews to be held at both the contractor and Government facilities. (Ref: SOW 210023, para. 3.2.14.1)

3.2.7.1 Logistics Guidance Conference (LGC)

The contractor shall conduct, attend, and participate in a Logistics Guidance Conference. The contractor shall hold the LGC in conjunction with the PAC. The contractor shall review logistics requirements of the contract. The contractor shall review the SOW to ensure the contractor understands logistics support requirements. The contractor shall review each CDRL to ensure the requirements match the SOW, and to ensure the contractor understands CDRL deliverable requirements. The contractor shall review PISC requirements to ensure the contractor understands the data inputs to the Training System Sparing Product Data (TSSPD) and Bill of Materials (BOM) for Logistics and Supply Chain Risk Management for the identification of spares and repair parts to sustain the training device throughout the initial support period.

3.2.7.2 Training Program Orientation Conference (TPOC)

The contractor shall participate in the Government conducted Training Program Orientation Conference (TPOC) held in conjunction with the PAC. The purpose of the TPOC is to ensure that the Government and contractor have a clear understanding of, and agreement to, the contractual requirements for the operations and maintenance training and IA training provided to the Government during on-site installation of the trainer.

3.2.7.3 Technical Manual Initial Guidance Conference (TMIGC)

The contractor shall conduct the TMIGC in conjunction with the PAC. The contractor shall present and discuss the following topics at the TMIGC:

a. Review of applicable Mil Standard and Data Item Description (DID) requirements (Exhibits E and F only)

b. Review of TD manuals delivery, review, and Government acceptance and rejection criteria

c. Review of Technical Data Package (TDP) drawings and associated lists delivery, review, and Government acceptance and rejection criteria

d. Review and discussion of Technical Documentation CDRL In-Process Review (IPR) percent level of completion

e. Discuss business rules development and the ASD S1000D Project Business Rules Decision Table, Business Rules Exchange (BREX) Data Module

f. Discuss Data Module Requirements List development

g. Discuss the Common Source Data Base

h. Identification of contractor logistics team members (i.e. Points of Contact (POCs), telephone numbers, email addresses, and other appropriate information)

i. List of action items with milestones for completion

j. Establishment of a tentative dates, locations, and expectations for Technical Documentation CDRL IPRs

k. Discussion of programs issues, problems, risk areas, and recommended solutions

l. Review of the Technical Data Content and Product Plan (TDCPP)

m. Review of the Quality Assurance Plan

3.2.7.4 Provisioning Item Selection Conference (PISC)

The contractor shall conduct and participate in the PISC within 30 days after the CDR event.

The contractor shall provide TSSPD products during the PISC in order to facilitate discussion on the range and depth for the recommended spares. The contractor shall present for review and discussion, the list of items proposed for the Initial Support Kit (ISK) via the CDRLs selected to support the PISC. The contractor shall provide data to support the Government in determining the reliability and criticality of each item to the mission and probable replacement lead-time to determine recommended quantities. During the PISC, the contractor shall demonstrate the approach to developing and populating the data elements of the TSSPD.

3.2.7.4.1 PISC Entry Criteria

The contractor shall attain Government concurrence that the following PISC entry criteria has been met prior to convening the PISC:

a. Successful completion of LGC

b. The TSSPD has been delivered and accepted IAW CDRL requirements

c. The BOM has been delivered and accepted IAW CDRL requirements

d. The PISC presentation materials have been submitted and are acceptable

3.2.7.4.2 PISC Exit Criteria

The contractor shall attain Government concurrence that the following PISC completion criteria has been met:

a. Documentation and capture of the range and depth of items that the Government has selected during the PISC

b. PISC action items and Requests for Action (RFA) have been successfully resolved and closed

c. PISC minutes and final presentation materials have been submitted and accepted

3.2.8 System Test and Evaluation

The contractor shall plan, coordinate, establish, document, and implement a T&E program, including specified T&E components to verify and validate that the required products meet the technical and operational requirements as stated in this SOW and Specification PRF 210025A.

The contractor shall provide representation in the T&E working IPT (WIPT) and shall attend and participate in the T&E WIPT meetings. The contractor shall routinely conduct T&E WIPT meetings to provide a forum for discussion, coordination, and resolution of test planning goals, strategy, and issues. The term “test” as used in this SOW refers to the broader test and evaluation of the products, not the specific verification method defined in the specification.

(Ref: SOW 210023, para. 3.2.15)

3.2.8.1 T&E Program Planning

The contractor shall document the Trainer Test and Evaluation Plan (TTEP) for each test event.

The contractor shall prepare the Revisions to Existing Government Documents (Trainer Test and Evaluation Plan (TTEP)) IAW the Base IDIQ CDRL.

3.2.8.2 Responsibility for Tests

Unless otherwise specified herein, the contractor shall perform the specified tests. The Government reserves the right to perform tests that are deemed necessary to ensure that delivered products conform to the contract requirements.

3.2.8.3 Contractor’s Test Results

The contractor shall record the test results during contractor tests.

3.2.8.4 Test Resources and Facilities

The contractor shall furnish the test facilities, aligned and calibrated equipment, and personnel to conduct testing. The contractor shall provide test facilities that replicate environmental conditions required by the tests. The contractor shall ensure that the contractor personnel, test equipment, test facilities, other supporting equipment, spare assemblies and parts, test and data logs, and other items necessary for testing are available for the full duration of the test events.

3.2.8.5 Test Methods

Tests shall be performed IAW the Government-accepted Test Procedures (TP) and other Government-accepted test plans. TPs shall cover verifications and verification methods specified in Specification PRF 210025A section 4 and shall be written so that a qualified technician with no special knowledge of the specific system being tested can perform the tests.

The contractor shall provide and use automated methods to collect, record, process, and quantitatively evaluate test data. The contractor shall avoid the use of highly manual and labor intensive test processes unless no other alternative exists. The contractor shall prepare test procedures that are modular, separable, and reusable throughout the system lifecycle. Test results shall be documented in the Test/Inspection Report (TIR). The contractor shall prepare the Test Procedures (TP) and Test/Inspection Report IAW the Base IDIQ CDRLs.

3.2.8.6 Test Criteria

The contractor shall test the required product using a combination of quantitative and qualitative test criteria. The contractor shall use quantitative test criteria when possible. If use of quantitative test criteria is not possible, the contractor shall establish and use unambiguous qualitative standards as test criteria. The contractor shall establish quantitative and qualitative test criteria based on real world data. If real world data is not available, the contractor shall generate baseline quantitative models and qualitative standards to use as the basis for acceptance.

3.2.8.7 Alignment

The contractor shall perform the necessary equipment alignments and calibrations prior to the initiation of each test event.

3.2.8.8 Test Log

The contractor shall maintain a digital test log from the start of contractor preliminary inspections to Government unconditional acceptance of the required product. In the digital test log, the contractor shall log the following by article, component (if applicable), date, time, and duration: cold starts, installations, alignments, calibrations, adjustments, tests, failures, repairs, replacements, removals, and other modifications. The digital test log shall automatically calculate and graphically present categorized metrics related to reliability, availability, maintainability, and stability. The contractor shall send copies of the digital test log to the Government at the completion of each test event and upon request. During test events, the contractor shall send to the Government weekly updates of digital test log metrics.

3.2.8.9 Changes During Testing

Changes made in the alignment, calibration, programming, and adjustments during the T&E program, shall be recorded in the contractor’s test log. Tests conducted prior to such changes shall be repeated, unless a Government technical representative determines that such changes have not invalidated the related test data.

3.2.8.9.1 Software Changes During Government Testing

The contractor shall obtain Government authorization prior to making changes to software baselines during Government and integrated test events. The contractor shall maintain configuration control of software baselines used during Government testing. The contractor shall process the revised software baseline into their configuration control program for record and archival into their organization’s software repository and an identical Government software repository at the Navigation Training System Lab (NTSL). The contractor shall assign a version scheme to the revised software baseline and record this version scheme in their configuration control program. The contractor shall provide to the government information on all of the changes, revisions made on the changed software baseline and overall impacts thereof on the trainer system along with the revised and associated incremental version scheme changes. The contractor shall provide updated software media label(s) reflecting the newly assigned version scheme of the revised software baseline along with all other pertinent information corresponding with the revised software baseline such as dates, locations, and all other attribute information uniquely identifying the revised software baseline. The contractor shall demonstrate to the Government that proposed software baseline changes are supported by contractor regression testing.

3.2.8.10 Changes After Testing

Modifications and changes in design, which are determined to be necessary as a result of testing, shall be recorded in the contractor’s test log. Tests run prior to such modifications shall be repeated unless a Government technical representative determines that such changes have not invalidated the related test data.

3.2.8.11 Government Regression Testing

The contractor shall attend and participate in the Government regression testing.

3.2.8.12 T&E Non-Conformance Reporting System

The contractor shall implement and utilize a non-conformance reporting system for reporting and tracking (identification, assignment, status, progress, resolution) of discrepancies and deficiencies discovered during the specified T&E Program Components. The contractor shall provide the Government continuous access to the non-conformance reporting system. The contractor shall use DR categories defined in the Base IDIQ SOW. For DRs established through conformance inspections:

a. The Government will be the final authority on DR category, class, and responsibility

b. Prior to requesting a Government retest of a DR, The contractor shall:

a. Verify the DR is corrected and system is ready for retest

b. Complete and sign off the DR forms

c. The Government will not consider a DR closed until the resolution has been verified by the DR originator or the originator’s designated representative and the DR has been signed by the Test Director or the Test Director’s designated representative

3.2.8.13 Deficiency and Discrepancy Adjudication

The contractor shall correct in scope program discrepancies and deficiencies, unless adjudicated otherwise by the PCO technical representative and communicated by the PCO.

3.2.8.14 T&E Program Components

The T&E program shall consist of the following components. Each T&E program component shall be conducted for each required product.

a. Navy Preliminary Evaluation (NPE)

b. Contractor Preliminary Inspection (CPI)

c. Ready-to-Ship Evaluation

d. Test Readiness Review (TRR)

e. Conformance Inspections:

1. Functional Configuration Audit (FCA)

i. Government Preliminary Inspection (GPI)

ii. Joint Final Inspection (JFI)

2. Physical Configuration Audit (PCA)

3.2.8.14.1 Navy Preliminary Evaluation (NPE)

Navy representatives and engineers designated by the Government will perform preliminary evaluations during the development of the required products to ensure early identification of major problem areas. The contractor shall coordinate and conduct NPEs after the required products are operational and prior to CPI to evaluate general quality, operational characteristics, training potential, and to identification of gross deficiencies. The contractor shall provide operational support for test methods and processes established by the Government. When requested by the Government, the contractor shall coordinate and conduct additional NPEs for the purposes of evaluating changes made to correct problem areas and to assess progress with the integration of major subsystems.

3.2.8.14.2 Contractor Preliminary Inspection (CPI)

The contractor shall perform CPI for each required product IAW the Government-accepted TP and other Government-accepted test plans as documented in the TTEP. The contractor shall conduct the CPI in-plant unless otherwise authorized by the Government. The contractor shall perform every TP applicable to the required product(s). The contractor shall conduct the tests under the direction of the contractor’s QMS representative who shall certify by signature that the applicable test(s) have been completed and the documented results are correct and comply with the applicable specification. The contractor shall invite the Government to each CPI events. A PCO technical representative may witness the performance of CPI. The contractor shall annotate in the TP, procedural changes made as a result of CPI and shall provide a copy of the annotated TP to the Government prior to the TRR.