Attachment_1_-_Statement_of_Work.pdf

N00024-16-R-6418

14 FEB 2017

i

ATTACHMENT 1

STATEMENT OF WORK

FOR THE

INTER SUBSYSTEM MONITORING TOOL

AND

ON-BOARD TEAM TRAINER – MASTER CONTROLLER

DEPARTMENT OF THE NAVY

PROGRAM EXECUTIVE OFFICER, SUBMARINES (PMS 425)

1333 ISAAC HULL AVENUE SE

WASHINGTON, NAVY YARD

WASHINGTON, DC, 20376

14 February 2017 ii

TABLE OF CONTENTS

1 SCOPE

1.1 Background

1.1.1 Navy Organization

1.1.2 Program Background

1.1.3 The Collaborative Development Environment

1.2 Program Phasing

2 APPLICABLE DOCUMENTS

2.1 Applicable Documents

3 REQUIREMENTS

3.1 Program and Contract Management

3.1.1 Progress Reporting

3.1.2 Subcontract Management and Control

3.1.3 Contract Work Breakdown Structure

3.1.4 Integrated Master Schedule

3.1.5 Program Management Reviews

3.1.6 Data Management

3.1.7 PKIs

3.1.8 Government Witness Activities

3.1.9 GFI

3.1.10 GFP

3.2 Systems Engineering

3.2.1 Systems Engineering Management

3.2.2 Modular Open Systems Architecture Approach

3.2.3 System Engineering and Design Analyses

3.2.4 Software Design Requirements

3.2.5 Technical Reviews

3.2.6 Integrated Product Teams

3.3 SYSTEM DEVELOPMENT

3.3.1 Software Engineering

3.3.2 Problem Reporting System

3.3.3 System Integration Planning

3.3.4 T&E Program Plan

3.3.5 Test Requirements

3.3.6 Test Documentation

3.4 Test and Evaluation

3.4.1 Test Conduct

3.4.2 Testing Support to the Government

3.4.3 Software Development Files

3.4.4 Software Deliveries

3.5 Integrated Logistics Support

3.5.1 IETM Source Data

3.6 Facilities

3.7 Platform Integration

3.7.1 System Delivery

3.8 Studies and Analyses

3.9 Contract Security Requirements

3.10 Configuration Management

3.10.1 ECPs and NORs

3.10.2 Requests for Variance

3.10.3 Specification Change Notice

iii

3.11 Risk Management

3.12 Quality Assurance

3.13 Information Assurance

ATTACHMENT 1

STATEMENT OF WORK FOR THE

INTER SUBSYSTEM MONITORING TOOL AND

ON-BOARD TEAM TRAINER – MASTER CONTROLLER

1 SCOPE

This Statement of Work (SOW) describes the efforts for the program management, systems engineering, software engineering, configuration management, quality assurance, test and evaluation, logistics and supportability engineering for the Inter Subsystem Monitoring Tool (ISMT) and On-Board Team Trainer – Master Controller (OBTT-MC) for Technology Insertion (TI)-2018 Advanced Processor Build (APB)-2017, TI-18 APB-19, TI-20 APB-19, TI-20 APB-21 and TI-22 APB 21. ISMT and OBTT-MC will be integrated into the Common Infrastructure Services (CIS) subsystem on SSN688I, SSGN, SSN21, SSBN, VIRGINIA, OHIO Replacement, and Royal Australian Navy (RAN) Collins Class Submarines. The OBTT products is not currently applicable for RAN Collins Class. CIS is being developed as a new independent subsystem within the Submarine Warfare Federated Tactical System (SWFTS), and will be provided hotel services within the AN/BYG-1 Submarine Combat and Weapons Control System shipboard physical footprint. Specific efforts include:

Maintain the software baselines for ISMT and OBTT-MC and provide “end-to-end” system engineering development, integration, test, and life cycle support for the ISMT and OBTT-MC application capability for the duration of this Period of Performance (PoP)

Incrementally develop ISMT and OBTT-MC configuration variants to support the various platforms as required. Each initial delivery will include all baseline engineering documentation, product lists and, logistics support products as necessary to provide the “as developed” product support, including Trainers.

Define the interface baseline including all requirements necessary to connect to the SWFTS network and share information.

Develop source material for Logistics Data, Interactive Electronic Technical Manual (IETM), Interactive Courseware (ICW)/Computer Based Training (CBT) and Interactive Multimedia Instruction (IMI) using Navy approved common authoring systems and formats to allow for efficient integration with SWFTS.

Support installation and field integration as required.

Provide a common build environment for the development, integration, and implementation of the ISMT and OBTT-MC into supported platforms.

Perform technical reviews and provide recommendations on actions and approaches needed to achieve program requirements as well as provide and assist as necessary any lab support needed to support software development and integration of the ISMT and OBTT-MC applications.

Provide support for design, development, and integration of program requested improvements to the ISMT and OBTT-MC capability to enhance System of Systems (SoS) Maintainability and reduce SoS fault and failure recovery time, and reduce underway manning required to train while increasing training proficiency, respectively.

Provide engineering services to support ISMT and OBTT-MC improvements and updates that include but are not limited to:

Porting the ISMT and OBTT-MC applications to new operating environments in support of the TI/APB process Supporting new SWFTS interfaces and subsystems

Perform integration and test services in support of the integration of the ISMT and OBTT-MC applications into CIS and SWFTS.

1.1 Background

