Attachment_2_-DRAFT_Barracuda_SOW.pdf

i

STATEMENT OF WORK (SOW)

FOR THE

BARRACUDA MINE NEUTRALIZER

Distribution Statement D: Distribution Authorized to the Department of Defense and U.S. DoD Contractors only:

Administrative/Operational Use, 10 March 2017. Other U.S. requests shall be referred to the Mine Warfare Program Office, PEO LCS (PMS 495).

Warning - This document contains technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C. Sec. 2751, et seq.) or the Export Administration Act of 1979, as amended (Title 50, U.S.C. appendix 2401, et seq.). Violations of these export laws are subject to severe criminal penalties. Disseminate per the provisions of OPNAVINST 5510.161.

Destruction Notice – For classified documents, DoD civilians or military personnel will follow procedures outlined in DoDM 5200.01, Volume 3, Enclosure 3; DoD Contractors will follow procedures outlined in DoDM 5220.22, Sections 11-19. For unclassified limited documents (e.g. FOUO, distribution statement controlled), destroy by any method that will prevent disclosure of contents or reconstruction of the document.

ii

CONTENTS

Section ....................................................................................................................................... Page

1.0 SCOPE (CLINs 0001, 0002, 0003, 0100, 0101, 0200 and 0201)

1.1 System Overview

2.0 APPLICABLE DOCUMENTS

2.1 Government Documents

2.1.1 Specifications, Standards, and Handbooks

2.1.2 Other Government Documents, Drawings, and Publications

2.1.3 Non-Government Standards and Other Publications

3.0 REQUIREMENTS (CLINs 0001, 0002, 0003, 0100, 0101, 0200 and 0201)

3.1 Program Management (CLINs 0001 - 0205)

3.1.1 Planning

3.1.2 Monitoring and Control

3.1.3 Metrics

3.1.4 Meetings and Reviews

3.1.4.1 Post Award Conference (applicable to CLINs 0001, 0002, and 0003 only)

3.1.4.2 Monthly Status Review

3.1.4.3 Integrated Baseline Review

3.1.4.4 Quarterly Program Reviews

3.1.4.5 Integrated Product and Process Development Team

3.1.5 Subcontractor Management

3.1.6 Risk Management and Reporting

3.1.7 Electronic Exchange of Information

3.2 Systems Engineering (CLINs 0001, 0002, 0003, 0007, 0100, 0101, 0104, 0200, 0201, and 0204) 11

3.2.1 Systems Engineering Planning

3.2.2 Design and Development

3.2.3 Systems Engineering Technical Reviews

3.2.4 Software

3.2.4.1 Software Development Technical Approach

3.2.4.2 Software Allocated Baseline

iii

3.2.4.3 Software Product Baseline

3.2.4.4 Software Version Description

3.2.4.5 Software Product Specification

3.2.4.6 Firmware Support Manual

3.2.4.7 Software User Manual

3.2.5 Cybersecurity

3.2.6 Program Protection Implementation Plan

3.2.7 Safety

3.2.7.1 Qualifications of Key Contractor System Safety Engineers/Managers

3.2.7.2 System Safety Program (SSP)

3.2.7.3 System Safety Program Plan (SSPP)

3.2.7.4 Hazard Management Plan

3.2.7.5 System Safety Group (SSG) and System Safety Working Group (SSWG) Support 20

3.2.7.6 Hazard Tracking and Risk Resolution

3.2.7.7 System Safety Progress Summary

3.2.7.8 Hazardous Materials Management Plan (HMMP)

3.2.7.9 Preliminary Hazard List (PHL)

3.2.7.10 Preliminary Hazard Analysis (PHA)

3.2.7.11 System Requirements Hazard Analysis (SRHA)

3.2.7.12 Subsystem Hazard Analysis (SSHA)

3.2.7.13 System Hazard Analysis (SHA)

3.2.7.14 Operating and Support Hazard Analysis (O&SHA)

3.2.7.15 Health Hazard Analysis (HHA)

3.2.7.16 Functional Hazard Analysis (FHA)

3.2.7.17 Environmental Hazard Analysis

3.2.7.18 Safety Assessment Report (SAR)

3.2.7.19 System Safety Hazard Management Assessment Report (HMAR)

3.2.7.20 Test and Evaluation Safety

3.2.7.21 Safety Review of Engineering Change Proposals (ECPs), Specification Change Notices (SCNs), System Problem Reports (SPRs), and Requests for Deviation/Waiver iv

3.2.7.22 Safety Verification

3.2.7.23 Explosive Hazard Classification (EHC) and Characteristics Data

3.2.7.24 Explosive Ordnance Disposal Source Data

3.2.7.25 Integration and Management of Subcontractors

3.2.7.26 Safe Standoff Analysis

3.2.7.27 System Safety Program Reviews

3.2.7.28 Safety Review Boards

3.2.7.29 Safety Training and Certification

3.2.7.30 Interfacing Equipment

3.2.7.31 Software System Safety Tasks

3.2.7.31.1 Software Requirements Hazard Analysis

3.2.7.31.2 Software Architecture Analysis

3.2.7.31.3 Detailed Design Hazard Analysis (DDHA)

3.2.7.31.4 Code-Level Software Hazard Analysis

3.2.7.31.5 Software Safety Testing

3.2.7.31.6 Software/User Interface Analysis

3.2.7.31.7 Software Change Hazard Analysis

3.2.8 Analysis

3.2.9 Integration

3.2.10 Technical Data Package

3.3 Configuration Management (CLINs 0001, 0002, 0003, 0007, 0100, 0101, 0104, 0200, 0201, and 0204)

3.3.1 Configuration Identification

3.3.2 Configuration Control

3.3.3 Configuration Status Accounting

3.3.4 Configuration Audits

3.3.5 Technical Data Management

