Attachment_1_-_Draft_Statement_of_Work_-_EWTS.docx

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.

C.2.1 Cyber Security

SECNAV M-5239.2 DON Cyberspace Information Technology (IT) and CSWF Management and Qualification Manual, 27 Jun 2016

X

NAVSEAINST 9400.02A NAVSEA PIT Control Systems Cybersecurity Governance and Guidance, 20 Sep 16

X

DoD Manual 8570.1-M, Information Assurance Workforce Improvement Program of 19 Dec 05 (Incorporating Change 4, 10 Nov 2015)

X

Total Ship Test Program Manual, NAVSEAINST S9095 AD-TRQ-010/TSTP

X

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 2016

X

SECNAV M-5510.36 DON Information Security Program Manual, June 2006

X

DONCIO Memo – DON Implementation of the Risk Management Framework (RMF) for DOD Information Technology, 20 May 2014

X

DONCIO Memo - RMF Process Guide v1.0, 13 Dec 2016

X

C.2.2 System Safety

NAVSEA INST 9410.2A NSWC Certification Policy, Risk Assessments, Software Trouble Reports

X

NAVSEA PEO IWS Instruction 5000.8 NAVSEA PEO IWS Risk Management Policy (Standard Chemical Avoidance)

X

Navy Weapon System Safety Program, NAVSEAINST 8020.6E, X

MIL STD 6016F Interoperability / Force Level Safety

X

JSWRB / JS-SSA Joint Service Weapon Safety Review Board (JSWRB) Endorsement of Joint Services Software Safety Authority (JS-SSA)

X

NOSSA Letter N32-1581 dated 10 Oct 08 Department of Navy Systems Of Systems (SOS)

X

OPNAV INST 5100.24C Environmental Safety Occupational and Health Considerations in Navy Capabilities and Systems Engineering Process

X

NAVSEA OP 5, Vol 1, Revision 7, Ch 14 Ammunition and Explosives Safety Ashore

X

NAVSEA INST OP 4 NAVSEA Explosives Safety Afloat

X

OPNAV INST 5100.23G Navy Occupational Safety and Health Program Manual

X

Joint Software Systems Safety Engineering Military Handbook 454B DoD Handbook Guidance on Software Safety Design

X

NAVSEA S2020-AH-SAF-010 Guidelines for Electronic Equipment

X

OPNAV INST 5100.24C Environmental Safety Occupational and Health Considerations in Navy Capabilities and Systems Engineering Processes

X

Allied Ordnance Publication (AOP 52) Assessment of Munitions Related Computing Systems North Atlantic Treaty Organization (NATO) (SSSTRP requested Architectural Analysis, via MIL STD 882E, Task 205)

X

C.2.3 Test & Evaluation

NAVSEA Instruction 9410.2A, Naval Warfare Systems Certification Policy (NWSCP)

X

PEO IWS Instruction 4730.1A, Combat System Certification Process, January 2005

X

PEOIWS Training Systems Directorate, Training Systems Certification Process, December, 2009

X

Incorporating Test and Evaluation into Department of Defense Acquisition Contracts Guide of October 2011

X

PEOIWSINST 4130.1B, IWS Enterprise Configuration Control Process (ECCP), SEP 14, 2011

X

PEO IWS Instruction 4732.1, Element Certification policy (Draft)

X

PEO IWS Instruction 4731.1, Combat System Stress and Endurance Test Requirements for Surface Programs (Draft)

X

S9095-AD-TRQ-010/TSTP Total Ship Test Program (TSTP) MIL-HDBK-61(SE) Configuration Management Guidance (para 6.2 and 6.3)

X

C.2.4 Logistics

DoD Guide to Uniquely Identifying Items, v2.5 September 15, 2012

X

NAVSO P-3692 Department of the Navy Guide for Conducting Independent Logistics Assessment, Revision 8, September 2012

X

Government Electronics and Information Technology Association (GEIA) SAE-GEIA-STD-0007, “Logistics Product Data” 1 AUG 2007

X

C.2.5 Systems Engineering

C.2.6 Software Engineering

C.2.7 Human System Engineering

MIL-HDBK-1908B NOTE 1

X

BFTT Human Intergration - Computer Interface (HCI) Design Guide

X

Workstation Production Methodology and Programmer’s Handbook, Revision 2, 01 March 2004

X

C.2.8 EW Training Systems Documents

BFTT T46D System Hardware Description and Operational Overview, Version P, 26 March 2013

X

C.2.9 Other Government Documents

BFTT Operational Requirement Document (ORD) 21 March 1992

X

C.2.10 Commercial Standards and Specifications

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 janel.duval@navy.mil)

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 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

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, 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, 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),

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;

· 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 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 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 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 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

·…