1.1.1 Navy Organization

Program Executive Officer, Submarines (PEO SUB) is the acquisition executive for this procurement. The Submarine Combat and Weapon Control Systems Program Office (PMS 425), in partnership with PEO SUB-SWFTS (SUB-S), is responsible for the acquisition, development, production, fleet introduction and support of the CIS system for all U.S. Navy submarines. Under a cooperative development program with RAN, ISMT development, test, integration and life-cycle support efforts under this acquisition will also support RAN Collins Class submarines.

1.1.2 Program Background

In a joint collaborative development environment, PMS425 and PEO Integrated Warfare Systems (IWS) 5A, established a Combat Systems Research and Development (R&D) Model to facilitate the rapid transition of Advanced Development products to the fleet into certified operational combat systems. This concept was first instituted in Acoustics Systems with dramatic successful results. A pre-requisite to achieving this success was the development of an Open System Architecture (OSA) Commercial-Off-The-Shelf (COTS) based “landing pad” to introduce advanced development products. Additionally, Open Business practices and processes in and Integrated Product and Process Development (IPPD) culture were formed that would allow for streamlined cooperative development strategies and efficient transition activities to apply Advanced Development, Advanced Processing Builds (APB) product integration with baseline systems. The outcome of this procurement is intended to provide facilities for the system engineering, integration, and testing of the ISMT and also to provide support to the operating Fleet and its land based support activities.

1.1.3 The Collaborative Development Environment

The Contractor shall incorporate changes required to support new capabilities being developed by IWS5 and/or other Government entities as part of the APB development and integration process, as well as part of non-APB year production proceses.

For ISMT, the Contractor is responsible for providing SoS fault recovery and other maintainability information to aid the fleet in recovering interfaces and functions developed by third (3rd) parties.

For OBTT-MC, the Contractor is responsible for receiving and integrating databases of information from third (3rd) parties and is required to be interoperable with current subsystem On-Board Trainers OBTs. It is essential the Contractor be able to effectively and efficiently work in a collaborative environment with a consortium of Navy, Navy Laboratories, Academia, and other industry partners to ensure continued success of the program.

1.2 Program Phasing

The Contractor shall support new development and legacy ISMT and OBTT-MC efforts for the SSN688I, SSGN, SSN21, SSBN, VIRGINIA, OHIO Replacement, and Royal Australian Navy (RAN) Collins Class Submarines.

The scope of services required to design, develop, deliver and support each ISMT and OBTT-MC TI/APB configuration under this procurement is proportional to the number of different combat system configurations undergoing modernization change or requiring new construction installation over the seven (7) year PoP of this contract.

Figure one (1) shown below is the expected development schedule and variants across planned contract years. All baselines shall be supported over the contract PoP.

Sept

Dec

Jan

Apr

May

Aug

Sept

Dec

Jan

Apr

May

Aug

Sept

Dec

Jan

Apr

May

Aug

Sept

Dec

Jan

Apr

May

Aug

Sept

Dec

Jan

Apr

May

Aug

Sept

Dec

Jan

Apr

May

Aug

Sept

Dec

Jan

Apr

May

Aug

TI‐18/APB17

TI‐18/APB19

TI‐20/ APB19

TI‐20/APB21

TI‐22/APB21

Contract CLINs Option Year 6

CLIN 0601

CLIN 0603

(V) 2, 5, 6, 8

(V) 2, 5,7, 8

(V) 2, 5, 7, 8

(V) 1, 9, 10, 11

(V) 1, 9, 10, 11

Base

CLIN 0001

CLIN 0005

Option Year 1

CLIN 0101

CLIN 0103

Option Year 2

CLIN 0201

CLIN 0203

Option Year 3

CLIN 0301

CLIN 0303

Option Year 4

CLIN 0401

CLIN 0403

Option Year 5

CLIN 0501

CLIN 0503

Figure 1: ISMT and OBTT-MC Configuration, Variants and Contract Years

NOTE: The number of variants in each TI/APB is subject to change depending on platform modernization schedules.

2 APPLICABLE DOCUMENTS

ISMT and OBTT-MC work required by this contract shall meet the requirements of the ISMT and OBTT-MC System/Subsystem Specifications (SSS) and the System Performance Specification (P- SPEC) for CIS Subsystem and shall be performed in accordance with this SOW and SOW Appendices, Other Documents/Exhibits/Attachments listed in Section J and all provisions of this contract.

2.1 Applicable Documents

The Military Specifications, Standards, and Handbooks referenced within this SOW are provided as guidance only and are a basic framework for defining task areas. This SOW will require the Contractor (as applicable) to provide best commercial standards and practices to meet the overall specifications in the system, and provide copies of license agreements related to the use of these components for Government Performance Objectives. Additional Specifications, Standards, and Handbooks might be referenced in individual Technical Instructions.

2.1.1.1 GOVERNMENT DOCUMENTS

The following documents are applicable to this SOW and attached appendices to the extent specified herein.

AN/BYG-1 MOU Amendment 1 November 2009 Memorandum of Understanding between the

Department of Defense of the United States of America and the Department of Defence of Austalia for the Cooperative Development Production and Support of The AN/BYG-1 Tactical and Wespon Control System

MIL-HDBK-61A

7 February 2001

Military Handbook: Configuration Management Guidance

NAVSEAINST 9410.02A

24 Aug 2012

Naval Warfare Systems Certification Policy

PMS425 WBS

11 March 2014