3.4 Reliability, Availability, and Maintainability (CLINs 0001, 0002, 0003, 0007, 0100, 0101, 0104, 0200, 0201, and 0204)

3.4.1 Failure Modes, Effects, and Criticality Analysis

3.4.2 Failure Reporting and Corrective Action System

v

3.4.3 Reliability, Availability, and Maintainability Predictions

3.4.4 Reliability Centered Maintenance

3.5 Quality (CLINs 0001, 0002, 0003, 0007, 0100, 0101, 0104, 0200, 0201, and 0204)

3.5.1 Software Quality Processes

3.6 Test and Evaluation (CLINs 0001, 0002, 0003, 0100, 0101, 0200 and 0203)

3.6.1 Test and Evaluation Planning

3.6.2 Contractor Testing

3.6.2.1 Anti-Tamper Evaluation

3.6.2.2 Software Test and Evaluation

3.6.2.3 Risk Reduction Testing

3.6.2.4 Performance Testing

3.6.2.5 Reliability Testing

3.6.3 Test Equipment

3.7 Testing Support (CLINs 0006, 0105 and 0205)

3.7.1 Developmental Testing Support

3.7.2 Certification Testing Support

3.7.3 DT/IT Support

3.7.4 Operational Assessment Support

3.7.5 Live Fire Test and Evaluation Support

3.8 Supportability and Integrated Product Support (CLINs 0001, 0002, 0003, 0007, 0100, 0101, 0104, 0200, 0201, and 0204)

3.8.1 Maintenance Planning/Strategy

3.8.2 Planned Maintenance System Data/Technical Documentation

3.8.3 Support Equipment

3.8.4 Supply Support

3.8.4.1 Vendors/Subcontractors

3.8.4.2 Provisioning Conference

3.8.4.3 Provisioning Technical Documentation

3.8.4.4 PTD Screening and Sequencing

3.8.4.5 Design Change Notice

3.8.4.6 Indenture Code

vi

3.8.4.7 Component Identification Data

3.8.4.8 Engineering Data For Provisioning (EDFP)

3.8.4.9 Supplemental EDFP

3.8.4.10 System Configuration Provisioning List

3.8.5 Packaging, Handling, Shipping, and Transportability

3.8.6 Facilities

3.8.7 Manpower, Personnel and Training

3.8.8 Logistics Documentation

3.8.9 Demilitarization and Disposal

3.9 Hardware

3.9.1 Engineering Development Models (CLINs 0001, 0002 and 0003)

3.9.2 System Integration Laboratories (SILs) (CLINs 0014 and 0015)

3.9.3 Support Equipment (CLINs 0007, 0104 and 0204)

3.9.4 Low Rate Initial Production Lot 1 (CLINs 0100 and 0101)

3.9.5 Low Rate Initial Production Lot 2 (CLINs 0200 and 0201)

3.10 Security

1.0 SCOPE (CLINs 0001, 0002, 0003, 0100, 0101, 0200 and 0201) The Contractor shall design, build, and test the Barracuda mine neutralizer (herein referred to as Barracuda). This Statement of Work (SOW) defines the requirements for the development and production of the Barracuda. The Barracuda consists of an in-water expendable mine Neutralizer Vehicle and Communications Buoy, and its associated support equipment. Three variants of Barracuda will be developed: a War Shot, an Exercise Variant, and an Inert Variant. The War Shot variant, referred to as Barracuda, is the only variant that will contain a warhead. The Barracuda Exercise Variant will be used for testing, operational training, and tactics development. Additionally, the Barracuda Exercise Variant will be inert, recoverable, and have the ability to record data onboard to facilitate system development and testing. The Barracuda Exercise Variant shall meet the requirements for the War Shot, except for the ability to neutralize the target and where other differences are specifically called out within this SOW and associated documents. The Inert Variant will be identical to the war shot except that all energetic material will be replaced with inert simulated explosive fill. The Inert Variant will be used to support testing. The Contractor shall also provide all associated logistic support for all variants as defined in the SOW.

1.1 System Overview

The mission of Barracuda is to neutralize mines that have been previously located by other mine countermeasure assets. Barracuda will be initially deployed from an unmanned surface vehicle (USV), and controlled from another site, notionally the USV or the Littoral Combat Ship (LCS).

Upon launch, Barracuda will not be physically connected to the USV, but will maintain a communications link. The USV will act as a relay to transmit data between Barracuda and the operator located onboard an LCS. Barracuda may also be operated from a shore-based site while deployed from an USV, if the USV is being operated from shore.

2.0 APPLICABLE DOCUMENTS

The following documents form a part of this statement of work (SOW) to the extent specified herein. In the event of conflict between the documents referenced and the contents of this SOW, the SOW shall supersede except if mandated by law.

2.1 Government Documents

2.1.1 Specifications, Standards, and Handbooks

DEPARTMENT OF DEFENSE STANDARDS

DOCUMENT # TITLE GUIDANCE

/INVOKED

MIL-STD-882E System Safety Invoke MIL-STD-810G Environmental Engineering Considerations and

Laboratory Tests Guidance

MIL-STD-331C Fuze and Fuze Components, Environmental and Performance Test for

Guidance

MIL-STD-1366E Interface Standard for Transportability Criteria Guidance MIL-STD-648D Department of Defense Design Criteria Standard

Specialized Shipping Containers Guidance

MIL-STD-2105D Hazard Assessment Tests for Non-Nuclear Munitions

Guidance

MIL-STD-461G Requirements for the Control of Electromagnetic Interference Characteristics of Subsystems and their Equipment

Guidance

MIL-STD-464C Electromagnetic Environmental Effects Requirements for Systems

Guidance

