C.1.

0 INTRODUCTION

C.1.1 Background
The Battle Force Tactical Training (BFTT) Program is an Acquisition Category (ACAT) IV-M acquisition program
that provides the hardware and software required to integrate onboard trainers and simulators and stimulators into a
baseline multi-warfare and multi-ship combat system team training capability. An integral part of the programs
under the BFTT are the Battle Force Electronic Warfare Trainer (BEWT), Surface Electronic Warfare Team Trainer
(SEWTT) and Combined Integrated Air and Missile Defense and Anti-Surface Warfare Trainer (CIAT). The
BEWT, SEWTT and CIAT systems, whether integrated with BFTT or operating in standalone mode, are the sole
providers of tactical EW training to the US Navy and US Coast Guard.
C.1.2 Scope
This Statement-of-Work (SOW) describes the systems, supplies and services to be furnished, manufactured,
performed or processed to meet the training requirements of the US Navy and US Coast Guard. The scope of this
contract is to continue the US Navy’s migration from legacy BEWT systems to the new and developing BEWT II
systems; continue development of enhanced capabilities of the SEWTT software; continue the development of the
CIAT training system; develop future training capabilities, such as Mk53, MH60R, Specific Emitter Identification
(SEI), High Gain High Sensitivity, Soft Kill Coordinator (SKC) and Electronic Attack (EA), Laser Detect and
Engage (LDE), and Electro-Magnetic Spectrum Visualization Tool (ESVT) etc; incorporation of an enhanced After
Action review with electronic scoring; deliver BEWT II systems to the US Coast Guard and US Navy; deliver
training systems to CIAT training locations worldwide; provide Engineering expertise to the US Navy as required to
advance all forms and facets of combat system training, both Electronic Warfare and Non-Electronic Warfare; and
provide updates, repair, technical and engineering support services as required to the US Navy.

The Contractor shall perform these as specifically defined and directed in TIs which shall be issued in accordance
with the Special Provision under Section H “NAVSEA 5252.242-9115 TECHNICAL INSTRUCTIONS.”

C.2.0 DOCUMENTS FOR INCORPORATION OR REFERENCE

The specifications or standards (government and commercial) necessary for successful performance of this contract
are listed in sections below. Additional specifications, standards, instructions, directives, and other publications may
be cited in individual TIs as guidance and clarification for the Contractor. The contractor shall use all documents in
C.2.1-2.10 denoted as “Incorporation” as requirements in executing the SOW. All documents denoted as reference
shall be used as reference guides during performance.

DOCUMENTS INCORPORATION REFERENCE

C.2.1 Cyber Security
DoD Instruction 8500.01, Cybersecurity of 14 March 2014 X
SECNAVINST 5239.3C, Department of the Navy Information X
Assurance (IA) Policy, 02 May 2016
SECNAV M-5239.2 DON Cyberspace Information Technology X
(IT) and CSWF Management and Qualification Manual, 27 Jun
2016
SECNAV 5239.20A DON Cyberspace IT and CSWF X
Management and Qualification, 10 Feb 2016
NAVSEAINST 9400.02A NAVSEA PIT Control Systems X
Cybersecurity Governance and Guidance, 20 Sep 16
Department of the Navy Chief Information Officer Memorandum X
02-10, Information Assurance Policy Update for Platform
Information Technology 26 April 2010, with Enclosure (1), PIT
Definitions for DON, and Enclosure (2), DON Platform IT IA
Guidance
DoD Directive 8140.05, Cyberspace Workforce Management of X
11 August 2015
DoD Manual 8570.1-M, Information Assurance Workforce X
Improvement Program of 19 Dec 05 (Incorporating Change 4, 10

1
Nov 2015)
Navy C&A and Navy ODAA, C&A Guidance for PIT X
Interconnection of 20 Jan 09
CJCSINST 6510.01F, Information Assurance (IA) and Computer X
Network Defense, 9 Feb 2011
DODINST 8580.1, Information Assurance (IA) in the Defense X
Acquisition System of 09 July 04
SECNAV M-5239.1 Department of the Navy Information X
Assurance Program, Information Assurance Manual of Nov 05
SECNAV 5239.22 DON Cybersecurity Safety Program X
(CYBERSAFE), 15 Nov 2016
DISA IAVA Process Handbook, Version 3.0, 14 Feb 2007 X
NAVSEA Afloat Information Assurance (IA) Implementation X
Manual 9400.2-M, April 2012
SECNAV 5510.36A DON Information Security Policy, 6 Oct X
2006
Test Procedure Preparation Directive NAVSEA T9050-AA-DIR- X
010
NAVSEA S9AA0-AA-SPN-010/GEN-SPEC X
PEO IWS Instruction 5000.8 X
PEOIWSINST 5234.1, Software Measurement Policy, dated 31 X
Jan 2012
PEOIWSINST 5239.1, PEO IWS Surface Navy Combat System X
Cybersecurity
Security Technical Implementation Guides X
(STIGs)
Surface Navy Combat Systems Software Product Line X
Architecture, Architecture Description Document, Version 1.0,
dated 31 July 2009
Total Ship Test Program Manual, NAVSEAINST S9095 AD- X
TRQ-010/TSTP
NIST Special Publication (SP) 800-53 X
NIST Special Publication (SP) 800-53A X
CNSS Instruction No. 1253 X
NAVSEA Afloat PIT RMF Business Rules Interim v1.1, 14 Nov X
2016
SECNAV M-5510.36 DON Information Security Program X
Manual, June 2006
DONCIO Memo – DON Implementation of the Risk X
Management Framework (RMF) for DOD Information
Technology, 20 May 2014
DONCIO Memo - RMF Process Guide v1.0, 13 Dec 2016 X
BFTT Security Classification Guide 2-15-17 X
C.2.2 System Safety
Mil-Std 882E (current version E) (Department of Defense X
Standard Practice System Safety)
OPNAV INST 5100.Navy System Safety Policy (Program X
Milestones) System Safety Working Group
NAVSEA INST 9410.2A NSWC Certification Policy, Risk X
Assessments, Software Trouble Reports
NAVSEA PEO IWS Instruction 5000.8 NAVSEA PEO IWS Risk X
Management Policy (Standard Chemical Avoidance)
NAVSEA SW020-AH-SAF-010 Weapon System Safety X
Guidelines Handbook