PMS425 Work Breakdown Structure (WBS)

PMS425 IMP

14 November 2016

PMS425 Integrated Master Plan (IMP), Rev.M

PMS425 Risk Management Plan May 2013

Submarine Combat and Weapon Control System Program Office Risk Management Plan Version 1.0

PMS425 CM Plan 11 February 2014

Configuration Management Plan, Version 1.0.0

PMS425 SEP

15 December 2015

Systems Engineering Plan (SEP), Version 1.1.3

PMS425 ltr Ser 425/0092 dated 23 March 2015

Information Assurance Vulnerability Management Policy for SWFTS

COMNAVNETWARCOM

Communications Tasking Order

(CTO) 11-16A

September 2011

Secure Configuration Compliance Validation Initiative and Vulnerability Remediation Asset Manager (VRAM) Requirements

DODD 8500.01

14 March 2014

Information Assurance (IA)

DOD 8570.01-M

19 December 2005

Information Assurance Workforce Improvement Program

ISO/IEC/IEEE 12207-2008

21 March 2008

ISO/IEC/IEEE Standard for Systems and Software Engineering – Software Life Cycle Processes

OSA Guidebook 13 June 2013

DoD Open System Architecture Contract Guidebook, v1.1

MIL-STD-881C

3 October 2011

Work Breakdown Structures for Defense Materiel Items

MIL-STD-882E

11 May 2012

Standard Practice for System Safety

NAS411 thru Rev. 3 30 September 2013

Hazardous Materials Management Program

NAVSEA 9400.2

18 August 2010

Implementation of NAVSEA Afloat IA Governance and Guidance

2.1.1.2 NON-GOVERNMENT DOCUMENTS

IEEE/EIA 12207.0/1/2 Software life cycle processes; March 1998 and life cycle data; implementation April 1998 considerations

ANSI/EIA-632-1999 Processes for Engineering a System

3 REQUIREMENTS

To support the entire range of potential tasks envisioned under this contract, this section of the SOW supports requirements definition and the conduct of design, development, subsystem and SoS integration, test, logistics and system support. The resulting contract will utilize Technical Instruction(TI) signed by the Contracting Officer’s Representative (COR) and the PCO to provide clarifying information regarding this SOW. Upon issuance of an approved TI, the Contractor is authorized to perform the requirements of this SOW without further direction from the COR.

3.1 Program and Contract Management

The Contractor shall designate a Program Manager (PM) who shall have responsibility for all aspects of this contract and shall possess the authority to commit the Contractor to specific courses of action. The Contractor shall organize, coordinate, control and report the status of all contract activities related to this contract, and shall be responsible for activities assigned to its subcontractors to ensure the delivery of all supplies and services specified in this contract and any resultant TIs.

3.1.1 Progress Reporting

The Contractor shall prepare and deliver monthly Progress, Status and Management Reports to provide status of all assigned tasks, report progress against milestones, report progress against contract incentives and identify technical or schedule problem areas or risks along with recommendations for resolution [CDRL A001]. The progress reports shall be broken out for ISMT and OBTT-MC, and includes each TI/APB. The progress report shall include the following financial data:

a. Planned hours and cost to date by month (Budgeted Cost for Work Scheduled

(BCWS))

b. Actual hours and cost incurred to date by month (Actual Cost of Work Performed

(ACWP))

c. Estimated remaining cost to complete assigned tasking by month (Estimate to Completion (ETC))

d. Actual costs plus ETC (Estimate at Comletion (EAC)) for the fiscal year

The Contractor shall prepare an informal weekly progress report for submission to the Government.

This report shall document the accomplishments and progress with respect to the Government approved Integrated Master Schedule (IMS) as described in Section 3.1.4 and shall be broken out by each major effort that includes each TI/APB. This report shall identify issues or obstacles impeding progress and recommended solutions or current plans to resolve these issues or mitigate their impacts. This report shall also include other topics or issues as identified by the Government COR. The report shall be submitted in electronic form using Microsoft Outlook compatible format or other format as agreed upon between the Contractor and the Government.

3.1.2 Subcontract Management and Control

The Contractor shall identify and monitor subcontractor technical, quality, schedule, and milestone achievement on a continuing basis, according to the Contractor’s own established subcontract management techniques. The Contractor shall invite Government contracting and technical representatives to participate in subcontractor visits and reviews. The Contractor shall provide fifteen (15) working days advance notice to the PCO and designated Government technical representatives prior to planned subcontractor visits and reviews. Attendance at these reviews or tests is optional on the part of the Government, and failure of the Government representative to attend shall not constitute an excusable delay on the part of the Contractor.

3.1.3 Contract Work Breakdown Structure

The Contractor shall ensure the Contract Work Breakdown Structure (CWBS) extends down to the appropriate level required to provide adequate internal management, surveillance, performance measurement and financial management, regardless of the reporting level stipulated in the Contract for Government visibility. The Contractor shall analyze the system requirements specified in the SOW and system specification and shall use the PMS425 Work Breakdown Structure (WBS) as guidance to create a CWBS structure representing the products and services that comprise the entire work effort under the contract. The Contractor, if necessary, shall update the CWBS during the execution of the contract. Changes to the CWBS or associated definitions, at any reporting level, require approval of the Government.[CDRL A002]

3.1.4 Integrated Master Schedule