MIL-STD-130N Identification Marking of U.S. Military Property Invoke MIL-STD-31000A Technical Data Packages Guidance MIL-STD-3018 Parts Management Invoke MIL-STD-1839D Calibration and Measurement Requirements Invoke MIL-STD-3034A Reliability Centered Maintenance Process Invoke MIL-STD-3018 Parts Management Invoke MIL-STD-1839D Calibration and Measurement Requirements Invoke

MIL-STD-3034A

MIL-STD-1472F

MIL-STD-11991A

(Appendix F)

MIL-STD-2073-1E

Reliability Centered Maintenance Process Human Engineering General Standard for Parts, Materials, and Processes

Department of Defense Standard Practice for Military Packaging

Invoke Guidance

Invoke

DEPARTMENT OF DEFENSE SPECIFICATIONS

MIL-S-901D Shock Tests H.I. (High-Impact) Shipboard Machinery, Equipment, and Systems, Requirements

DEPARTMENT OF DEFENSE HANDBOOKS

DOCUMENT # TITLE GUIDANCE/

INVOKED

MIL-HDBK-217F Reliability Prediction of Electronic Equipment Guidance

MIL-HDBK-1390 Level of Repair Analysis Guidance FIIG-A239 Federal Item Identification Guide Miscellaneous

Items Guidance

MIL-HDBK-189 Reliability Growth Management Guidance MIL-HDBK-61A Configuration Management Guidance Guidance

2.1.2 Other Government Documents, Drawings, and Publications

INVOKED

MIL-PRF-38793C Performance Specification, Technical Manuals:

Calibration Procedures, Preparation of Invoke

MIL-PRF-63033C Performance Specification, Technical Manuals:

Demilitarization of Surplus Military Items, Preparation of

Invoke

MIL-DTL-24784C Detail Specification, Manuals, Technical: General Acquisition and Development Requirements, General Specification for

Invoke

MIL-DTL-24784/22 Detail Specification Sheet: Technical Content Development Requirements for Combat System Technical Operations Manuals (CSTOMs); Hull, Mechanical, and Electrical (HM&E) System and Equipment Manuals; Electronic [Including Service Test Electronic, Experimental Electronic and Interior Communication (IC)] System and Equipment Manuals; and Weapon Systems and Weapon Equipment Manuals

Invoke

MIL-DTL-24784/23 Detail Specification Sheet: Illustrated Parts Breakdown (IPB) Requirements

Invoke

DOD 4160.21-M-1 Defense Material Disposition Disposal Guidance and Procedures

Guidance

DOD 4160.28-M-V1 Defense Demilitarization: Program Administration Guidance

NAVSEAINST-

5000.09

Naval Systems Engineering Technical Review Handbook

Invoke

NAVSEA ST000-A-

IDX-010

Test, Measurement and Diagnostic Equipment Index (TMDEI)

Guidance

NAVSEA OD 45845 Metrology Requirements List (METRL) Invoke DoDI 8500.01 Cybersecurity Invoke DoDI 8510.01 Risk Management Framework for DOD

Information Technology

DoDI 5200.39 Critical Program Information Identification and Protection Within Research, Development, Test, and Evaluation

Invoke

Program Protection Plan Outline and Guidance, 01 November 2015

Guidance

DOD 4100.39-M Federal Logistics Information System Procedures Manual Multiple Application References/Instructions

Invoke

DoDI 5200.44 Protection of Mission Critical Functions to Achieve Trusted Systems and Networks

Invoke

DoDI 5000.02 Operation of the Defense Acquisition System Guidance

NAVSEAINST

8010.5C

Insensitive Munitions Requirements

S9310-AQ-SAF-010 Navy Lithium Battery Safety Program Responsibilities and Procedures

Guidance

DOD Risks, Issues, Opportunities Guide, dated June 2015

Guidance

Performance Specification for Barracuda Mine Neutralizer

Invoke

Barracuda Deployment Platform Interface Requirement Specification

Invoke

Barracuda Host Platform Interface Requirement Specification

Invoke

Barracuda Test and Evaluation Master Plan Guidance Mine Warfare Program Office Configuration

Management Plan Guidance

Mine Warfare Program Office Risk Management Plan

Guidance

NAVSUP P-719 Guide of the Assignment, Application and Use of Source, Maintenance and Recoverability Codes

Guidance

SECNAV M-5239.2 Cybersecurity Information Technology and Cybersecurity Workforce Management and Qualification Manual

Invoke

Application Security and Development Security Technical Implementation Guide (STIG) V4R1

Invoke

Joint Software Safety Engineering Handbook, dated August 2010

Invoke

NAVSUP P-700 Common Naval Packaging Guidance NAVSEA Provisioning, Allowance, Fitting Out

Support (PAFOS) Manual Guidance

NIST SP 800-34 Contingency Planning Guide for Federal Information Systems

DOD Guide to Uniquely Identifying Items, Version 2.5, dated 15 September 2012

Guidance

DOD Guide to Item Unique Identification Quality Assurance, Version 1.0, dated 20 November 2009

Guidance

OPNAVINST

5100.24B

Navy System Safety Program Policy Invoke

NAVSEAINST

5000.8

Naval SYSCOM Risk Management Policy Invoke

NAVSEAINST

5100.12B

System Safety Engineering Policy Invoke

NAVSEAINST

8020.6E

Department of the Navy Weapons Systems Explosive Safety Board

Joint Software Safety Engineering Handbook

Barracuda Mine Neutralizer Program Protection

Plan Invoke

Barracuda Design Reference Mission Profile Invoke

Anti-Tamper Security Classification Guide Invoke Barracuda Security Classification Guide Invoke

DoDAF Architecture Framework Version 2.02 Guidance

T9070-AL-DPC-

020/077-2

NAVSEA Hazardous Material Avoidance Process

Invoke

Department of Defense Ammunition and Explosives Hazard Classification Procedures

Guidance

NAVSEAINST