2
Navy Weapon System Safety Program, NAVSEAINST 8020.6E, X
NAVSEA INST 5100.12B System Safety Engineering Program X
Requirements
NAVSEA INST 5100.12M System Safety Engineering Manual X
MIL STD 6016F Interoperability / Force Level Safety X
JSWRB / JS-SSA Joint Service Weapon Safety Review Board X
(JSWRB) Endorsement of Joint Services Software Safety
Authority (JS-SSA)
NOSSA Letter N32-1581 dated 10 Oct 08 Department of Navy X
Systems Of Systems (SOS)
OPNAV INST 5100.24C Environmental Safety Occupational and X
Health Considerations in Navy Capabilities and Systems
Engineering Process
NAVSEA OP 5, Vol 1, Revision 7, Ch 14 Ammunition and X
Explosives Safety Ashore
NAVSEA INST OP 4 NAVSEA Explosives Safety Afloat X
OPNAV INST 5100.23G Navy Occupational Safety and Health X
Program Manual
NOSSA TECHNICAL MANUAL S9310-AQ-SAF-010 X
Department of Navy Lithium Batteries
STANAG 4404 Training Safety Precepts Combat System and X
Combat System Elements and Design Requirements
OPNAV INST 1500.75A High Risk Training Policy and X
Procedures
SEC NAV INST 5100.10K Department of Navy Safety Policy X
Joint Software Systems Safety Engineering Military Handbook X
454B DoD Handbook Guidance on Software Safety Design
NAVSEA S2020-AH-SAF-010 Guidelines for Electronic X
Equipment
OPNAV INST 5100.24C Environmental Safety Occupational and X
Health Considerations in Navy Capabilities and Systems
Engineering Processes
OPNAV INST 1500.76C Naval Training Systems Requirements, X
Acquisition and Management
NAVSEA Hazardous Material (HM) Avoidance Process X
Technical Manual (T9070-AL-DPC-020/077-2
OPNAV INST 1500.76C CNO Naval Training Systems X
Requirements, Acquisition and Management
Allied Ordnance Publication (AOP 52) Assessment of Munitions X
Related Computing Systems North Atlantic Treaty Organization
(NATO) (SSSTRP requested Architectural Analysis, via MIL
STD 882E, Task 205)
C.2.3 Test & Evaluation
NAVSEA Instruction 9410.2A, Naval Warfare Systems X
Certification Policy (NWSCP)
PEO IWS Instruction 4730.1A, Combat System Certification X
Process, January 2005
PEOIWS Training Systems Directorate, Training Systems X
Certification Process, December, 2009
NAVSEA Instruction 4215.1, Implementing Automated Test and X
Re-Test Tools in NAVSEA Acquisition Programs, June 10, 2010
PEO IWS INSTRUCTION 9800.1, AEGIS Integration Event X
(AIE) Process, JAN 23, 2012
Incorporating Test and Evaluation into Department of Defense X
Acquisition Contracts Guide of October 2011

3
PEOIWSINST 4130.1B, IWS Enterprise Configuration Control X
Process (ECCP), SEP 14, 2011
PEO IWS Instruction 4732.1, Element Certification policy (Draft) X
PEO IWS Instruction 4731.1, Combat System Stress and X
Endurance Test Requirements for Surface Programs (Draft)
S9095-AD-TRQ-010/TSTP Total Ship Test Program (TSTP) X
MIL-HDBK-61(SE) Configuration Management Guidance (para
6.2 and 6.3)
C.2.4 Logistics
DoD Guide to Uniquely Identifying Items, v2.5 September 15, X
2012
DoD Instruction 5000.64 Accountability and Management of X
DoD-Owned Equipment and Other Accountable Property, May
19, 2011
DoD Instruction 4140.01 DOD Supply Chain Material X
Management Regulation, December 14, 2011
MIL-STD-31000 Technical Data Packages, Detail Specification, X
dated 9 Jul 2004
MIL-STD-129R Military Marking For Shipment and Storage, Sep X
2007
NAVSO P-3692 Department of the Navy Guide for Conducting X
Independent Logistics Assessment, Revision 8, September 2012
SECNAVINST 4105.1 Independent Logistics Assessment and X
Certification Requirements November 9, 2012
Government Electronics and Information Technology Association X
(GEIA) SAE-GEIA-STD-0007, “Logistics Product Data” 1 AUG
2007
C.2.5 Systems Engineering
Government Electronics and Information Technology Association X
(GEIA) GEIA-STD-0007, “Logistics Product Data” 1 AUG 2007
PEO Integrated Warfare Systems, Tailored Technical Review X
Manual, Version 2.0, 18 DED 2009
C.2.6 Software Engineering
IEEE 12207, "Standard for Information Technology - Software X
Life Cycle Processes"
IEEE1278 Distributed Interactive Simulation (DIS) Standards X
IEEE1516 Standard For Modeling And Simulation (M&S) High X
Level Architecture (HLA) Framework And Rules
C.2.7 Human System Engineering
MIL-STD-1472G X
MIL-STD-46855A DoD Standard Practice Human Engineering X
Requirements for Military Systems, Equipment and Facilities
MIL-HDBK-1908B NOTE 1 X
ASTM-F1166 HUMAN Engineering Design for Marine Systems, X
Equipment and Facilities, HFS100 American National Standard
for HUMAN Factors Engineering of Visual Display Terminal
Workstations
BFTT Human Intergration - Computer Interface (HCI) Design X
Guide
MIL-STD 2525C DoD Interface Standard Common Warfighter X
Symbology
Workstation Production Methodology and Programmer’s X
Handbook, Revision 2, 01 March 2004
C.2.8 EW Training Systems Documents
Integrated Training Systems / PEO IWS Tailored Technical X

4
Review Manual (TRM) – Tailored 13 February 2013
BFTT T46D System Hardware Description and Operational X
Overview, Version P, 26 March 2013
C.2.9 Other Government Documents
BFTT Operational Requirement Document (ORD) 21 March 1992 X
C.2.10 Commercial Standards and Specifications
SQL for databases (e.g., SQL for databases ANSI ISO/IEC 9075- X
1, ISO/IEC 9075- 2, ISO/IEC 9075-3, ISO/IEC 9075-4, ISO/IEC
9075-5)
HTML for presentation layer (e.g., XML 1.0 X
www.webstandards.org)
XML for data transfer X
Web services for remote system calls X
ISO/IEC 19501:2005 Information technology – Open Distributed X
Processing – Unified Modeling Language (UML) Version 1.4.2
ASME Y14.100-2004 Engineering Drawing Practices X
IEEE/EIA Std 12207-2008 Systems and Software Engineering X
ISO 9001:2000 Quality Management Systems -Requirements, X
dated 12 Dec 2000
ISO 10007:2003Quality Management-Guidelines for X
Configuration Management
JAVA SWING Application Program Interface, Addition 7 X
ANSI/ISO/ASQ 9001-2008 Quality Management Systems X
CMMI-DEV+IPPD V1.3 or higher X
EIA/IS-632 X
IEEE 1220 X
IEEE Std 24765:2010 X

Note 1: Standards that are not specified within this contract or that are modified must be submitted to and approved
by the IWS 1IT PAPM and the PCO prior to use.
Note 2: Documents listed are current as of the date of this solicitation. If a more current version becomes available
the Contractor shall notify the COR and the PCO prior to use.
Note 3: Copies of military handbooks, instructions, standards and specifications and DoD adopted non-Government
standards may be obtained in accordance with the Federal Acquisition Regulation (FAR) Subpart 52.211-2. Copies
of specifications, standards, and data item descriptions cited in this solicitation, if listed in the DoD Index of
Specifications and Standards (DoDISS) or the Acquisition Management Systems and Data Requirements Control
List, DoD 5010.12-L (Dec 2003) may be obtained from:
1. ASSIST database via the Internet at https://assist.dla.mil/
2. DoD issuances (http://www.dtic.mil/whs/directives/)
3. DoN issuances (http://doni.dla.mil/default.aspx)
4. PEO IWS documents (Please email [email protected])
5. By submitting a request to the
Department of Defense Single Stock Point (DoDSSP)
Building 4, Section D
700 Robbins Avenue
Philadelphia, PA 19111-5094
6. Naval Systems Data Support Activity (NSDSA) website at:
https://www.navsea.navy.mil/nswc/porthueneme
7. DoD Information Technology Standards Registry; https://disronline.csd.disa.mil/a/
8. ITS Portal – https://nserc.nswc.navy.mil/its (Requires an account)
Copies of non-government publications not listed in the DoDISS or DAU may be obtained from the respective
industry association.
Note 4: Document Precedence

5
In the event of conflict between the Incorporation and Reference documents in the preceding paragraphs, the order
of precedence shall be the Incorporation documents and then any other reference document(s).

C.3.0 STATEMENT OF WORK

C.3.0.1 Section C Contents Table

SOW Section Applicable CLINs

3.1 Program Management Common Across All CLINs
3.2 Systems Engineering, Design, Level Of Effort: CLIN 0001 and 0007, and if Exercised 1001,
Development, Implementation, Test, and 1007, 2001, 2007, 3001, 3007, 4001, 4007 and CLINs in
Support support of Level of Effort 0003, 0004, and if Exercised 1003,
1004, 1006, 2003, 2004, 2006, 3003, 3004, 3006, 4003, 4004,
4006
3.3 Production Production of BEWT II Systems 0005, and if Exercised 1005,
2005, 3005, 4005
3.6 Government Furnished Material Storage Storage 0006, and if Exercised 1006, 2006, 3006, 4006

C.3.1 Program Management

(Applicable to all CLINs)
The Contractor shall perform program management functions to ensure all the requirements are met. The Contractor
management functions include, but are not limited to, manage and maintain DD Form 1423 to ensure compliance
with development and delivery requirements; maintain information liaison with all stakeholders; track and maintain
records of direction and authorization from Contracting Officers Representative (COR), Alternate Contracting
Officers Representative (ACOR), Program Management Office (PMO), Procuring Contracting Officer (PCO) and
Administrative Contracting Officer (ACO); development and tracking of cost data as a management element of the
program; inspection and test records; provide and maintain a quality management system; maintain auditable
records of all costs charged to this contract; manage production flow to ensure delivery requirements are met;
manage execution of the Technical Instructions; manage contract funding to ensure that appropriations are
expended in an allowable manner and Limitation of Funds and Cost Clauses are followed; manage data call
responses; maintain and keep account for all GFP and GFI to ensure records and disposition are accurate; and
ensure management practices as necessary to execute this contract in a cost effective and professional manner.

The Contractor shall plan for a one day Post Award Kickoff Meeting. The Contractor shall participate in semi-
annual program reviews.

C.3.1.1 Contractor Communication

The Contractor shall communicate and document its plans, processes and approaches to meet all program and
contract requirements. The Contractors Program Management team members shall each possess and maintain
Program Management Professional (PMP) certification. The Contractor shall use a metrics based management
approach for planning, scheduling and technical, cost, risk, and quality monitoring/reporting of program-wide
visibility of plan versus actual efforts under this contract. The Contractor shall establish, deliver and maintain a
program management process that outlines performance against cost schedule and technical objectives. (CDRL
A001, A012)
3.1.1.1 The Contractor shall provide support to the Integrated Product Team (IPT) structure documented in the
Government furnished Systems Engineering Plan (SEP) (Attachment J-03). The Contractor shall provide a Systems
Engineering Management Plan (SEMP) that integrates with the IWS 1IT SEP (Attachment J-03). (CDRL A024)
3.1.1.2 The Contractor shall update the Government furnished PEO IWS 1.0 Work Breakdown Structure (WBS),
Attachment J-05, and include WBS assignments in the Integrated Program Management Report (IPMR) (IMS)
(CDRL A013) and the Technical portion of the monthly report (CDRL A001).
3.1.1.3 The Contractor shall deliver the Contractor’s current Configuration Management Plan (CMP) (CDRL A041)
that describes the Contractor’s configuration management program, and the methods, procedures and controls,
effective configuration identification, change control, status accounting, and audits of the total configuration,

6
including hardware, software and firmware (CDRL A023). The principle use is to provide the government a basis
for review, evaluation and monitoring of the CM program and its proposed components.
3.1.1.4 The Contractor shall develop, tailor, maintain and deliver to the Government an Integrated Master Schedule
(IMS) (CDRL A013) for each separately funded developmental TI executed and all funded production CLINs along
with the associated Technical Data Packages (TDP) (CDRL B001).
C.3.1.2 Program Management Meetings and Technical Reviews
3.1.2.1 Post Award Kick-off Meeting – The Contractor shall provide a detailed briefing on its management and
contract execution strategy at the Post-Award Kick-off Meeting to be held within two (2) weeks of contract award.
The Contractor shall plan for a one-day Post Award Kick-off Meeting. As options under the contract are executed,
the Government reserves the right to conduct additional kick-off meetings.
3.1.2.2 Program Management Reviews – The Contractor shall conduct semi-annual Program Management Reviews
(PMR), beginning ninety (90) days after award. The Contractor shall document the PMRs, which may be conducted
via a Government approved online utility tool or other Government-approved means, with agendas, minutes
(CDRLs A022) and presentation materials delivered IAW (CDRLs A021). The purpose of the reviews is to ensure
the management approach remains sound, meets the requirements, and is properly documented. The Contractor
shall develop and deliver minutes of meetings, in accordance with (CDRL A022) or as directed by the COR for all
meetings that have a formal agenda. The PMRs shall include but are not limited to the following:
 The objectives and scope of the work for each requirement;
 Review of metrics;
 Confirmation of resolved issues and managing outstanding issues. This shall include status of significant
problems faced by the program manager and current plans to resolve the problems or mitigate their
impacts.
 Identification and evaluation of risk factors, mitigations, and address areas where risk has changed;
 Identification of cost and schedule variance;
 Identification of problems with Government Furnished Information or Equipment, impact, and work-
around or solutions;
 Identification of production status;
 Review of Action Items (AIs).
3.1.2.3 Technical Reviews – The Contractor shall schedule all Technical Reviews in the IMS. The technical
packages for formal review shall be developed and delivered in accordance with CDRL A021, available
electronically to Government Team ten (10) working days prior to the review.
3.1.2.4 The Contractor shall host and support Technical Interchange Meetings (TIMs) and milestone reviews for
development tasking and production quarterly, or as needed on an emergent basis to address critical program issues.
The Contractor shall:
 Submit TIM Agendas and any read ahead documents (CDRL A021);
 Publish meeting minutes for each IPT meeting (CDRL A022);
C.3.1.3 Integrated Digital Data Environment
The Contractor shall utilize the secure Integrated Training Systems (ITS) portal, Attachment J-06, operated by
Integrated Warfare Systems 1IT, that provides ready access to create, store, access, manipulate, and exchange digital
data via NIPRNET. No CLASSIFIED information, documents, software code, or other data shall be loaded to or
saved on the ITS portal. The Contractor shall provide e-mail notification to addressees (see Exhibit A-1) whenever
a deliverable is posted or updated.
All items posted by the Contractor to the ITS portal, including drafts of deliverables that are not final versions, shall
be considered delivered for purposes of the DFARS data rights clauses (and subject to the same rights asserted for
final deliveries). However, these non-final versions shall not constitute acceptance for purposes of Section E or the
DFARS data rights clauses.
C.3.1.4 Contract Security Requirements
The Contractor shall maintain an active facilities security clearance and safeguarding of CLASSIFIED materials up
to Secret and maintain certification by Defense Security Service (DSS) for the development, receipt, shipment,

7
handling and storage of classified and FOUO marked hardware, software, and documentation as required in support
of this contract. The information required to develop and test electronic warfare training systems includes library
models and entities classified Secret. The production and repair of systems includes GFE maintenance, handling
and de-militarization of hard drives containing classified and FOUO software and data.
The Contractor shall comply with the requirements of the DD 254, Attachment J-07, for implementation of and to
ensure proper safeguarding of classified materials, events and processes, also including proper unclassified
documentation designation and marking per the SCG. This shall include documentation developed by the
Contractor or received in support of working groups and IPTs.
The Contractor shall ensure personnel coming in contact with; developing and designing; repairing, maintaining and
updating; or handling classified material, data, or hardware, hold a valid SECRET clearance.
C.3.1.5 Cyber Security
The Contractor shall ensure the system design and engineering processes employed in system design include Cyber
Security (CS) and Information Assurance (IA) considerations as delineated in the technical reference documents
table, marked for incorporation (Section C.2.1), correctly implemented in the systems hardware and software.
Reference documents identified in Section C.2.1 table can be downloaded from the http://iase.disa.mil website.
The Contractor shall remain up to date on changes to cyber security guidance and be prepared to implement updated
policy and guidance. If it is determined that a change in guidance will impact the system or software design, or
other contract deliverables, the Contractor shall notify the COR and IWS 1IT within thirty (30) days of
determination.
The Contractor shall develop and deliver CS related deliverables as required in the Technical Instructions (TI).
Examples include, but not limited to:
1. IA Defense-in-Depth Architecture Diagrams for the system under development, and updates to the
sub-network and platform network diagrams into which the system will be integrated
2. List of IA validation and test procedures performed by the Offeror to verify that the stated IA
requirements have been met; (validation and test results should be made available upon request)
3. IA Residual Risk Assessment
4. IA Risk Mitigation Plan
5. IA test objectives and plans
6. Results of DISA Gold Disk Scans
7. DISA SRR Scripts, or e-Eye Retina Scans, as appropriate
8. Results of IA test procedures and validation procedures
(CDRLs A031, A032, A033, A034)
C.3.1.6 Safety
The Contractor shall design all systems and components tasked via TI to provide the users the ability to maintain
positive control over the capability to inject synthetic information into a shipboard combat system. A Permission-
To-Train (PTT) authorization is required from the combat system before simulators and stimulators can inject
synthetic data into the combat system. This authorization must be capable of being retracted automatically if safe
conditions are no longer being met. A designated operator must also be able to retract this permission. Loss of PTT
must cause simulation and stimulation of combat system elements to immediately cease. Training and stimulation to
the combat system can resume once PTT is restored. (CDRL A042)
C.3.2 Systems Engineering, Design, Development, Implementation, Test, and Support (Level Of Effort)

Systems Engineering tasking will be directed by the Government through the use of TIs as defined in Section H
Clause “NAVSEA 5252.242-9115 TECHNICAL INSTRUCTIONS.”
C.3.2.1 Development and Support
(Applicable to CLINs 0001, and if exercised 1001, 2001, 3001, 4001)
The Government will task the Contractor, via TI, to provide engineering support to the program office. The
engineering efforts will include the following:
1. Surface Electronic Warfare Team Trainer (SEWTT),

8
 2. Battleforce Electronic Warfare Trainer II (BEWT II),
3. Combined Integrated Air and Missile Defense (IAMD) and Anti-Surface Warfare (ASW) Trainer (CIAT),
4. Nulka,
5. BEWT Legacy and BEWT II In-Service Engineering Agent (ISEA) support.
3.2.1.1 SEWTT, Surface Electronic Warfare Team Trainer, trains AEGIS and SSDS EW watch standers,
individually and as a Team, when interfaced with the BFTT system, through the stimulation of the SLQ 32V6
tactical electronic warfare consoles both onboard ships and at shore-based facilities. The SLQ 32V6 is the
processing and human interface portion of the most recent upgrade to the Navy’s electronic warfare tactical
capability being undertaken. This multi-year multi-phase upgrade is known as the Surface Electronic Warfare
Improvement Project (SEWIP). SEWTT is a CSCI integrated into the SLQ 32V6 software.
3.2.1.2 BEWT, The Battleforce Electronic Warfare Trainer, trains AEGIS and SSDS watch standers, individually
and as a Team when interfaced with the BFTT system, through the stimulation of the SLQ 32A and SLQ 32B
tactical electronic warfare consoles both onboard ships and at shore-based facilities. The latest version of the
BEWT system is the BEWT II. The BEWT II adds capability, enhances fidelity of the training experience, and
significantly reduces production and sustainment costs by moving all the processes into a laptop and Integration
Management Unit (IMU).
3.2.1.3 CIAT, the Combined Integrated Air and Missile Defense (IAMD) and Anti-Submarine Warfare (ASW)
Trainer, will train AEGIS IAMD and ASW watch standers individually and as a team, in a high fidelity, shore-based
training environment that will replicate the environmental and tactical conditions of real world operations. The
trainer will require trainees to respond to the threats with approved Navy and Joint doctrine and capability as they
would in live combat operations.
3.2.1.4 Countermeasures include Nulka and other active and passive devices and capabilities that individually and as
a group are used by the ship to deflect or dissuade a hostile missile away from the ship. This training component
will be designed for integration into BEWT II and SEWTT.
3.2.1.5 BEWT and BEWT II ISEA Sustainment and support is provided to ship and shore as required to insure
uninterrupted operation of the training systems. This support includes telephone, email, and on-site as necessary;
depot level repair; and parts support.
C.3.2.2 Design and Implementation
(Applicable to CLINs 0001, and if exercised 1001, 2001, 3001, 4001)
The Contractor shall, adhering to the BFTT TRM (Attachment J-02), perform the system engineering design and
implementation required to design, develop, test, and deliver hardware and software and documentation changes to
update training system capabilities as directed in the TI. Systems engineering activities shall include: engineering
analyses to establish the technical approach and the integration requirements for training; pursue new technologies
beneficial to that tasking; development of the integration concept and alternatives; development of interface
hardware and software requirements and alternatives; development of Engineering Change Request (ECRs) for the
implementation of new capabilities or replacement of hardware/software for enhanced capabilities; and assessing
technical, cost, and schedule risks as directed in the TI. The Contractor shall update and revise, as tasked,
documentation provided under Attachment J-01 (GFI). In addition, the Contractor shall support, as directed in the
TI, the training system integrators and design agents in the integration of products into new and existing system
baselines.

(CDRLs A004, A005, A006, A007, A008, A009, A010, A011, A014, A015, A016, A017, A018)
C.3.2.3 Development Program Plan
(Applicable to CLINs 0001, and if exercised 1001, 2001, 3001, 4001)
The Contractor shall develop and deliver a Program Plan (PP) (CDRL A012) for each development TI executed.
(e.g. SEWTT, BEWT II, CIAT, and NULKA/Countermeasures). The PPs shall describe the specifics of how the
requirements will be executed, monitored, scheduled, and controlled. The PPs shall include:
 Organization Plan that outlines how information flows between internal stakeholders and how decisions are
made;
 Organization chart showing the management organization for implementation of the contract;

9
  Description of management tools for the purpose of evaluating status, early detection of problems and
problem resolution;
 Description of financial status and procedures for reporting work progress;
 Identification of project TPOC’s that are authorized by the Contractor to interface with the Program Office;
 Quality Assurance (QA) plan outlining the process that the Contractor will use to ensure software QA
process is implemented and maintained that, at a minimum, adheres to the requirements of ANSI/ISO/ASQ
9001-2008 Quality Management Systems;
 Address Risk Management (RM) outlining the process the Contractor will use to track, report and manage
and mitigate risk for each TI;
 Security Management (SM) plan outlining the procedures and processes the Contractor will impose to stay
consistent with the security classification guide and all appropriate security instructions.
C.3.2.4 Schedule & Cost Performance Reporting
(Applicable to CLINs 0001, and if exercised 1001, 2001, 3001, 4001)
To effectively manage the efforts assigned under this contract, the Contractor shall, in addition to the information
reporting identified in 3.1, implement an integrated schedule and cost performance reporting process.
Integrated Master Schedule (IMS) (CDRL A013) – The Contractor shall implement and maintain an IMS for each
development TI (e.g. SEWTT, CIAT, Countermeasures). The IMSs shall identify all development milestones, major
tasks, efforts, and activities necessary to successfully execute the tasks with estimated labor hours and costs
associated with each. The IMSs shall provide rigorous schedule management, facilitate the identification of task
interdependencies, and provide additional insight through the use of critical path analysis. The IMSs shall be
created in Microsoft Project, or Government approved substitute. The IMSs shall be reviewed at the semi-annual
PMRs with emphasis on approved changes, missed or potentially missed deadlines or deliveries, cost changes, risks,
and problem solving.
The Contractor shall report financial data IAW CDRL A001 under this contract operating IAW commercial
accounting standards as promulgated by the Financial Accounting Standards Board (FASB). The Contractor shall
provide this data electronically. The financial data shall be integrated with the IMS to provide the Government with
an integrated schedule and cost performance picture.
C.3.2.5 Open Systems Approach and Goals
(Applicable to CLINs 0001, and if exercised 1001, 2001, 3001, 4001)
In satisfying the Government’s requirements, the following system architecture approach characteristics shall be
utilized:
a. Open Architecture – 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.
i. Ensure that external information exchange requirements are implemented in a standard and open
manner as part of this effort. These actions shall include planning that identifies the contractor’s
specific approach to ensuring system and interface data is well-defined, available to all programs,
and uses a standards-based tool for definition within the context of DoD and Service upgrade
programs. The contractor shall develop system upgrades, IT system capabilities and business rules
that ensure that: 1) data will be posted to shared spaces for users to access and download except
when limited by security, policy, or regulations; 2) data shall provide for interoperability with
many-to-many exchanges of data, and verified trust and integrity of users and applications; and 3)
data, including applicable markings if any, shall be transmitted through well and openly defined
interfaces.
ii. The contractor shall ensure that its projects, at the architectural and operational level, continue to
promote the use of an open architecture as well as adoption of other standards and requirements,
tailored to meet its specific Military Service, Coalition and Joint Military Service requirements as
defined throughout this document.
b. Modular, Open Design – The contractor shall develop an architecture that is layered and modular and uses
standards-based Commercial-Off-The-Shelf (COTS)/Non-Developmental-Item (NDI) hardware, operating
systems, and middleware that all utilize either non-proprietary or non-vendor-unique key module or component
interfaces. The contractor’s design approach shall be applied to all subsystems and components. As part of its