The IMS shall consist of key ISMT and OBTT-MC program milestones, as derived from the PMS425 Integrated Master Plan (IMP) provided as Government Furnished Information (GFI) (Attachment 2). The IMS shall also include specific lower-level milestones for each TI/APB baseline consistent with the CWBS and as mutually agreed upon between the Contractor and the Government. The IMS shall include efforts of all activities including subcontractors. Events of particular interest to the Government include, but are not limited to: 1) acceptance of GFI 2) program reviews 3) technical reviews 4) test events 5) system and SWFTS integration events 6) major acquisition milestones 7) delivery of software upgrades with new functionality, and 8) introduction and delivery to the fleet.[CDRL A026]

The Contractor shall use the IMS as a day-to-day execution tool and to periodically assess progress in meeting program requirements. The Contractor shall maintain and update the IMS, when necessary, to reflect Government approved changes, or changes in the Contractor’s detailed execution activities or schedule. The IMS shall include the activities of the prime Contractor and their subcontractors. All Contractor schedule information delivered to the Government or presented at program reviews shall originate from the IMS. The Contractor shall perform appropriate analyses of the IMS tasks and report potential or existing problem areas and recommend corrective actions to eliminate or reduce schedule impact.

The Contractor shall report, as part of the weekly informal progress report described in Section

3.1.1 herein, a written assessment of scheduled events to include key milestones and events affecting the critical path, which were not completed, or are projected to be not completed, per the IMS schedule. The Contractor shall also provide in the report, work around(s) and/or recovery schedules/plans and associated impacts due to program changes. The Contractor shall address in the schedule narrative progress to date and discuss any significant schedule changes (i.e., added/deleted tasks, any/all programmatic schedule assumption changes, etc.).

3.1.5 Program Management Reviews

The Contractor shall conduct Program Management Reviews (PMRs) quarterly, in the Washington, DC, area to provide Government insight into program cost, schedule, technical and outstanding issues. The PMR Agenda shall include any specific topic as mutually agreed between the Government and Contractor. [CDRL A003]

The Contractor shall place read ahead material and presentations on the Government Integrated Development Environment (IDE) preceding the PMRs [CDRL A027]. The Contractor shall place final Presentation Material, Conference Agendas and Conference Minutes on the Government IDE following the PMRs. The Contractor shall capture all Government and Contractor Acton Items from the PMRs and track their completion. The Contractor shall update Action Item status including closure plans. The Contractor shall also participate in PMR’s as required per TIs.

[CDRL A003; CDRL A004]

3.1.6 Data Management

3.1.6.1 Digital Data Management.

The Contractor shall implement data management procedures for complete and timely flow of data deliverables and track document versions, clearly identifying document changes/additions.

Specific data deliverables formats and distributions are listed in the Exhibit A, DD Form 1423-1, Contract Data Requirements Lists (CDRLs).

The Contractor shall maintain and deliver a Data Accession List (DAL) to track all data used to fulfill the requirements of the contract. [CDRL A028] The Contractor shall provide the DAL on a monthly basis, concurrent with submission of the Contractor Progress, Status and Management Report

The Contractor shall plan, schedule and report the status of all contractor and subcontractor data generated in support of this contract including E-mail transmittals and CDRL deliverables.