4790.8C

Maintenance and Material Management Manual Invoke

2.1.3 Non-Government Standards and Other Publications

INVOKED

ISO 9001-2015 Quality management systems Requirements Guidance IEEE-730-2014 Standard for Software Quality Assurance

Processes Guidance

NCSL Z540.3 Requirements for the Calibration of Measuring and Test Equipment

Guidance

AS1390 Level of Repair Analysis Invoke SAE GEIA-STD-0007B Logistics Product Data Invoke SAE GEIA-HB-0007 Logistics Product Data Handbook Guidance SAE GEIA-HB-0007-1 Logistics Product Data Reports Handbook Guidance TechAmerica TA-STD-

Product Support Analysis Invoke

S1000D International Specification for Technical Publications Using a Common Source Database

ASTM F116-07 Standard Practice for Human Engineering

Design for Marine Systems

ANSI/EIAA 748 Earned Value Management Systems

Guidance formal/2015-06-03 OMG Systems Modeling Language, Version

1.4

3.0 REQUIREMENTS (CLINs 0001, 0002, 0003, 0100, 0101, 0200 and 0201)

The Contractor shall provide Program Management (PM), Systems Engineering (SE), Configuration Management (CM), Reliability, Availability, and Maintainability, Quality, Test and Evaluation (T&E), and Supportability and Integrated Product Support , and related deliverables for definition, design, integration, fabrication, test, and support of the Barracuda System. The Contractor shall provide all manpower, materials (to include Contractor and subcontractor travel costs), and facilities to fulfill this Statement of Work (SOW). The Barracuda system and all supporting elements and equipment shall be designed and tested in accordance with the requirements defined in this SOW, the Barracuda System Performance Specification (SPS), and the associated Barracuda Deployment Platform Interface Requirement Specification (IRS), the Barracuda Host Platform IRS, and other requirements documents contained within this SOW.

3.1 Program Management (CLINs 0001 - 0205)

The Contractor shall organize, coordinate, and control all internal project activities (including subcontractors) to ensure the correct and timely delivery of all supplies and services specified in this contract. The Contractor shall establish and maintain management operations that shall include the following areas:

• Program Planning and Control

• Subcontractor Control

• Financial Management

• Data Management

• Management and Accountability for Government Furnished Equipment, Material, or

Information

• Risk Management

• Logistics Management

• Configuration Management

• Quality Assurance

• Security

• Safety

• Reliability

• Maintainability

• Supportability

The Contractor shall establish and implement a program management office function to manage all technical performance, including reliability, maintainability, supportability, human systems integration, safety, integrated product support, cost, schedule, data delivery, and hardware delivery requirements of the contract.

3.1.1 Planning

The Contractor shall establish program structure, practices, and techniques to be used in managing the efforts to fulfill the requirements of the SOW. The Contractor shall identify personnel, materials, tools, and facilities necessary to fulfill the requirements of the SOW. The Contractor shall develop, update, and maintain a Contractor Work Breakdown Structure (WBS).

The Contractor shall develop an integrated schedule, to include tracking of all activities, subcontractor activities, resource loading, major milestones, deliveries, testing, and dependencies as specified in this SOW. The result of these planning efforts shall be delivered and presented at the Integrated Baseline Review (IBR). (CDRL D001)

3.1.2 Monitoring and Control

The Contractor shall use an Earned Value Management System (EVMS) to monitor and manage the cost, schedule, technical performance and risk for all aspects of the SOW. The American National Standards Institute/Electronic Industries Alliance Standard 748, Earned Value Management Systems shall be used for guidance. (CDRL D002)

3.1.3 Metrics

The Contractor shall implement metrics to provide management visibility into the software and hardware development process and progress. The selected metrics shall clearly portray variances between actual and planned performance, shall provide early detection or prediction of situations that require management attention, and shall support assessment of the impact of proposed changes on the program. The Contractor shall provide the government routine insight into these metrics during meetings and reviews described below.

3.1.4 Meetings and Reviews

3.1.4.1 Post Award Conference (applicable to CLINs 0001, 0002, and 0003 only) The Contractor shall support a Post Award Conference (PAC) within fifteen (15) calendar days after contract award. The PAC shall be hosted at the Contractor’s facility and will be used to review contract requirements and will be used to identify and resolve potential problems. The Contractor shall establish a capability to electronically share and exchange information as required in this SOW, and present its capabilities and structure at the PAC. The Contractor shall prepare presentation materials. (CDRL D003)

3.1.4.2 Monthly Status Review

The Contractor shall hold a Monthly Status Review. The Contractor shall review cost, schedule, technical progress, and program issues and risks during the Monthly Status Review. The Monthly Status Review shall be hosted at the Contractor’s facility. Video teleconferencing or conference calls may be used for these status meetings. Monthly reviews are not required during the month of Quarterly Program Reviews. The Contractor shall prepare presentation materials, supporting materials, and meeting minutes. (CDRLs D003, D004)

3.1.4.3 Integrated Baseline Review

The Contractor shall conduct an Integrated Baseline Review (IBR) at the Contractor’s facility within ninety (90) calendar days after contract award. The Contractor shall conduct incremental IBRs, as needed, throughout the life of the contract for major contract changes involving re-planning or detail planning of the next phase of program. The Contractor shall provide an overview as to how the program shall be executed. The Contractor shall identify and present how the contracts and program requirements have been allocated down to the work package/cost account. The Contractor shall describe the planned approach for coordinating and establishing communications between Government and Contractor team members. The Contractor shall describe the overall management philosophy as it relates to resolving conflict and problems, and discussing achievement of key milestones and challenges to overcome in order to meet the program objectives. The Contractor shall ensure that the program baseline includes the entire contract technical scope, consistent with the contract schedule requirements, and has adequate resources assigned. The IBR will be used to achieve a mutual agreement of the baseline plan and the underlying management processes, such as configuration management, risk management, software development, quality assurance, and reliability management. The Contractor shall describe the team structure and identify IPT/WG participants as described in Section 3.1.4.5.