10
 Open System Management Plan, the contractor shall, at a minimum, - describe how the proposed system
architecture meets these goals, including the steps taken to use non-proprietary or non-vendor unique COTS or
reusable NDI components wherever practicable.
i. Module Coupling – The contractor’s design approach shall result in loose coupling, minimal
dependencies on other modules, , as evidenced by simple, well- defined interfaces and by the
absence of implicit data sharing. The purpose is to ensure that any changes to one module will not
necessitate extensive changes to other modules, and hence facilitate module replacement and
system enhancement. The Contractor shall describe their approach used determine the level of
coupling and the design trade-off.
ii. Module Cohesion – The contractor’s design shall result in modules that are characterized by the
singular assignment of identifiable and discrete functionality. The purpose is to ensure that any
changes to system behavioral requirements can be accomplished by changing a minimum number
of modules within the system. The Contractor shall describe their approach used to determine the
level of cohesion and the design trade-off.
c. System Requirements Accountability – The contractor shall ensure that all system requirements (including
those contained in the Initial Capabilities Document, Capabilities Development Document, Capabilities
Production Document, and in this Section C) are accounted for through a demonstrated ability to trace each
requirement to one or more modules that consist of components that are self-contained elements with well-
defined, open and published interfaces implemented using open standards.
d. Inter-component Dependencies – The contractor’s designs shall result in a layered system design, maximizing
software independence from the hardware, thereby facilitating technology refresh. The design shall be
optimized at the lowest component level to minimize inter-component dependencies. The layered design shall
also isolate the application software layers from the infrastructure software (such as the operating system) to
enhance portability and to facilitate technology refresh. The design shall be able to survive a change to the
computing infrastructure with minimal or no changes required to the application logic. The interfaces between
the layers shall be built to open standards or the technical data describing the interface shall be available to the
Government with at least Government Purpose Rights. The system architecture shall minimize inter-component
dependencies to allow components to be decoupled and reused, where appropriate, across various DoD or
Service programs and platforms.
e. Modular Open Systems Approach (MOSA) – The contractor shall describe its rationale for the modularization
choices made to any designs generated on this contract. These components shall be of a size that supports
competitive acquisition as well as reuse. The contractor’s design approach shall emphasize the selection of
components that are available commercially or within the DoD, to avoid the need to redevelop products that
already exist and that can be reused. The contractor’s rationale shall explicitly address any tradeoffs performed,
particularly those that compromise the modular and open nature of the system.
f. MOSA Objectives – The contractor shall specify how it plans to use MOSA to enable all systems under the
subject contract to adapt to evolving requirements and threats; accelerate transition from science and technology
into technology and deployment; facilitate systems reconfiguration and integration; reduce the development
cycle time and total life cycle cost; maintain continued access to cutting edge technologies and products from
multiple suppliers; and mitigate the risks associated with: (1) technology obsolescence, (2) being locked into
proprietary or vendor-unique technology, and (3) reliance on a single source of supply over the life of the
system.
h. Design Information Documentation – The contractor shall document and model the system or component (e.g.,
software, hardware, middleware) design information using industry standard formats (e.g., Unified Modeling
Language). It shall also document and model how it will use tools that are capable of exporting model
information in a standard format (e.g., Extensible Markup Language Metadata Interchange (XMI) and
AP233/ISO 10303). The contractor shall identify the proposed standards and formats to be used. The contractor
shall maintain the design information, including any models used, so that the design information and models are
current with the as-built system.
i. Technology Insertion – The contractor’s architectural approach shall support the rapid and affordable insertion
and refreshment of technology through modular design, the use of open standards and open interfaces. The
contractor shall define the functional partitioning and the physical modularity of the system to facilitate future