The Contractor shall establish a collaborative IDE (i.e. Dynamic Object-Oriented Requirements System (DOORS) and make available to all participants in the contract. All data shall be developed, managed, used, and delivered/exchanged electronically to the greatest extent practical, and marked with the appropriate distribution statment. The Contractor shall maintain proper levels of data control and security, in accordance with the appropriate Program Protection Plans and Information Assurance (IA) guidelines, for all materials and information developed, processed, maintained or transmitted for ISMT, OBTT, and/or related systems, subsystems, and components.

The Contractor shall comply with the requirements of Attachment 4, DD Form 254 DoD Contract Security Classification Specificaiton for implementation of and to ensure proper safeguarding of classified materials, events and processes. This will include documentation developed by the Contractor or received in support of Working Groups (WGs) and Integrated Product Teams (IPTs).

The Contractor shall ensure the Government has full real-time access to the database. The Contractor shall provide an export of the complete database at agreed to intervals to the Government controlled environment.[CDRL A029]

3.1.6.2 Data Delivery.

All products and data developed under this Contract shall be delivered with unlimited usage rights, as defined in Section H, DFARS clause 252.227.7013, 7014, and 7017 and appropriately marked as such, unless a waiver has been submitted and approved by the Government. In this context, data developed refers to source code and data that is uniquely developed under this contract and does not include embedded open source or COTS software products.

The Contractor shall upload all CDRL documents to the Advanced Interactive Management Technology Center (AIMTC) hosted by the Naval Undersea Warfare Center, Newport Division (NUWCDIVNPT) to include all applicable attachments and enclosures. The Contractor shall place data generated on this contract and any software models/applications necessary to use this data on the Government IDE. The IDE will be the digital repository for finished products/contract deliverables and data.

The Contractor shall provide an E-mail notification to the points of contact listed in Exhibit A, Attachment 1 “CDRL Distribution List” upon completion of uploading the CDRL delivery to AIMTC. The notification shall include the CDRL Item #, Title/Subtitle, the classification, the method of delivery (posting to AIMTC, hard copy via regular mail, etc.), and the path and link to the AIMTC IDE location. The Contractor’s E-mail notification shall also include an “official” Letter of Transmittal which identifies at a minimum the CDRL Item Number, CDRL Title and Subtitle, Contract letter reference #, submittal date, TI/APB, & Variant information (if applicable).

The CDRL document deliverable shall include a cover page with CDRL Item Number, CDRL Title and Subtitle, classification, Distribution Statement, and Cage Code/ Document # and Document date. When numerous items are provided under a specific CDRL (i.e. Technical Manuals or drawings), the Contractor shall include a Unique Identifiers (UIDs) to clearly identify the CDRL delivery.

The Contractor shall have Public Key Infrastructure (PKI) certification and a static Internet Protocol (IP) address (or group of addresses) to access the unclassified IDE. The Contractor shall coordinate with the Government on the approach to handling classified data and/or the requirement to access the SIPRNET or other encrypted links. Controlled Unclassified Information (CUI) submitted via E-mail shall be digitally signed and encrypted.

3.1.7 PKIs

Portions of product development require access to Government networks. The DoD has established the External Certification Authority (ECA) program to support the issuance of DoD approved PKI certificates to industry partners and other external entities and organizations. The ECA program is designed to provide the mechanism for these entities to securely communicate with the DoD and authenticate to DoD Information Systems. Currently an ECA is required for AIMTC access for CDRL delivery and transfer of other program and contract data including For Official Use Only (FOUO) documentation.

The DoD PKI Program Management Office (PMO) has designated the ECA External Liaison Officer (ELO) as the single point of contact to receive and coordinate all communications between the ECA community, DoD programs, and the DoD PKI PMO. The Contractor shall procure the ECA Certificates directly from the vendors. The Contractor shall purchase ECA Certificates for required individuals from the approved ECA website (http://iase.disa.mil/pki/eca/index.html).

ECA’s for designated personnel shall be in place within thirty (30) days of contract award.

3.1.8 Government Witness Activities

The Government reserves the right to witness all Contractor efforts to accomplish the SOW requirements and maintains the right to comment on processes. The Contractor shall make available to the technical representatives authorized by the Government all program data (e.g. working documents, databases, tracking systems, test results), including electronic access to computer files, pertaining to the Contractor and subcontractor activities in the performance of this contract. These activities may occur at the contractor’s site, or other locations.

3.1.9 GFI

The Contractor shall manage and control all items listed in Attachment 2, ISMT/OBTT-MC GFI List in accordance with the provisions of the contract. The Contractor shall provide E-mail notification of receipt of all GFI in accordance with the CDRL Distribution List herein. The Contractor shall thoroughly inspect GFI and report deficiencies. [CDRL A005]

3.1.10 GFP

The Contractor shall manage all GFP identified in Attachments 3, Government Furnished Property/Services, in accordance with the provisions of this contract. The Contractor shall provide E-mail notification of receipt of all GFP to all POCs listed in Exhibit A, Attachment 1. The Contractor provide a quality deficiency report to the Government documenting any GFP found damaged, malfunctioning, or otherwise unsuitable for use. [CDRL A006]

3.2 Systems Engineering

3.2.1 Systems Engineering Management

The Contractor shall provide a System Engineering Management Plan (SEMP) for how development will progress with the incorporation of inputs from the various supporting WGs. The Contractor shall describe how the various technical inputs to the systems engineering effort will be integrated into a collaborative development environment. A description of each major technical review shall be included. [CDRL A007]

3.2.2 Modular Open Systems Architecture Approach.

The Contractor shall establish and maintain a Modular Open Systems Architecture (MOSA) approach in accordance with the requirements of the DoD Open System Architecture Contract Guidebook, v.1.1. 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 re-used. The Contractor shall specify the process to avoid compromise of the intellectual property rights of third (3rd) party developers. The Contractor shall establish an Associate Contractor agreement with each third (3rd) party developer and coordinate disclosure and delivery schedule directly with the developers. The Contractor shall ensure the following system architecture characteristics are maintained for all baselines:

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.

b) Modular, Open Design – The Contractor shall develop and maintain an architecture that is layered and modular and uses COTS/Non-Developmental Item (NDI) hardware, operating systems, and middleware that utilizes non-proprietary or non-vendor-unique, key Application Programming Interfaces (APIs). The Contractor’s design approach shall be applied to all components. The Contractor shall provide the Government (and/or Government support contractors) electronic access to its integrated development environment throughout the term of the contract.

c) MOSA –The Contractor’s design approach shall produce a system that consists of hierarchical collections of software components.

In technical and design reviews, the Contractor shall provide the approach to be used relating to the overall Software Computer Software Configuration Item (CSCI) structure, functional flows, and interface requirements and shall describe how their approach supports Open Architecture goals while interfacing with the other SWFTS systems simultaneously under development and those already fielded on the target platforms. Additionally, as part of technical and design reviews, the Contractor shall, at a minimum:

a) Describe how the proposed system architecture meets the modular, open design goals, including the steps taken to use non-proprietary or non-vendor unique COTS or reusable NDI components wherever practicable.

b) Describe its rationale for the modularization choices made to generate the design.

c) Provide rationale to explicitly address any tradeoffs performed, particularly those that compromise the modular and open nature of the system.

d) Describe the plan to maintain awareness of, and access to, modern and developing technologies and products from industry. Describe how it will mitigate the risks associated with technology obsolescence.

e) Describe how it will avoid being locked into proprietary or vendor-unique technology and reliance on a single source of supply over the life of the product.

3.2.3 System Engineering and Design Analyses