The Contractor shall prepare a meeting agenda, presentation materials, and meeting minutes.

(CDRLs D003, D004, D005)

3.1.4.4 Quarterly Program Reviews

The Government will conduct Quarterly Program Reviews (QPRs) at the Contractor’s facility to review the status of the program. The Contractor shall report on cost, schedule, technical progress, and program issues and risks. The Contractor shall ensure that reporting includes subcontractor cost reporting, schedule, technical progress, issues, and risks. Schedule reporting shall include a schedule of major near term events, and an overall Master Program Schedule and critical/alternate path analysis. The Contractor shall report on hardware and software configuration status accounting metrics. The Contractor shall prepare a meeting agenda, presentation materials, and meeting minutes. The first QPR shall be conducted within 180 calendar days of the contract award. During months that a QPR is held, the QPR replaces the Monthly Status Review. (CDRLs D003, D004, D005)

3.1.4.5 Integrated Product and Process Development Team

The Contractor shall apply a systematic approach to the integrated, concurrent development of the products and processes that apply to the development and production of Barracuda using the Integrated Product Team (IPT) model. The purpose of the IPTs is to discuss and resolve issues and make team decisions based on timely input from IPT team members.

The Contractor shall participate in the Government-chaired Program Management (PM) IPT, composed of senior management, technical, business/contracts, and team leaders from other lower-level IPTs and Working Groups (WGs). The PM IPT monitors all program-level technical, cost, and schedule objectives; oversees program status and progress by conducting technical and programmatic reviews; provides the leadership to ensure sound business management of the program; and provides executive oversight of the planning, scheduling, and budgeting for production, deployment, and life-cycle support of Barracuda. The PM IPT will be the primary forum for resolution of Systems Engineering (SE) IPT and other WG issues. The PM IPT may authorize and charter additional IPTs/WGs on an ad-hoc basis as needs dictate.

The Contractor shall participate in the Government-chaired SE IPT to manage the overall system engineering processes, and solve technical problems for Barracuda. The SE IPT will oversee the Contractor’s system engineering process to ensure it provides a total system solution, meeting the Barracuda System Performance Specification requirements that include design, fabrication, integration, and test, while providing a balance among performance, cost, schedule, and risk.

The SE IPT shall identify, track, and validate critical Technical Performance Measures (TPMs) as part of the systems engineering process. TPMs identify critical technical parameters that are at a higher level of risk during design. The SE IPT shall develop a list of TPMs, which will be approved by the PM IPT at Preliminary Design Review (PDR). In support of solving technical problems, the SE IPT may request Technical Interchange Meetings (TIMs). The Contractor shall support these TIMs by providing analysis to support SE IPT technical recommendation(s). The Contractor shall support the PMS 495 risk management process by proposing risks for submittal to the PMS 495 Risk Management Board through the SE IPT. The Contractor may use the Mine Warfare Program Office Risk Management Plan as guidance.

Additionally the Contractor shall provide support for the following IPTs and/or WGs: System of System (SoS) IPT, Test and Evaluation (T&E) IPT, Integrated Product Support (IPS) IPT, Software WG, and System Safety WG, Logistic Support WG. Additional IPTs, WGs, and/or TIMs may be formed as required under the PM IPT and shall be supported by the Contractor.

The Contractor shall support IPTs, WGs, and TIMs with agendas, presentation materials, and meeting minutes as required. (CDRLs D003, D004, D005)

3.1.5 Subcontractor Management

The Contractor shall actively manage and report the performance and quality of all work performed under subcontracts. The Contractor shall flow down all prime Contractor requirements to all subcontractors.

3.1.6 Risk Management and Reporting

The Contractor shall establish and maintain a Risk Management Program to assess the risks associated with program cost, schedule, and achievement of technical requirements. The DoD Risks, Issues, Opportunities Guide of June 2015 may be used as guidance.

The Contractor shall maintain a Risk Database which:

• Identifies potential risks.

• Assesses risks by determining probability of occurrence and assigns a relative ranking of program impact.

• Assigns the risk realization date.

• Determines actions to mitigate or minimize these risks and closure criteria.

The Risk Management database shall be maintained by the Contractor. The database output shall be included in the presentation materials for the Monthly Status Review. Risk mitigation actions shall have defined schedule milestones. The Contractor may submit applicable risks, from their database, to the PMS 495 Risk Management Board through the SE IPT. (CDRL D003)

3.1.7 Electronic Exchange of Information

The Contractor shall use the applications outlined in Table 1 for documents delivered to the Government.

Document Category Application

Word Processing Microsoft Word

Spreadsheets Microsoft Excel

Project Planning Microsoft Project

Presentation Software Microsoft PowerPoint

Requirements Traceability/Verification MagicDraw

Model Based Systems Engineering MagicDraw Table 1: Document Formats

The Contractor shall provide, implement, and maintain a program collaboration tool to generate, integrate, store, view, and retrieve all unclassified digital data generated during contract performance on-line, accessible by Internet, compliant with the requirements of Navy/Marine Corps Intranet (NMCI). All CDRLs and Contractor technical documentation shall be available for Government on-line review and comment.

The IPTs and WGs shall use the Electronic Commerce/Electronic Data Interchange (EC/EDI) solution for on-line review and exchange of comments. The Contractor shall notify the government of any new postings, revisions, and updates. The Contractor shall maintain and archive all data and purge data files only upon Government approval.

3.2 Systems Engineering (CLINs 0001, 0002, 0003, 0007, 0100, 0101, 0104, 0200, 0201, and 0204)