11
 replacement of specific subsystems and components without impacting other parts of the system and to
encourage third-party vendor’s participation.
j. Life Cycle Sustainability – The contractor shall consider use of COTS/NDI and open standards to enhance the
system’s life cycle sustainability by implementing performance-based logistics (PBL) arrangements to sustain
the components through their life cycle.
k. Interface Design and Management – The contractor shall:
i. Clearly define and describe all component and system interfaces;
ii. Define and document all subsystem and configuration item (CI) level interfaces to provide full
functional, logical, and physical specifications;
iii. Identify processes for specifying the lowest level (i.e., subsystem or component) at and below
which it intends to control and define interfaces by proprietary or vendor-unique standards and the
impact of that upon its proposed logistics approach. Interfaces described shall include, but not be
limited to, mechanical, electrical (power and signal wiring), software, firmware, and hardware
interfaces;
iv. Identify the interface and data exchange standards between the component, module or system and
the interconnectivity or underlying information exchange medium;
v. Consider using these interfaces to support an overall information assurance strategy that
implements Information Assurance (IA) Processes in accordance with DoD Instruction 8500.2
(dated February 6, 2003).
vi. If applicable, select external interfaces from existing open or Government standards with an
emphasis on enterprise-level interoperability. The contractor shall describe how its selection of
interfaces will maximize the ability of the system to easily accommodate technology insertion
(both hardware and software) and facilitate the insertion of alternative or reusable modular system
elements;
vii. Describe the extent that the change or configuration management process proposed will use
“community of interest” teams in an integrated team approach to effectively identify how
individual changes impact the system’s internal or external interfaces and information exchange
standards.
l. Treatment of Proprietary or Vendor-Unique Elements – The contractor shall explain the use of proprietary,
vendor-unique or closed components or interfaces. If applicable, the contractor shall define its process for
identifying and justifying proprietary, vendor-unique or closed interfaces, code modules, hardware, firmware, or
software to be used. When interfaces, hardware, firmware, or modules that are proprietary or vendor-unique are
required, the contractor shall demonstrate to the Government that those proprietary elements do not preclude or
hinder other component or module developers from interfacing with or otherwise developing, replacing, or
upgrading open parts of the system.
m. As Built Configuration List Identification of Modification Items and Funding Source – The contractor shall
prepare and deliver a comprehensive list of items (to include parts, components, sub- assemblies, assemblies,
SRUs and LRUs) that during or in connection with the performance of the contract that are new or have been
redesigned, modified, or otherwise changed. Such list shall be specific as to description, nomenclature, part
number, higher order subassembly or assembly, the nature of the redesign, modification or other change. In
addition, and as specific and discrete task requirements of this contract, the contractor shall further identify in
the ABCL, with respect to each such listed new, redesigned, modified, or changed item, the purpose of the
redesign, modification or other change and the source of both the requirement and the funding for such
redesign, modification or other change. In identifying the funding source, the contractor shall, in the case of
each redesign modification, or other change funded in whole or in part with government funding, specifically
identify the contract, line item, and ACRN which funded or partially funded the redesign, modification, or other
change.
n. Open Business Practices – The contractor shall demonstrate that the modularity of the system design promotes
the identification of multiple sources of supply and/or repair, and supports flexible business strategies that
enhance subcontractor competition. The contractor shall conduct a market survey to identify candidate COTS,
proprietary, open source software (OSS) and other reusable NDI capable of achieving the performance
requirements of solutions that it proposes to custom build. The survey results shall be provided to support each
major review. COTS and other reusable NDI selection criteria shall address the following factors, at a
minimum: Electrostatic Sensitive Device (ESD) immunity; Electromagnetic Interference/Electromagnetic