The Contractor shall develop System/Subsystem Design Descriptions (SSDDs) in accordance with EIA-632 and SSS. In addition, the requirements outlined in the following paragraphs shall be included in the SSDD. [CDRL A008]. The SSS shall be updated, as required, for each configuration basline [CDRL A009].

3.2.3.1 Requirements Analysis.

The Contractor shall conduct detailed system engineering and design analyses of the proposed software and hardware system in accordance with the specifications included in individual Technical Instructions. Materials and components to be incorporated into the system or subsystems shall be specified including a listing of any hazardous materials or processes incorporated or used in the fabrication of the system or subsystems. The design analyses shall consist of detailed examinations of the design techniques and materials that the Contractor plans to use to meet the requirements of the specifications. The Contractor shall not require any critical manufacturing processes, special inspections/tools or calibrations in its design. The design analyses shall be specific on both the system and component levels. The Contractor shall examine the design details and modify them, as necessary, to ensure that the system design will conform to established Navy goals for minimum practical manning and highly maintainable, minimally complex systems. The Contractor shall develop Specification Requirement Verification Matrices (SRVMs) to ensure traceability between the test requirements and the ISMTand OBTT-MC SSS. [CDRL A010]

3.2.4 Software Design Requirements

The Contractor shall develop, update and maintain Software Requirements Specifications (SRS) and Interface Requirements Specifications (IRS) and Software Design Description

(SDD). The Contractor shall deliver revisions for each TI/APB baseline.[CDRL A011];

[CDRL A012]

3.2.5 Technical Reviews

Technical reviews shall be held at the Contractor’s facility to discuss and evaluate design status.

To support these reviews, The Contractor shall develop design review data package .[CDRL A027] Design reviews will be conducted on a periodic basis to determine progress and resolve issues. The structure and intervals shall be defined in the IMS. The Contractor shall conduct the following reviews in accordance with the PMS425 Sytem Engineering Plan (SEP) provided as GFI (Attachment 2).

a. System Requirements Review (SRR). The Contractor shall present its interpretation/understanding of the system functional requirements.

b. Preliminary Design Review (PDR). The Contractor shall present its system and software designs to show compliance with the system functional and performance requirements contained in the NAVSEA Technical Instructions. The completion of the PDR shall result in the establishment of the system software functional (performance) baseline.

c. Subsequent reviews including the Critical Design Review (CDR), which could take place in the form of Incremental Design Reviews (IDRs), are to be held in accordance with the Contractor’s software development process and will be agreed to by the Navy at the conclusion of the SRR. The Contractor shall present its detailed design to demonstrate the readiness to proceed into production, demonstration, and test and can meet stated performance requirements within cost, schedule, risk, and other system constraints.

3.2.6 Integrated Product Teams

The Contractor (including subcontractors and vendors as necessary) shall attend, present as necessary, and participate in the following Government-established PMS425 and SWFTS Integrated Product Teams (IPTs) and WGs supporting Legacy configuration updates, integration, and installation and performance assessment:

a. PMS425 System Engineering Integrated Product Team (SEIPT)

b. PMS425 Requirements Architecture Design Working Group (RADWG)

c. PMS425 Integration and Test Working Group (ITWG)

d. PMS425 Integrated Logistics Support Working Group (ILSWG)

e. PMS425 Problem Trouble Report (PTR) Review Board

f. PEO SUB Technology Insertion IPT (TI IPT)

g. PEO SUB Systems Architecture Working Group (SAWG)

In addition, the Government may establish, and the Contractor shall participate in ad hoc IPTs and subgroups, as the need arises. IPT meetings shall be held at either the Contractor’s facility or a Government specified facility.

To the extent specified in the established charter, the IPTs shall have responsibility for the following functions:

a. Monitoring and reporting of Subsystem status and progress for both the Government and the Contractor;

b. Joint identification, evaluation, management, and reporting of risk mitigation and cost reduction initiative efforts;

c. Identification, collection, analysis, and reporting of appropriate metrics for measurement of cost/schedule control, engineering and production progress;

d. Joint evaluation and management resolution of major issues associated with hardware and software engineering, production, integration, test, and Installation and Checkout (I&C) activities;

e. Verification that the Contractor’s ‘early and often’ design disclosure process is providing data that is current, complete and accurate to third (3rd) party developers;

f. Joint evaluation and management of the ILS effort; and

g. Joint recommended approval of data items requiring approval under this contract.

3.3 SYSTEM DEVELOPMENT

3.3.1 Software Engineering

The Contractor shall establish and maintain a software engineering process using the IEEE/EIA 12207 Series Standard to meet the requirements of the contract and achieve ISMT Performance.

The software engineering process shall be documented in a Software Development Plan (SDP). The Contractor shall tailor the requirements identified in IEEE/EIA 12207 as applicable to the ISMT program and the tailoring shall be included as part of the SDP.[CDRL A013]

The Contractor shall manage, develop, update, test and deliver computer software in accordance with the SDP. The Contractor shall maintain all requirements in a requirements tracking tool (i.e.

DOORS) with real time access being provided to the Government. The Contractor shall provide the following software development services:

Execute Code and Unit Test (CUT) Perform code review Assess, adjudicate, and resolve PTRs Generate and deliver the Software Product Specification (SPS) in accordance with the approved IMS to meet both CIS subsystem software development and integration, as well as SWFTS SoS integration requirements.[CDRL A018]

Generate and deliver software builds as directed by the Program Office to support unplanned CIS and SWFTS events to address critical issues (i.e. Tiger Team, fleet support)