The Contractor shall perform Systems Engineering (SE) tasks required to ensure compliance of the system with the requirements in the Barracuda System Performance Specification and as described in the following sections.

3.2.1 Systems Engineering Planning

The Contractor shall prepare a Systems Engineering Management Plan (SEMP) that details the Contractor’s overall systems engineering approach to meet the SE requirements set forth in the Barracuda System Performance Specification and this SOW. The Contractor shall describe how the various technical inputs are integrated and how multi-disciplinary teamwork will be implemented. The SEMP shall provide comprehensive detail on how an integrated engineering effort will be managed and conducted during the design, development, integration, and testing of Barracuda. The SEMP shall present the methods, practices, and procedures used to manage and integrate the hardware, software, and specialty engineering activities into a structured SE effort.

The SEMP shall describe the entire Barracuda design process and provide detail on the engineering, technical, support, and programmatic efforts for the development. The Contractor's SE approach shall be applied to all subsystems and components. The Contractor shall describe how its selection of interfaces will maximize the ability of the system to easily accommodate the insertion of alternative, reusable modular system elements. Within the SEMP, the Contractor shall describe how the proposed system architecture meets these goals, including the steps taken to use non-proprietary or non-vendor unique COTS components wherever practicable. (CDRL D006)

3.2.2 Design and Development

The Contractor shall comply the requirements from this SOW, the Barracuda SPS, and the Barracuda External IRSs to the lower level subsystems. The Contractor shall record and deliver these requirements in the System/Subsystem Specification (SSS). The Contractor shall maintain a System Requirements Verification Matrix (SRVM), based on the Barracuda SPS and the Contractor-developed SSS, for the purpose of verifying all system requirements. The Contractor shall provide traceability from each requirement to the test method, test level, test case number, and resulting test status to verify compliance with that particular requirement. Test methods may include inspection, analysis, demonstration, or test. The SRVM shall also provide backwards traceability of derived requirements to the applicable higher requirement. (CDRLs D007, D008)

The Contractor shall utilize the Model-based systems engineering (MBSE) methodology to capture the context, standards, requirements, structure, behavior, and characteristics of Barracuda. Visibility into the integrated system model shall be accomplished by DoD Architecture Framework (DoDAF) 2.02 viewpoints, Systems Modeling Language (SysML) v1.4 diagrams, or a combination of both. The Contractor shall also populate the integrated system model with viewpoints/diagrams that show the structure, behavior, interfaces, requirements traceability, and other derived design aspects of the Barracuda sub-systems, configuration items, and components. The Contractor shall design the integrated system model using MagicDraw, as listed in Table 1. The Contractor shall develop and provide the integrated system model to the Government in a format compatible with the MagicDraw tool suite. The Contractor shall develop the integrated system model such that it can be exported in open-standard formats, such as the Physical Exchange Schema (PES) or Extensible Modeling Language (XML), in such a way that the model can be shared between various modeling tools without the loss of data.

(CDRL D009)

The Contractor shall design and fabricate three variants of the Barracuda system. Three variants are: a War Shot, an Exercise Variant, and an Inert Variant. The War Shot variant shall contain a kill mechanism capable of rendering mines inoperative. The Barracuda Exercise Variant shall be inert, recoverable, and have the ability to record data onboard to facilitate system development and testing. Data elements to be stored by Barracuda Exercise Variant will be dependent on the system design. The Inert Variant shall be identical to the war shot except that all energetic material shall be replaced with inert simulated explosive fill.

The Barracuda design will address design criteria that meets safety criteria, form, fit, and function to not adversely affect the human operator from normal workload conditions. Human Systems Integration (HSI) standards found in MIL-STD-882E; MIL-STD-1472F, Human Engineering; and American Society for Testing and Materials (ASTM) F1166-07, Standard Practice for Human Engineering Design for Marine Systems, Equipment, and Facilities will be used during Barracuda development.

The Contractor shall follow an open systems approach for using modular design, standards-based interfaces, and widely-supported consensus-based standards. The contractor shall develop and maintain an architecture that incorporates appropriate considerations for reconfigurability, portability, maintainability, technology insertion, vendor independence, reusability, scalability, interoperability, upgradeability, and long-term supportability. The Contractor shall design any additional modularity into the system as described in Attachment X.

The Government will maintain control of the functional baseline, as reflected in the System Performance Specification. The Government will take control of the allocated baseline at the conclusion of PDR, and of the production baseline at the conclusion of Critical Design Review (CDR). Changes to baselines will be managed via the configuration control process in Section 3.3.2

3.2.3 Systems Engineering Technical Reviews

The Contractor shall conduct Systems Engineering Technical Reviews (SETRs) in accordance with the Naval Systems Engineering Technical Review Handbook, NAVSEAINST 5000.09, Enclosure 5. Integrated Warfare Systems Specific SETR Guidance. The Contractor shall conduct the following SETR events:

• System Requirements Review

• System Functional Review

• Software Specification Review

• Preliminary Design Review

• Critical Design Review

• System Verification Review

• Production Readiness Review

Incremental technical reviews of the above shall be coordinated through the SE IPT and PM IPT.

These events shall be hosted at the Contractor’s facility. Each SETR event will be chaired by the Government. The Contractor shall develop and deliver a Design Review Information Package for the SETR events. The Contractor shall prepare a meeting agenda, presentation materials, and meeting minutes for each SETR event. The Contractor shall also discuss the various levels of the Technical Data Package, prior to the appropriate SETR event, as defined in this SOW. The Contractor shall develop and deliver a Barracuda Manufacturing Plan to support the Production Readiness Review. (CDRLs D003, D004, D005, D010, D011)

3.2.4 Software

3.2.4.1 Software Development Technical Approach

The Contractor shall define a software development approach appropriate for the computer software effort to be performed under this contract. This approach shall be documented in a Software Development Plan (SDP). The Contractor shall follow this SDP for all computer software to be developed or maintained under this effort. (CDRL D012)