12
 Compatibility (EMI/EMC); Integrated Logistics Support requirements; safety; reliability consistent with the
environment described in the System Specification; maintainability; subsystem performance trade-offs; power,
cooling, and physical form factors; open system architecture break out compatibility; cost; manufacturer’s
quality assurance provisions; market acceptability; obsolescence; adequacy of available technical and
intellectual property data and re-procurement data rights on the product; and merits of the software supported by
the product. Decisions leading to the selection of specific COTS, NDI, proprietary or OSS products should be
supported by appropriate analysis (e.g., with test results, architectural suitability, “best value” assessments, etc.).
o. Reuse of Pre-existing or Common Items – The contractor shall reuse pre-existing or common items unless a
determination is made to not reuse. Exceptions to reuse of pre-existing items must be accompanied by
justification, such as cost (both of adoption and life cycle support), schedule, functional and non-functional
performance, etc. The general objective of these efforts shall be the development of a common system and/or
common elements or components which meet the performance requirements of the various DoD or Service
platform missions, where commonality offers the greatest technical and cost benefits.
p. Third-Party Development – The contractor shall address how it will provide to the Government information
needed to support third-party development and delivery of competitive alternatives of designs for software or
other components or modules on an ongoing basis. The contractor shall provide a list of those proprietary,
vendor-unique elements that it requests be exempt from this review.
q. Life Cycle Management and Open Systems – The contractor’s architecture shall provide for insertion of COTS
into the system and demonstrate that COTS, reusable NDI, and other components are logistically supported
throughout the life cycle. The contractor shall describe and demonstrate the strategy for reducing product or
system and associated supportability costs through insertion of COTS and other reusable COTS or NDI
products. The contractor shall establish a process to logistically support COTS or NDI products. The contractor
shall describe the availability of commercial repair parts and repair services, facilities, and manpower required
for life cycle support and demonstrate they are adequate to ensure long term support for COTS or NDI products.
The contractor shall provide the proposed methodology for pass through of COTS warranties to the
Government.
r. Use of Standards – In designing the system(s), the contractor shall use the following standards in descending
order of importance:
i. Standards as specified within the contract
ii. Commercial standards
a) Standards developed by international or national industry standards bodies that have been widely
adopted by industry. Examples of widely adopted standards are:
1) SQL for databases (e.g., SQL for databases ANSI ISO/IEC 9075-1, ISO/IEC 9075-2, ISO/IEC
9075-3, ISO/IEC 9075-4, ISO/IEC 9075-5)
2) HTML for presentation layer (e.g., XML 1.0 www.webstandards.org)
3) XML for data transfer
4) Web services for remote system calls
b) Standards adopted by industry consensus-based standard bodies and widely adopted in the market
place.
c) De facto standards (those widely adopted and supported in the market place).
Note: Standards that are not specified within this contract or that are modified must be submitted to and
approved by the Government Program Manager prior to use.
C.3.2.6 Software Design, Development, Test and Certification
(Applicable to CLINs 0001, and if exercised 1001, 2001, 3001, 4001)
The Contractor shall produce and deliver to the Government updated models, build scripts, source code, operations
and support documents, executables, make files, software product specifications, and SVDs necessary for the
Government to compile, produce, test and deliver media for ships/sites in support of the tasks in this SOW. The
Contractor shall document this activity and deliver it as a part of the delivered Computer Program End Item or a
Scientific and Technical Report. (Note – CDRL A028, A029, A044 shall include the following items: a) software
code and associated documentation, b) models and simulations with associated manuals, c) tools and associated
manuals, d) development environment and instructions [ e.g., scripts, make file, etc.], e) software licenses, f)
scenarios, and g) MsgDefs (message definitions)). The Contractor shall produce and deliver to the Government
updated software product specification, technical functional scripts, test data sets, software test procedures,
functional prototype demonstration results, development objects, reusable learning objects, training documentation