Generate Software Version Description (SVD) documents for the generated software builds.[CDRL A020]

Generate software configuration build procedures

3.3.2 Problem Reporting System

The Contractor shall utilize the Government directed system for the identification, tracking, and resolution of all software and baseline documentation problems identified during system development, integration and testing. In addition, the PTR system shall be used to track test documentation problems and technical manual errors. Data on the problems covered in this system shall be included with the Contractor’s Progress, Status and Management Report in Section 3.1.1.

3.3.3 System Integration Planning

The Contractor shall develop a System Integration Plan (SIP), identify and provide the necessary development facilities, and conduct system integration, in accordance with the SIP. The Contractor shall address all problems identified by the Government during interface testing. The Contractor shall support integration and testing of ISMT and OBTT-MC.[CDRL A014]

3.3.4 T&E Program Plan

The Contractor shall develop, maintain and update a Test and Evaluation Program Plan (TEPP) to describe all testing planned for the ISMT, OBTT-MC and associated sensors, shipboard subsystems and interfaces. The TEPP shall also address recent advances in automated testing capabilities that can be accommodated during Government-conducted test and certification and regression testing.[CDRL A015]

3.3.5 Test Requirements

The Contractor shall develop, maintain and update the SRVM and Test Procedures. The TEPP and SRVM shall describe all tests for each system configuration separately. The Contractor shall generate a Test/Inspection Report following the conduct of each test performed and provide in a Test Completion Report. [CDRL A017]

3.3.6 Test Documentation

The Contractor shall maintain a comprehensive test program and perform integrated test planning to ensure that all tests are properly time phased and that duplicative or redundant testing is minimized. The test planning shall address pass/fail criteria and provisions for analyzing and correcting the cause of any failures.

3.4 Test and Evaluation

The Contractor shall perform demonstrations and tests per the Contractor-prepared and Government-approved TEPP and test procedures, in accordance with the SOW and the ISMT and

OBTT-MC SSS. [CDRL A016]

Government acceptance of the final software is contingent upon successful completion of these demonstrations and tests. The Contractor shall provide test lead support and test meeting support for all Test and Evaluation (T&E) efforts within this SOW.

3.4.1 Test Conduct

The Contractor shall document and conduct Test Readiness Reviews (TRRs) as scheduled in the IMS to ensure the system software is configuration managed, test documents and Request for Variance (RFVs) are approved, and test entrance requirements are satisfied prior to entering formal test events. The Contractor shall deliver software builds and conduct testing as defined in the TEPP and SRVM. [CDRL A015]

The Contractor’s T&E services shall also include:

a. Conduct of integration as necessary to ready the product for formal testing

b. Software build installation

c. Execution of Build Confidence Checkout (BCC)

d. Execution of Build Quality Assessment (BQA)

e. PTR Verification and Validation (V&V)

f. System Integration Tests (SITs)

g. Generation and delivery of Test/Inspection Reports, including Test Completion

Reports. [CDRL A017]

The Contractor shall conduct regression testing to determine adequacy of PTR fix solutions and to ensure that no new faults have been introduced. TRRs and TRR presentations shall be required for regression test events.

3.4.2 Testing Support to the Government

The Contractor shall provide access to its development and test facilities for the Government to perform on-site independent tests or evaluations. The Contractor shall provide support, as required, for Government-conducted Non Propulsion Electronics System (NPES)/SWFTS-level test events such as External Interface Tests (EITs), System Level Tests (SLTs), and SITs.

3.4.3 Software Development Files

The Contractor shall establish uniform Software Development Files (SDFs) containing technical information available to the software developers necessary to produce the latest version of the CSCIs. Preliminary and Detailed Design shall be provided in the SDFs. The SDF shall include a description of known problems (open PTRs) and test results for the CSCI. The Contractor shall describe the format, content and procedures of the SDFs. The Government shall be provided access to these files without restriction.

3.4.4 Software Deliveries

The Contractor shall generate and deliver software builds as necessary to support software development and integration requirements. The Contractor shall deliver the ISMT and OBTT- MC software as executable and source code to include any supporting configuration files and data libraries. The Contractor shall ensure that source code is documented to permit validation with software design documentation.[CDRL A018]

3.5 Integrated Logistics Support

The Contractor shall maintain an ILS Program in support of ISMT and OBTT-MC. The Contractor shall ensure effective logistics support for operation and maintenance of the production systems.

3.5.1 IETM Source Data

The Contractor shall develop, update and maintain ISMT and OBTT-MC IETM source data to support Government or other Contractor development of the SWFTS IETM configurations. The data shall address all aspects of ISMT and OBTT-MC operations and maintenance for each configuration, consistent with similar data contained within the SWFTS SoS Technology and

AN/BYG-1 IETMs provided as GFI (Attachment 2). The Contractor shall support validation planning and validation certification of the data. [CDRL A019]

In support of source data development, the Contractor shall participate in the ILS WG meetings, technical manual In Process Reviews (IPRs), training development IPRs and supportability analysis. Delivery schedule of IETM source data shall be documented in the Contractor’s IMS, support SWFTS IETM need dates and support the overall program IMP.

The Contractor shall develop source data that is S1000D compliant in a Government approved S1000D database environment. The Contractor shall provide subject matter expertise to support comment incorporation, desktop lab validations and verifications, training curriculum development support and provide single point of contact for the government and other members of the ILS working group in all matters relating to ISMT and OBTT-MC IETM source data delivery, development and schedules.