The SDP shall address the Contractor’s proposed methods for complying with Application Security and Development Security Technical Implementation Guide V4R1, 25 July 2016.

In all cases, the level of detail of the SDP shall be sufficient to define all software development processes, activities, and tasks to be conducted. Information provided shall include specific standards, methods, tools, actions, strategies, and responsibilities associated with the software development and qualification effort.

The Contractor shall develop the software and firmware required to achieve the requirements defined in this SOW, the Barracuda System Performance Specification, and other associated Barracuda requirements documents referenced in this SOW.

3.2.4.2 Software Allocated Baseline

The Contractor shall develop a Software Requirement Specifications (SRS) from allocated system level requirements and evaluate the software requirements to ensure all system level requirements are met. Requirements include the technical/operational functions the software must be capable of performing. Non-functional requirements include the characteristics of the software, as well as, reliability, maintainability, security, safety, and error handling. The Contractor shall develop an SRS for each Computer Software Configuration Items (CSCI).

(CDRL D013)

The Contractor shall break down the Barracuda SRS into a Software Architecture Design (SAD), and Interface Design Document (IDD) (CDRLs D014, D015).

The SAD shall break down the software attributes of the overall architecture defined in this SOW and the System Performance Specification (SPS).

The SAD shall contain sufficient detail to show that the architectural design meets the cybersecurity and safety requirements outlined in Sections 3.2.5 and 3.2.7.

The Contractor shall develop the IRS as defined in the SOW. The IRS shall break down the software attributes that outline the specification of requirements imposed on one or more system, subsystem, Hardware Configuration Item (HWCI), CSCI, manual operation, or other system component to achieve one or more interfaces among these entities (CDRL D016).

The IDD shall define the specifics of the interfaces identified in the IRS by identifying each interface and the data exchanged between each interface. The IDD shall contain enough detail such that the hardware and software of each component that makes up the interface is defined.

3.2.4.3 Software Product Baseline

The Contractor shall develop a Software Design Description (SDD) that shows how the software system will be structured to satisfy the requirements identified in the software requirements specification. The SDD is a translation of requirements into a description of the software structure, software components, interfaces, and data necessary for implementation. (CDRL D017)

3.2.4.4 Software Version Description

The Contractor shall provide a Software Version Description (SVD) for each formal software release of all CSCIs. The SVD shall identify and describe the CSCIs and will be used to release, track, and control software versions, including the initial release of the software and any subsequent release(s). The SVD shall contain the inventory of materials released, inventory of software contents, all changes implemented, any unique-to-site restrictions, installation instructions, and known errors remaining in the code. (CDRL D018)

3.2.4.5 Software Product Specification

The Contractor shall develop and deliver a Software Product Specification for each CSCI. The Contractor shall deliver the following in the Barracuda Software Product Specification:

• Full description of all software, libraries, build files, makefiles supplied

• Instructions for using all routines and programs

• Source code for all software and firmware

• Source code for all Contractor and Subcontractor developed frameworks and toolkits

• Source code, object code, libraries, and documentation that has been customized or modified from a commercial product

• Source code for all Contractor tools required to build, load, debug, execute, and process data from the support and test equipment

• Source code for all components and tools that are required to build all system resident software and firmware

• Detailed list of all hardware and software required to build, test, and load system software and firmware including compilers, debuggers, profiles, operating systems, board support packages, libraries, firmware synthesis and test tools

• Build support infrastructure such as makefiles for all components and tools

• Unit test scripts and verification source code

• Binary images for all software and firmware

• Algorithm, software and firmware design documents

(CDRL D019)

3.2.4.6 Firmware Support Manual

The Contractor shall develop and deliver a Firmware Support Manual (FSM) to identify and record information needed to program and reprogram firmware devices in which Barracuda System software will be installed (CDRL D020). (NOTE: Firmware is considered software until it is burned into a firmware device and shall be treated accordingly in development efforts)

3.2.4.7 Software User Manual

The Contractor shall develop and deliver a Software User Manual (SUM). The Contractor shall describe all operator-machine interface controls to support system, subsystem, equipment level and test operations. The Contractor shall develop the equipment-oriented instructions necessary to support the operational aspects of the hardware and software baselines that:

• Describe system software install and load procedures

• Describe system initialization and administration procedures

• Describe all operator-machine interface controls to support system, subsystem, and equipment level operations

(CDRL D021)

3.2.5 Cybersecurity

The Contractor shall ensure that the design to be developed and produced in the Barracuda system incorporates, within the system allocated baseline, the DoD cybersecurity requirements as delineated in the technical reference documents DoDI 8500.01 series, “Cybersecurity”, and DoDI 8510.01 series, “Risk Management Framework for DoD IT”. The Contractor shall keep abreast of changes in applicable Cybersecurity technical guidance that may impact the system allocated baseline.

The Contractor shall establish and maintain security measures to protect all aspects of the system to include physical, technical, and vulnerability management measures to meet DoD security and Cybersecurity requirements.

The Contractor shall employ only government off-the-shelf (GOTS) or commercial off-the-shelf (COTS) information assurance (IA) and IA-enabled information technology products that comprise an NSA-approved solution for unmanned systems [products have been evaluated and/or validated by the National Security Agency (NSA) or in accordance with NSA-approved procedures] to protect classified information that is either in transit, or at-rest.

The Contractor shall designate a cybersecurity liaison to correspond with the Government Information System Security Manager (ISSM) to coordinate activities to ensure compliant implementation of security controls, to oversee all cybersecurity related issues, and cybersecurity test events.

The Contractor shall ensure that personnel working in the area of cybersecurity vulnerability management are trained and appropriately certified in accordance with SECNAV M-5239.2, Cybersecurity Information Technology and Cybersecurity Workforce Management and Qualification Manual dated June 2016.