13
source material in order to complete the development or specified task, and deliver these items to the Government
via a Scientific and Technical Report CDRL A044. The Contractor shall assist the Government with the setup of an
environment to compile/reproduce the software program.
3.2.6.1 The Contractor shall perform unit level, component level, CSCI level, System Integration, and Formal
Qualification testing IAW the tasks SDP, STP and STD. The Contractor shall provide documentation in support of
test planning, test events and test execution.
The following describes a minimum set of documentation in support of each developmental task to be provided by
the Contractor for Government review and acceptance IAW the testing tasks identified in the IMS. Additional
documentation may be required. Should a timing conflict occur between any combat system joint test events or
element certification events requiring any artifacts sooner than required IAW the BFTT tailored TRM Attachment J-
02, the joint test event or element certification event takes precedence.
 Software Development Plan (SDP) – CDRL A016
 Software Test Plan (STP) – CDRL A039
 Software Test Description (STD) – CDRL A005
 Test Procedures – CDRL A007
 Software Trouble Report Status – CDRL A035
 Hardware Trouble Report Status – CDRL A036
 Software Product Specification (SPS) – CDRL A037
 Failure Summary and Analysis Report – CDRL A051
3.2.6.2 The Contractor shall notify the Government to include the COR and TI identified Technical Point of Contact
(TPOC) when high priority Trouble Reports (TRs) are discovered or reported. Each problem shall be classified by
category (computer program, computer program documentation, equipment, etc.), by Trouble Report (TR)
Consequence (1, 2, 3, 4, 5) and by Likelihood of Occurrence (A, B, C, D, E) from the Warfare System Certification
Policy, NAVSEAINST 9410.2A, Appendix D. The Contractor shall assess TRs and provide recommendations to
the Government for correction or implementation. An assessment of the cumulative effects of related lower priority
TRs shall also be performed and reported. (CDRL A035)
Trouble report (TR) Prioritization
Priority 1 This priority denotes a problem that prevents accomplishment of essential capability or jeopardizes
safety, or other requirement designated as Critical
Priority 2 This priority denotes a problem that adversely affects the accomplishment of an essential capability
or adversely affects costs, technical or scheduled risks to the project or to the life cycle support of
the system and no work around solution is known
Priority 3 This priority denotes a problem that adversely affects the accomplishment of an essential capability
or adversely affects costs, technical or scheduled risks to the project or to the life cycle support of
the system and a work around solution is known
Priority 4 This priority denotes a problem that results in operator inconvenience or annoyance but does not
affect a required operational or mission essential capability or results in inconvenience or
annoyance for development or maintenance personnel but does not prevent the accomplishment of
the responsibilities of those personnel
Priority 5 This priority denotes any other condition
3.2.6.3 The Contractor shall resolve high priority TRs and implement required modifications and updates followed
by regression testing to insure TR has been resolved. Medium and low priority TRs (3’s and 4’s) shall be corrected
as directed by the Government. The Contractor shall plan and conduct testing to ensure the computer program items
meet the system and subsystem specification requirements.
3.2.6.4 The Contractor shall develop and maintain a Software Trouble Report database to track all TRs. The
Contractor shall provide the Government access to the Contractor developed TR Database. The Contractor shall
utilize the database as an engineering tool for tracking and resolving each problem detected, beginning with the Test
& Integration Phase and continuing through FQT, in the computer program under Contractor configuration control.
Inputs to the computer program corrective action system shall consist of TRs and change documentation. The
system shall be closed loop, ensuring all detected problems are promptly reported and entered into the system, action