The Contractor shall participate in the System Notes Working Group (SNWG) (as required), and ensure that all System Notes required for inclusion into the Consolidated System Note Package are provided post review and verification to the SNWG for inclusion into the Ready Reference Manual

(RRM).

3.6 Facilities

The Contractor shall procure software licenses supporting all configurations including any licenses required for delivery of updated legacy baselines.

3.6.1 Hardware/Software Integration and Test

The Contractor shall maintain Hardware/Software Integration and Test (HSIT) facilities that provides the resources and environment for development, integration and testing of ISMT and OBTT-MC software functionality. The Contractor shall provide hardware troubleshooting, repair, and regular upkeep for all project-related hardware and software. The Contractor shall ensure all equipment is working properly prior to the TRR for each variant. The Contractor shall create and maintain a facilities schedule. The Contractor shall coordinate with Government and industry partner facilities leads as needed to ensure resources needed for ISMT and OBTT-MC Integration & Test (I&T) outside the Contractor’s facility are appropriately coordinated and scheduled.

ISMT and OBTT-MC (I&T) with CIS will be conducted at the CIS Integrators facility. As an IP of CIS, ISMT and OBTT-MC will participate in SoS testing at Navy-defined SWFTS integration facilities.

3.6.2 Licenses

The Contractor shall procure, receive, integrate and install any developmental hardware and software licenses under CLIN 0005, as negotiated between the Contractor and PCO.

3.7 Platform Integration

3.7.1 System Delivery

The Contractor shall provide input and participate in the Government-led Software Delivery Verification Review (SDVR) supporting each new software build final delivery to ensure that the system has successfully completed verification with all discrepancies adequately documented and that all system support actions have been completed. The Contractor shall also provide input and participate in the Government-led Delivery Readiness Reviews (DRR) to ensure the system is ready to be delivered to the Fleet.

The Contractor shall generate and deliver the software media executable data files SVD document to support software installation, training and maintenance on the individual platforms as directed by the Government. The SVD shall include separate sections for any unique platform requirements.

[CDRL A020]

3.8 Studies and Analyses

The Contractor shall assist the Government in developing strategies and studies, performing system engineering analysis, and developing implementation plans to ensure ISMT achieves the specified performance. Specific studies and analyses supporting TI/APB development shall be delivered in the Techncial Report – Studies/Service.[CDRL A021]

3.9 Contract Security Requirements

The Contractor shall meet access requirements for COMSEC, Non-SCI Intelligence Information, NATO Information and Foreign Government Information under this contract.

The NATO and Foreign Government information that may be required in the execution of this contract includes data generated through existing international projects that are or were conducted through PEO IWS 5, primarily the APB project, which includes the International Exchange Agreement with the United Kingdom and the BYG-1 MOU with the Commonwealth of Australia. Any exchange of information to/from these projects will be in accordance with existing Foreign Data Exchange agreements already in place.

3.10 Configuration Management

The Contractor shall maintain a Configuration Management Program (CMP) consistent with the principles and processes contained within the PMS425 CMP and the PMS425 SEP provided as GFI (Attachment 2). The program shall be outlined in the Contractor’s CMP. [CDRL A022]

When practical, Engineering Change Proposals (ECPs), Notice of Revisions (NORs) and RFVs should be unclassified. Classified data essential to the evaluation and disposition of an ECP, NOR or RFV must be submitted separately in accordance with the security procedures established in accordance with the contract and referenced in the unclassified portion of the ECP.

3.10.1 ECPs and NORs

The Contractor shall generate an ECP and/or NOR, as required, for baseline changes using MIL- HDBK-61A and the PMS425 CMP as guidance. ECPs shall not be submitted for new TI/APB configurations prior to the first successful DRR; the PTR process shall be used for defining configuration baseline changes for any in-development (prior to first DRR) TI/APB. ECPs shall be developed and submitted under the Engineering Services CLINs and shall only be submitted post- DRR to support either the next TI/APB configuration to be developed or to satisfy an urgent change to a legacy TI/APB configuration being supported under the Engineering Services CLINs.

Approved ECPs shall be considered as new Capability Items (CI) to the relevant TI/APB configuration. [CDRL A023]

All ECPs submitted under this contract shall be classified as Class I. The Contractor shall make revisions to the ECP(s) as required.

The Contractor shall also prepare and submit a NOR concurrent with any ECPs that would require revision to any Government specification or technical document if the ECP were approved. The NOR shall be used to describe the proposed change to the document.[CDRL A024]

3.10.2 Requests for Variance

A variance is a specific written authorization from the Government to depart from a particular requirement(s) of the existing, approved TI/APB. Variances differ from engineering changes because they do not affect changes to configuration documents. Variances will not permanently change the established baseline.

The Contractor shall generate a RFV, if required, under the TI/APB CLINs during the TI/APB development process.[CDRL A025]

The Contractor shall prepare critical and major RFVs and minor RFVs for Government review and approval. The Contractor shall submit RFVs for test failed requirements and provide an assessment of the impact to software, operations, and logistics documentation. RFVs shall not be submitted for changes to software code listings; an ECP must be used to effect such a change.

The Contractor shall classify variances based on the criteria specified in the PMS425 CMP.

3.10.3 Specification Change Notice

The Contractor shall prepare a proposed Specification Change Notice (SCN)…