The Contractor shall develop, deliver, and maintain system security artifacts in support of the DoDI 8510.01 System Security Plan (SSP) referenced in the Risk Management Framework (RMF) Core Security Authorization Package Security Controls Template to support an Authorization Decision by the Authorizing Official (AO) for Barracuda. (CDRL D022)

The Contractor shall develop, deliver, and maintain a Security Controls Traceability Matrix (SCTM), as defined in the Implementation Status/Security Control Status section of the SSP within the RMF Core Security Authorization Package Security Controls Template. The SCTM establishes the technical, administrative, and procedural security control baseline minimal requirements for the system. The initial SCTM shall become a finalized baseline set of security controls, consistent with the approved RMF Categorization of the System, in accordance with

(IAW) Step 1 of the RMF process. The Contractor shall use the finalized baseline SCTM to maintain and manage implementation of each planned security control, addressing each security control to determine the implementation status, and describing all tailoring guidance to more closely align the control for specific operating conditions. (CDRL D022)

The Contractor shall provide Platform Information Technology (PIT) Cybersecurity Artifacts in support of the Government PIT Designation Request for Barracuda to obtain a PIT Designation.

(CDRL D022)

The Contractor shall track, notify, and implement security vulnerabilities as they are identified, and document the processes in support of the Government Cybersecurity Vulnerability Management Plan to ensure the system maintains its security posture throughout the entire lifecycle. (CDRL D022)

The Contractor shall regularly scan the system for vulnerabilities utilizing the DoN approved vulnerability scanning tools. The Contractor shall ensure the scanning tools have been updated with the latest signatures and scanning engines prior to the execution of each vulnerability scan.

The Contractor shall deliver the vulnerability scan report. (CDRL D022)

The Contractor shall implement vulnerability management tasks for cybersecurity compliance to include patch maintenance, anti-virus and, and implementation of Security Technical Information Guides (STIGs), Security Readiness Guides (SRGs), Secure Content Automation Protocol (SCAP) Benchmarks, and document all benchmark artifacts. (CDRL D022)

The Contractor shall host and participate in cybersecurity test events IAW the Barracuda Test and Evaluation Master Plan (TEMP) at the Contractors’ development or manufacturing facility, or other test sites as appropriate, for an independent Security Control Assessor (SCA) to conduct security assessment of the system to meet the requirements for obtaining an Authorization to Operate.

The Contractor shall document all non-compliant results from test events in a Plan of Actions and Milestones (POA&M) along with mitigating factors. The POA&M shall also identify and explain all Not Applicable (N/A) IA Controls, All Non-Compliant IA Controls, and all Non- Compliant vulnerability findings as identified in the vulnerability Scans, STIGs, SRGs, and SCAP Benchmarks. (CDRL D022)

The Contractor shall provide inputs for implementation of a Contingency Plan IAW NIST SP 800-34 for the Barracuda operating in its intended environment. (CDRL D022)

The Contractor shall develop, deliver, and maintain Cybersecurity Strategy Artifacts IAW the DON CIO Cybersecurity Strategy Template and Guidance. The Cybersecurity Strategy shall be tailored to the specific system security features the Contractor is designing into the system to enable an update to the Barracuda DON CIO Cybersecurity Strategy. (CDRL D022)

3.2.6 Program Protection Implementation Plan

The Contractor shall conduct Program Protection in accordance with the following documents, and keep abreast of any changes in these documents that may impact Program Protection requirements:

• DoDI 5200.39, "Critical Program Information (CPI) Identification and Protection Within Research, Development, Test, and Evaluation (RDT&E) "

• DoDI 5200.44, "Protection of Mission Critical Functions to Achieve Trusted Systems and Networks"

• Deputy Assistant Secretary of Defense, Systems Engineering Program Protection Plan (PPP) Outline and Guidance, 01 November 2015

• DoDI 5000.02 “Operation of the Defense Acquisition System”

• Barracuda Mine Neutralizer Program Protection Plan

• Anti-Tamper (AT) Security Classification Guide (SCG)

The Contractor shall derive and develop the implementation of program protection requirements from the Government’s Barracuda Program Protection Plan (PPP), and provide implementation information to enable an update to the PPP. (CDRL D023)

The Contractor shall host and assist in a re-assessment, at each SETR event, to determine the existence of Critical Program Information (CPI) inherent in the system or inherited from external systems.

The Contractor shall assist in the Threat Assessment for any CPI identified.

If any CPI is identified for Barracuda stemming from the re-assessments, the Contractor shall derive and develop their implementation of Anti-Tamper (AT) in accordance with the AT requirements defined in the Barracuda AT Plan. The Contractor shall articulate the AT design techniques intended to be implemented for the protection of CPI within the classified Barracuda AT Plan.

The Contractor shall comply to DoDI 5200.44 for Supply Chain Risk Management (SCRM).

The contractor shall demonstrate that the contractor has visibility into its supply chain for critical components, understands the risks to that supply chain, and has implemented or plans to implement risk mitigations to counter those risks.

The Contractor shall host and assist in Criticality Analysis (CA) re-assessment at each SETR event to support Supply Chain Risk Management (SCRM) efforts to determine mission critical components, in addition to the components a program determines are critical for other reasons (e.g. safety critical), that may result in catastrophic or critical protection failures due to operational, system information, or component integrity aspects.

The Contractor shall assist in the Threat Assessment for any Level I or Level II rated Critical Components resulting from the CA. Criticality levels shall be defined by adapting the MIL-STD 882 System Safety Program definitions of criticality to mission criticality.

3.2.7 Safety

3.2.7.1 Qualifications of Key Contractor System Safety Engineers/Managers The Contractor shall ensure that the design as developed establishes…