14
initiated on them, resolution achieved, and status tracked. The Contractor shall have remote electronic read and
write access to the Government’s TR database for the duration of this contract. (CDRLs A035, A036)
3.2.6.5 The Contractor shall maintain Information Security policies and procedures in accordance with appropriate
sections of CNSSI No.1253, the Federal Information Processing Standards Publication (FIPS PUB) 140-2, the
National Industrial Security Program Operating Manual (NISPOM), and meet Defense Security System (DSS)
certifications where applicable.
The Contractor shall identify all critical program information to support inclusion of future anti-tamper designs.
The Contractor shall coordinate the design of all system software in a manner that allows successful testing and
certification of the system in accordance with its Cybersecurity requirements. All aspects of Cybersecurity shall be
followed. The Contractor solutions shall provide for sensitive but classified and/or unclassified information in
accordance with the standards set forth in DoD security policies, and shall satisfy all applicable DoDI 8500.1,
8510.01, and CNSSI No. 1253 data security requirements and Security Technical Implementation Guides from the
Defense Information Systems Agency (DISA). Vulnerabilities associated with protection of sensitive data will not
be accepted. Classified data shall be protected in accordance with NISPOM.
C.3.2.7 Upgrades to Address Obsolescence Issues, Maintenance, Repair and ISEA Support
(Applicable to CLINs 0007, and if exercised 1007, 2007, 3007 and 4007)
Tasking will be directed by the Government through the use of TIs as defined in Section H of this document.

3.2.7.1 The Contractor shall provide maintenance support, trouble shooting, and technical assistance for training
systems installed on ships and at shore sites. As directed in the TI, the Contractor shall produce, test, and deliver
training system upgrade kits to ships and shore sites as directed by the Government. As directed in the TI, the
Contractor shall retrofit existing training systems IAW Government approved ECPs.
3.2.7.2 The Contractor shall provide systems engineering support, to include legacy BEWT, BEWT II, CIAT, and
SEWTT ISEA, for ship and shore systems to insure uninterrupted operation. This support includes telephone, email,
and on-site as necessary; depot level repair; and parts support. As directed in the TI, the contractor shall provide
maintenance support, trouble shooting, and technical assistance for BEWT, BEWT II, CIAT and SEWTT
installed on ships and at shore sites.
(CDRLs A009, A010, A011)
3.2.7.3 The Contractor shall establish and maintain an inventory control process using COR approved computer-
based application software programs for all program material and equipment. The Contractor shall manage, catalog,
receive, store, transfer, and dispose / de-mil material IAW DoD and US Navy instructions. Storage of Government
Furnished Parts, and storage of Government Furnished systems, efforts related to diminishing manufacturing
sources, efforts related to disposal/de-mil material are allocable to this CLIN. The Contractor shall maintain an Item
Unique Identifier (IUID) marking as defined in the reference(s) in Section C.2 and in accordance with DFARS
252.211-7003 “ITEM IDENTIFICATION AND VALUATION (JUN 2011)” for all items held under the control of
the Contractor. Government Furnished Property (GFP) and Government Furnished Material (GFM) under the
control of the Contractor must be reported quarterly to the COR.
(CDRLs A030)
C.3.2.8 Government Furnished Material (GFM) Storage
(Applicable to CLINs 0006 and if exercised 1006, 2006, 3006 and 4006)
The Contractor shall provide and maintain insured and bonded storage facilities for Government property pending
use, repair, disposal or shipment to designated recipient. Storage of Government Furnished Parts, and storage of
Government Furnished systems, efforts related to diminishing manufacturing sources, efforts related to disposal/de-
mil material are allocable to this CLIN. The Contractor shall only direct charge the allocable storage cost of
GFM/GFE/GFP material prior to Government specified quantities being transferred for use on production CLINs.
C.3.2.9 Material
(Item 0003, and if exercised1003, 2003, 3003 and 4003)
The Contractor shall be reimbursed on a cost-only basis (no fee) for all allowable and allocable costs associated with
the procurement of materials for other than Firm Fixed Price (FFP) production. These costs include 3 rd Party
Software Licenses. The Contractor shall make use of any available license through the DoD Enterprise Software
Initiative (ESI) to the maximum extent possible (http://www.esi.mil/LandingZone.aspx?id=102&zid=1). Includes,

15
but not limited to, ODCs incidental to work performed under CLINs 0001, and if exercised 1001, 2001, 3001 and
4001. TIs will be used by the Government to direct the procurement of ODCs. The tasking provided in the TIs to
procure ODCs shall include and are not limited to; cost of shipping of Government Furnished parts, cost of shipping
of Government Furnished systems, and the cost of shipping post Government acceptance production systems
completed under CLIN 0005, 1005, 2005, 3005 and 4005.
C.3.2.10 Travel
(Item 0004, and if exercised 1004, 2004, 3004 and 4004)
The Contractor shall travel throughout the Continental United States (CONUS) and to foreign countries (OCONUS)
in support of this contract as directed via TI in accordance with HQ B-2-0020.
In order to minimize travel costs, the Contractor and its subcontractors at all tiers shall comply with DoD Joint
Travel Regulations (JTR) in conducting travel of employees. All travel shall be conducted IAW the JTR.

C.3.3 PRODUCTION (FFP)

C.3.3.1 First Article Unit Production (CLIN 0008)
The Contractor shall produce, test, and deliver first article unit consistent with the, system specifications, and Build-
to-Print documentation provided in Section J Attachment J-01-2. The Contractor shall perform First Article testing
using Attachment J-04, BEWT II Production Test Procedures with Instructions and in accordance with Federal
Acquisition Regulation (FAR) 52.209-3. The Contractor shall develop and deliver test reports to the TPOC and the
Contracting Officers Representative (COR) indicated on the TI in accordance with CDRL A036.
C.3.3.2 Training System Production
(If exercised CLINs 0005, 1005, 2005, 3005 and 4005)
The Contractor shall produce, test, and deliver training systems consistent with the system specifications and
technical direction identified in the Build-to-Print documentation provided in Section J Attachment J-01-2 and J-04.
The Contractor shall implement and maintain a UIID marking as required by DFARS 252.211-7003 “ITEM
UNIQUE IDENTIFICATION AND VALUATION (JUN 2011).” System baseline, software version, delivery date
and receiving location shall be as directed in the modification exercising the option for each system.
The Contractor shall evaluate all Cyber Security guidance changes discovered under C.3.1.5 for impact to system
production. Any required design changes shall be documented in the Engineering Change Process (ECP) and
submitted to the Government using the established process.
The BEWT II system is Grade B Shock, Power Qualification, and EMI certified in accordance with MIL-S-901D,
Medium Weight Shock Machine (MWSM), Grade B, Type A, Class I equipment; MIL-STD-1399, Section 300B;
and MIL-STD-461 F (Surface Ships).
The Contractor shall perform Production Acceptance Testing (PAT) using Attachment J-04, BEWT II Production
FAT Procedures.
(CDRLs A004, A005, A006, A007, A008, A009, A010, A011, A014, A015, A016, A017, A018)

16