PCS_SOW_ATT_2_COMPLETE_14Feb2014.pdf

DRAFT ACQUISITION SENSITIVE

N0002413NR92166

ATTACHMENT 2

STATEMENT OF WORK

FOR THE

SUBMARINE PAYLOAD CONTROL SYSTEM (PCS)

DEPARTMENT OF THE NAVY

PROGRAM EXECUTIVE OFFICER, SUBMARINES

SUBMARINE COMBAT AND WEAPONS CONTROL SYSTEMS (PMS425)

1333 ISAAC HULL AVENUE SE

WASHINGTON, NAVY YARD

WASHINGTON, DC 20376

DRAFT – 14 February 2014

FOUO - For Office Use Only i

TABLE OF CONTENTS

1. SCOPE 1

1.1 Navy Organization 2

1.2 Background 2

1.3 System Overview 3

1.4 Program Phasing 3

2. REQUIREMENTS AND CONTRACTUAL COMPLIANCE 4

2.1 Applicable Documents 4

2.1.1 Specifications and Standards (NAVSEA) (AUG 1994) 4

2.1.2 Applicable Documents 4

3. GENERAL REQUIREMENTS 6

3.1 Program and Contract Management 6

3.1.1 Post Award Conference (PAC) 6

3.1.2 Progress Reporting 6

3.1.3 Contract Work Breakdown Structure (CWBS) 7

3.1.4 Earned Value Management (EVM) 7

[Applicable to CLINs 0005, 0007, 0105, 0107, 0109, 0205, 0207, and 0208] 7

3.1.5 Integrated Master Schedule 8

3.1.6 Subcontract Management 8

3.1.7 Program Reviews 8

3.2 Meeting Support 9

3.3 Government Access to Contractor Facilities and Digital Environment 9

3.4 Meetings, Integrated Product Teams (IPTs), Peer Reviews, and Working Groups 10

3.5 Risk Management 11

3.6 Quality Assurance (QA) 11

3.7 Configuration Management 11

3.7.1 ECPs and NORs 11

3.7.2 Requests for Deviation (RFD) 12

3.8 Studies and Analyses 12

3.9 Data and Deliverables 12

3.9.1 Design Disclosure, Intellectual Property and Data Rights 12

3.9.2 Data Management 13

3.9.3 Data Delivery 13

3.9.4 Public Key Infrastructures 14

3.10 Government Furnished Information (GFI) Management 14

3.11 Government‐Furnished Property/Equipment/Material (GFP/E/M) Management 14

FOR THE

SUBMARINE PAYLOAD CONTROL SYSTEM (PCS)

1. SCOPE

This Statement of Work (SOW) defines the effort required to design, develop, test, and deliver the Payload Control System (PCS) portion of the AN/BYG-1 Submarine Combat Control System (SCCS) for all U.S. Navy new construction and in-service submarines and appropriate Joint Program Office (JPO) submarine platforms. The Contractor shall support all new development and legacy PCS efforts for the following AN/BYG-1 system variants:

AN/BYG-1 (V)1: VIRGINIA Class Blocks I and II (SSNs 774-783) AN/BYG-1 (V)2: 688i (SSNs 751-773) AN/BYG-1 (V)3: 688 with Vertical Launch System (SSNs 719-725 and 750) AN/BYG-1 (V)4: 688 without Vertical Launch System (SSNs 688-718) AN/BYG-1 (V)5: OHIO Class Ballistic Missile (SSBNs 730-743) AN/BYG-1 (V)6: SEAWOLF Class (SSNs 21-23) AN/BYG-1 (V)7: OHIO Class Guided Missile (SSGNs 726-729) AN/BYG-1 (V)8: Royal Australian Navy COLLINS Class (SSGs 73-78) AN/BYG-1 (V)9: VIRGINIA Class BLK III/IV (SSNs 784 -800) AN/BYG-1 (V)10*: VIRGINIA Class BLK V (SSN 801 and up)

* Nomenclature not yet assigned. PMS425 will submit nomenclature request when Block V RFP is released.

In addition to the variants listed above, support will be provided for planning efforts for future OHIO Replacement Class configurations.

The scope of services covered by this SOW includes efforts for system requirements definition, design, development, integration, and test through fielding and life cycle support. In general, these efforts include the following:

Program, Contract and Financial management and oversight for the Contractor’s PCS program “End to end” system engineering for development, integration, test and life-cycle support for all PCS configurations for the duration of this Period of Performance (PoP) PCS external interface definition including the determination of all necessary requirements to connect to the Submarine Warfare Federated Tactical Systems (SWFTS), launchers, and payloads Integration and test of the PCS with other components of the AN/BYG-1 system including, but not limited to, the Tactical Control System (TCS) and Information Assurance (IA) Integration and test of strike components including, but not limited to, Tactical Tomahawk Weapon

Control Systems (TTWCS), Tomahawk Control Interface Processor (TCIP), and Mission Distribution System (MDS)

Support for Technology Insertion (TI) hardware refreshment planning including support for TI hardware development, prototyping and product selection

Support for re-architecture and modernization of the existing Weapon Control System (WCS) to enable future development and payload integration under a PCS system

Support for development of PCS VIRGINIA Payload Module (VPM) capability and BLK III/IV Technology Baseline improvements

Development of PCS logistics source data Support for platform-level integration and test of the entire AN/BYG-1 system with other external-interfacing electronic subsystems

Technical/troubleshooting support as required for modernization and new construction system installation and test periods

Support for PCS software and logistics product support post-Delivery Readiness Review (DRR) Validation and assessment of PCS effectiveness, suitability and sustainability

1.1 Navy Organization

The Program Executive Officer, Submarines (PEO SUB) is the acquisition executive for this procurement. The Submarine Combat and Weapons Control Systems Program Office (PMS425) is responsible for the acquisition, development, production, fleet introduction and support of the AN/BYG-1 PCS for all classes of U.S. Navy submarines. Under a cooperative development program with the Royal Australian Navy (RAN), the PCS development, test, integration and life-cycle support efforts under this acquisition will also support RAN COLLINS Class submarines.

1.2 Background

Utilizing a collaborative development process originally introduced in Acoustics programs, PMS425 and Program Executive Office, Integrated Warfare Systems (PEO IWS 5) jointly operate and maintain a Combat Systems Research and Development (R&D) model to accelerate the transition of advanced development software to the submarine Fleet. This concept, which provides progressive capability through Advanced Processor Build (APB) software, relies upon an Open System Architecture (OSA) structure coupled with a second, complementary initiative involving periodic refreshes of Commercial Off the Shelf (COTS) hardware. This second initiative, the cyclical Technology Insertion (TI) process, mitigates the impacts of obsolescence through the regular planned replacement or upgrade of older hardware. Given advancements in power and capability with each hardware generation (most notably in the microprocessor industry), the repetitive TI process provides the opportunity to introduce greater processing capacity and thereby a more capable and efficient “landing pad” for the software APBs with each successive hardware refresh.

To date, three of the major submarine electronics Program Offices (PMS425, PMS401 and PMS435) follow this process and work cooperatively to systematically provide advanced capability for Combat and Weapons Control, Acoustics and Imaging systems. Other activities involved in collaborative PCS development, specifically in regard to payloads, include the PEO SUB Undersea Weapons Program Office (PMS404) and the Program Executive Officer, Unmanned Aviation and Strike Weapons (PEO(U&W)) Tomahawk Weapons Systems Program Office

(PMA 280).

The AN/BYG-1PCS efforts under this procurement shall follow the time-phased TI/APB cycle whereby a new APB software baseline is generated in odd years and a new TI hardware baseline in even years. The odd-year software baselines, the primary focus of this procurement, are integrated into both the prior-year and next-year TI hardware baselines. It is essential that the Contractor conduct the efforts required under this PCS procurement following the TI/APB process and working within the supporting collaborative development environment of Navy, Navy Laboratories, Academia and other government and industry partners. Although the PCS itself does not include or integrate an advanced development APB software product from PEO IWS 5 (PCS updates are primarily Fleet improvement and/or weapons-driven), it does follow the TI/APB cycle and APB naming convention for software updates.

For the purposes of this SOW, the following terminology will be used in relation to the PCS efforts to be performed by the Contractor.

Platform: An individual submarine Variant: The specific submarine class (or a submarine class separated by unique platform characteristics) that drives software and/or hardware differences Baseline: A term applied to either software or hardware or a combination of both. A hardware baseline is the sum total of AN/BYG-1 system hardware selected for a given TI (i.e., TI-16). A software baseline is the sum of approved functional capability for a given APB software build (i.e., APB-17). A baseline can also be a combined baseline (hardware plus software capability) such as TI-16/APB-17. A baseline is all-inclusive and not variant specific.

Configuration: A variant plus the combined hardware and software baseline. Example: AN/BYG-1(V)2

TI-16/APB-17.

Please note that minor individual platform differences also exist within system variants. The contractor shall be required to accommodate those platform-unique differences within each configuration for all products delivered under this SOW

1.3 System Overview

The AN/BYG-1 SCCS is divided primarily into three separately-developed but fully-integrated software applications—the Tactical Control System (TCS), which provides contact management and decision management functions, the Information Assurance (IA) application which includes the networking infrastructure to maintain separate security enclaves and downgrade system disk drives, and the PCS which is the subject of this acquisition.

The PCS is a fully integrated, mission critical subsystem that provides the operator the ability to exercise command and control over all submarine payloads (current and future) including but not limited to:

Torpedoes Mines Tomahawk cruise missiles Missiles Modular Undersea Heavyweight Vehicles (MUHVs) Unmanned Undersea Vehicles (UUVs) Unmanned Aircraft Systems (UAS) Countermeasures

The PCS software will operate on processing, display and launcher tactical hardware procured via separate contract vehicles with other industry partners and shipbuilders. No shipboard hardware procurement is planned for this contract. However, the Contractor will be responsible for procuring developmental laboratory assets supporting each TI/APB baseline. Additionally, the Contractor will be tasked to support the TI hardware refreshment process in decomposing subsystem requirements to specific technology hardware and infrastructure requirements and assessing and selecting candidate hardware. Any tactical system hardware and/or launcher equipment (in addition to the COTS development hardware procured by the Contractor) that is required to support the Contractor's Government-approved development, test and integration approach, will be provided as GFE following contract award and will be maintained as GFE under the provisions of the contract.

1.4 Program Phasing

The scope of services required to design, develop, deliver and support each PCS 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 six-year Period of Performance (PoP) of this contract.

The table below is the expected effort by configuration and variant across the CLINs and fiscal years of the contract PoP. Once the first Delivery Readiness Review (DRR) for the relevant TI/APB has been successfully completed, continued support for that configuration will transfer to the appropriate Engineering Services Level of Effort (LOE) CLIN. These legacy PCS baselines shall then be supported over the contract PoP under the Engineering Services LOE CLINs.

Example of PCS Variants and Estimated Demand NOTE: The number of variants in each TI/APB is subject to change depending on platform modernization schedules. Changes shall be negotiated and incorporated as Baseline Change Requests (BCRs).

2. REQUIREMENTS AND CONTRACTUAL COMPLIANCE

The work required by this contract shall meet the requirements of the Performance Specification for the Payload Control System (PCS) PMS425-PCPS-001 dated 21 January 2014 (Attachment 7) 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

2.1.1 Specifications and Standards (NAVSEA) (AUG 1994)

(a) Definitions.

(i) A “zero-tier reference” is a specification, standard, or drawing that is cited in the contract (including its attachments).

(ii) A “first-tier reference” is either: (1) a specification, standard or drawing cited in a zero-tier reference, or (2) a specification cited in a first-tier drawing.

(b) Requirements.

All zero-tier and first-tier references, as defined above, are mandatory for use. All lower tier references shall be used for guidance only.

2.1.2 Applicable Documents

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

ANSI/EIA-748-A

January 2005

Standard for Earned Value Management Systems Intent Guide (EVMS-IG)

COMNAVNETWARCOM

Communications Tasking Order

(CTO) 11-16

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

DODD 8500.01E

24 October 2002

Information Assurance (IA)

DODD 8570.01

15 August 2004

Information Assurance Training, Certification, and Workforce Management

DODI 8500.2

6 February 2003

Information Assurance (IA) Implementation

ISO/IEC/IEEE 12207-2008

31 January 2008

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

OSA Guidebook June 2013

DoD Open System Architecture Contract Guidebook, v1.1

MIL-HDBK-61A

7 February 2001

Military Handbook: Configuration Management Guidance

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. 2 29 April 1994

Hazardous Materials Management Program

NAVSEA 9400.2

18 August 2010

Implementation of NAVSEA Afloat IA Governance and Guidance

NAVSEAINST 9410.02

18 July 2005

Naval Warfare Systems Certification Policy

SAFETY-SSMP-02

21 May 2007

PMS425 System Safety Management Plan (SSMP)

13 May 2013

PMS425 Work Breakdown Structure (WBS)

27 November 2013

PMS425 Integrated Master Plan (IMP)

PMS425 Risk Management Plan May 2013

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

PMS425 Configuration Management Plan 22 January 20143

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

PMS425 SEP

25 July 2013

Submarine Combat and Weapon Control System Systems Engineering Plan (SEP), Version 1.1.1

PMS425 ltr Ser 425/0161 dated 24 August 2007

Information Assurance Vulnerability Management Policy for PMS425

3. GENERAL REQUIREMENTS

Section 3 of this SOW provides the Program Management and general requirements that shall be applicable to all work to be accomplished under the contract. Appendices A through E provide the specific technical efforts applicable to the TI/APB Development, Integration, Testing and Delivery efforts (CLINs 0005, 0105, 0108, 0205, and 0208) and the Engineering Support Services and Studies efforts (CLINs 0001, 0101, 0201, 0203, 0204, 0301, 0303, 0401, and 0403) under this contract.

3.1 Program and Contract Management

The Contractor shall designate a single Program Manager who shall have responsibility for all aspects of this contract and shall have the authority to commit the Contractor to specific courses of action. The Contractor shall establish and maintain an integrated management control system to control costs and schedule for all work under all CLINs covered by the contract. The Contractor shall organize, coordinate and control all services and supplies related to this contract including the identification and monitoring of subcontractor technical, quality, schedule and milestone achievements.

3.1.1 Post Award Conference (PAC)

The Contractor shall conduct a PAC with the Government within thirty (30) days of contract award. The PAC shall be no longer than two business days. The Contractor shall develop the PAC structure and agenda. The Contractor shall generate and record minutes, attendance list, and action items of the PAC, and produce copies of all information presented. The Conference shall be held at the Contractor’s facility. Representatives from each subcontractor on the Contractor's team shall attend. [CDRLs A001, A002]

The purpose of the PAC is as follows:

a) Review the Contract and Technical requirements

b) Discuss the roles and working relationships between the Contractor and the Government

c) Discuss the Contractor’s planned management effort and requirements verification process

d) Discuss required meetings, periodicity, and reporting requirements

e) Review the Contractor’s facility plans

f) Review the Contractor’s recommendations for AN/BYG-1 Integration and Test

g) Identify the Integrated Product Teams and their respective roles and responsibilities

h) Management and Contract Mechanics

Contract Administration Team Introductions Integrated Baseline Review (IBR) Earned Value Management System (EVMS) Quarterly Program Reviews (QPR) Quarterly Financial Reviews (QFR)

i) Technical Discussions Requirements Traceability overview Configuration Management processes Major Technical Risk Areas Design Review execution and schedule Configuration Management processes

3.1.2 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 A003]

In addition to the monthly Progress, Status and Management Reports, the Contractor shall provide two separate weekly informal reports to the Government via E-mail. The first report shall contain current contract and financial status, identification of any potential issues or risks and recommendations for resolution, and progress toward contract deliverable schedules as defined in the Integrated Master Schedule. The contract and financial report shall be delivered to the Government Contracting Officer Representative (COR), the PMS425 Principal Acquisition Program Manager (PAPM) and the PMS425 Acquisition Program Manager (APM). The second weekly report shall address technical status and shall identify progress toward, and any changes to, the PCS critical path, near-term major milestones, and TI/APB developmental task or activity actual start and/or actual finish date variances. The Contractor shall also include work-around(s) and/or recovery schedules/plans, identification of any risks, and associated impacts due to program changes. The technical report shall be delivered to the Government COR, the PMS425 PAPM, the PMS425 APM, and the PMS425 Chief Engineer (CHENG).

3.1.3 Contract Work Breakdown Structure (CWBS)

The Contractor shall tailor the requirements of MIL-STD-881C to develop and maintain a PCS Contractor Work Breakdown Structure (CWBS) and CWBS Dictionary that is compliant with EVMS guidelines and correlates cost and schedule performance with technical progress. The Contractor shall ensure the 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 (GFI, Attachment 3) to create a CWBS structure representing the products and services that comprise the entire work effort under the contract. The Contractor shall ensure traceability to the. 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 A004]

3.1.4 Earned Value Management (EVM)

[Applicable to CLINs 0005, 0007, 0105, 0107, 0109, 0205, 0207, and 0208]

The Contractor shall use a formally validated and accepted Earned Value Management System (EVMS) that complies with the EVMS guidelines in ANSI/EIA-748 for the applicable TI/APB development CLINs. The contractor shall provide timely, reliable, and accurate monthly Integrated Program Management Reports (IPMRs) utilizing Formats 1-6 to provide cost and schedule performance status, define changes to the Performance Measurement Baseline (PMB), provide staffing forecasts, and provide the Contractor’s Integrated Master Schedule

(IMS). [CDRL A005]

The IPMRs shall present and measure progress against exit criteria, present the status of any significant process or schedule changes, and identify any existing or potential problem areas or risks along with recommendations for resolution. The Contractor shall designate critical subcontractors, by name, for EVM compliance and validation or flow down of EVMS compliance to subcontractors. Critical subcontractor IPMR reports shall be included as attachments to the prime contractor reports.

3.1.4.1 Integrated Baseline Review (IBR)

The Contractor shall hold an IBR no later than 90 days after contract award in accordance with DFARS clause 252.234-7002. The Contractor shall work with the Government to develop the IBR agendas. The Contractor shall make available read-ahead material and presentation material seven (7) days prior to the IBR. The Contractor shall generate and record minutes, attendance list, and action items of the IBR, and produce copies of all information presented. Additionally, IBRs should also be conducted on subcontracts that meet or exceed the EVM threshold defined in DoD 5000.2. The prime Contractor shall lead the subcontractor IBRs, with active participation by the Government. The IBR shall be held at the Contractor’s facility and shall be no longer than two business days.

[CDRLs A001, A002]

Minimum IBR Entry Criteria

a) CWBS and CWBS Dictionary approved [CDRL A004]

b) Control Accounts established and Control Account Managers (CAMs) assigned

c) Initial IMS submitted (Format 6 of CDRL A005)

Within 90 days of each contract option exercise, the Contractor will host an IBR assessment of the Performance Measurement Baseline (PMB) which will be conducted by the Government program manager and the Contractor.

The IBR is not a one-time event and will be used after the exercise of significant contract options, and the incorporation of major design modifications. The Government will use IBRs throughout the life of the PCS program to facilitate and maintain mutual understanding of:

a. The scope of the PMB consistent with authorizing documents

b. Management control processes

c. Risks in the PMB associated with cost, schedules, and resources

d. Corrective actions where necessary

3.1.5 Integrated Master Schedule

The Integrated Master Schedule (IMS) (Format 6 of the IPMR provided in [CDRL A005] shall consist of key PCS program milestones, as derived from the PMS425 Integrated Master Plan (IMP) provided as GFI (Attachment 3).

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: acceptance of GFI; Program Reviews; Technical Reviews; test events; system and SWFTS integration events; major acquisition milestones; delivery of software upgrades with new functionality; and introduction and delivery to the fleet.

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 to reflect Government-approved change requests or changes in the Contractor’s detailed execution activities or schedule. 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, risks, and recommend corrective actions to eliminate or reduce schedule impact.

3.1.6 Subcontract Management

The Contractor shall actively manage the performance and quality of all work performed under subcontract.

Appropriate prime contract requirements shall be flowed down to all Subcontractors. The Contractor shall ensure their functional leads and/or CAMs are actively engaged in the preparation of all subcontract specifications and statements of work. The Contractor shall invite Government contracting and technical representatives to participate in Subcontractor visits and reviews. The Contractor shall provide 15 working days advance notice to the Government contract Administrative Contracting Officer (ACO) 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.7 Program Reviews

The Contractor shall conduct QPRS and QFRs every three (3) months at its facility or alternate government facility per direction of the government for a period not to exceed one (1) day. An informal “read-ahead” brief shall be provided electronically to the Government 10 working days prior to the review.

3.1.7.1 Quarterly Program Review (QPR)

The purpose of the QPR is to ensure the Contractor’s approach and progresses are technically sound, meet the requirements, and are mutually understood and properly documented. At each QPR, the Contractor shall report status, issues, risks and recommendations for the following items (at a minimum) for all exercised CLINs:

a) Schedule progress against the IMS (3 month history and 6 months projected)

b) Contract deliverables completed and projected (3 month history and 6 months projected)

c) Technical and program status and metrics

d) Test and evaluation activities

e) Logistics source data development and support efforts

f) Risk analysis activities

g) Quality program status

h) Safety program status

i) GFP and GFI status

j) Proposed changes to the Program baseline

3.1.7.2 Quarterly Financial Review (QFR)

The purpose of the QFR is to ensure the Contractor has adequate financial resources and planning to execute the contract. At each QFR, the Contractor shall report status of the following (at a minimum) for all exercised CLINs:

a) Cost/Schedule performance and variances against plan

b) Financial projection/actual (3 month history, 6 month future)

c) Performance against the contract incentives

d) Risk analysis activities

3.2 Meeting Support

The Contractor shall prepare agendas for Contractor-hosted meetings, program reviews, IPTs and all other meetings/reviews. The agendas shall be provided by the Contractor via electronic mail (E-mail) two weeks prior to meetings and shall be reviewed jointly between the Government and Contractor. [CDRL A001]

The Contractor shall have the capability to support controlled access to unclassified Voice and Web Conferencing.

The Contractor shall provide the web-teleconference connection to those offsite and required to attend. The web-teleconference information shall be provided by the Contractor via electronic mail (E-mail) one week prior to the meetings.

The Contractor shall maintain the capability to participate in face-to-face coordination meetings and telephone conversations with the Government program office. The Contractor shall plan for a minimum of four (4) face-to-face meetings each fiscal year, with travel to the Washington Navy Yard or other support activities locations.

The Contractor shall prepare and electronically submit minutes of the meetings within 10 working days unless otherwise directed by the Government. Minutes shall include a summary of discussions, copies of handouts, briefs or graphics, and a listing of action items. [CDRL A002]

3.3 Government Access to Contractor Facilities and Digital Environment

The Contractor shall enable and facilitate the Government and Government-designated representative’s access to Contractor facilities and Contractor Integrated Digital Environment databases (i.e., Dynamic Object-Oriented Requirements System (DOORS), Problem Trouble Report (PTR) database). Government personnel attendance will be controlled by the Government’s Program Manager.

The Contractor shall provide secure office space and provide office services for up to three technical representatives, authorized by the Government, on site at the Contractor’s facility beginning at contract award and continuing through the end of the contract.

The Government may witness all Contractor efforts (to include all peer reviews, tests, test-like events, and inspections) to accomplish the SOW requirements and maintains the right to comment on processes. The Contractor shall notify the Government a minimum of fourteen (14) calendar days in advance of any such peer review, tests, events, and/or inspections.

The Contractor shall have required personnel cleared for Top Secret information required to maintain knowledge of the current threat environment, strike mission planning and any related improvements discovered by operational forces.

3.4 Meetings, Integrated Product Teams (IPTs), Peer Reviews, and Working Groups

The Contractor shall participate in and conduct meetings, conferences, teleconferences, video teleconferences, drumbeats, Integrated Product Teams (IPTs), peer reviews, and working groups supporting all efforts under this contract. Participating and conducting includes meeting preparation, travel, attending meetings and providing information for the IPT, peer review, or working group to make decisions.

Specific Government-established IPTs and working groups supporting the TI/APB Development, Integration, Testing and Delivery CLINs and the Engineering Support Services and Studies LOE CLINs are defined in Section 4 of this SOW.

In addition, the Contractor may, at its discretion, establish additional IPTs with members from Government, the Contractor, subcontractors, industry partners and vendors in order to address specific programmatic issues or to support general PCS development and fielding including the consolidation and integration of cost, schedule and performance data to provide a global perspective into the managerial and technical aspects impacting Government and industry.

For the Contractor-established IPTs, the Contractor shall develop IPT charters and present these charters during program reviews for Government approval. Potential functions for Contractor IPTs may include:

a) Monitoring and reporting of PCS 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 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 party developers

f) Joint evaluation and management of the ILS effort

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

The Contractor may also establish Peer Reviews and Working Groups at its discretion. For these Contractor-established Peer Reviews and Working Groups, the Contractor shall develop charters and present these charters to the APM and CHENG for Government approval. Potential functions for Contractor Peer Review and Working Groups may include:

a) Monitoring and reporting of PCS design status and progress

b) Identification, evaluation, collection, analysis, and reporting of engineering design, requirements, test events, and documentation details

c) Evaluation and resolution of major issues associated with hardware and software engineering, production, integration, test, and I&C activities

d) Evaluation and resolution of major issues associated with the ILS effort

Contractor IPT, Peer Reviews, and Working Group meetings shall be held at either the Contractor’s facility or a Government specified facility. Web-teleconference connection shall be provided to those offsite and required to attend.

3.5 Risk Management

The Contractor shall continuously assess and manage program and technical risks in accordance with the PMS425 Risk Management Plan (Attachment 3 GFI). Risks shall allow for the identification of both technical and non-technical risks, risk assessment, the development of appropriate actions and mitigations to effectively manage these risks, and tracking of potential impacts to cost, schedule, or performance impacts. Risk analysis shall also be provided in the Contractor’s IPMR and presented during Program and Technical Reviews. The analysis shall identify the area of risk, the impact of each risk on the overall program, and proposed approaches for reducing the identified risks. The Contractor shall support the PMS425 Risk Advisory Board (RAB) and Working Group meetings in accordance with the PMS425 Risk Assessment/Management Plan.

3.6 Quality Assurance (QA)

The Contractor shall implement and maintain a QA program during the performance of the contract and shall ensure the materials and work provided by Subcontractors, and Suppliers meet the standards of the SOW. The Contractor shall be responsible for developing, presenting, implementing and supplementing, if needed, quality and timeliness control procedures to ensure that all aspects of the PCS contract meet the standards set forth in the SOW. At a minimum, the quality management process should include the following key QA activities:

a) Establishment and implementation of a Quality Control Program

b) Monitoring and control of critical processes and product variation

c) Establishment of mechanisms for feedback of field product performance

d) Implementation of an effective root cause analysis and corrective action system

e) Continuous process improvement

3.7 Configuration Management

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

When practical, Engineering Change Proposals (ECPs), Notice of Revisions (NORs) and Requests for Deviation (RFDs) should be unclassified. Classified data essential to the evaluation and disposition of an ECP, NOR or RFD 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.7.1 ECPs and NORs

The Contractor shall generate ECPs and NORs, as required, for baseline changes using MIL-HDBK-61A and the PMS425 Configuration Management Plan as guidance. ECPs shall not be submitted for new TI/APB configurations prior to the first successful DRR; the Problem Trouble Report (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 A007]

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

3.7.2 Requests for Deviation (RFD)

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

The Contractor shall generate Requests for Deviation (RFDs), if required, under the TI/APB CLINs during the TI/APB development process. [CDRL A009]

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

The Contractor shall classify deviations based on the criteria specified in the PMS425 Configuration Management Plan.

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 the PCS achieves the specified performance. Specific studies and analyses supporting TI/APB development shall be described in the TI/APB Appendices. [CDRL A010 (approval required) and A011 (non-approval)]

If the award is not to the incumbent Contractor, a Transition plan shall be required within 60 days after contract award. [CDRL A010] The Contractor shall submit a transition plan to include the following elements:

Identification of required hardware and software to initiate TI-16/APB-17 development Proposed schedule Facility plan for development and test efforts Reconstitution of the software build plan and schedule

3.9 Data and Deliverables

3.9.1 Design Disclosure, Intellectual Property and Data Rights

The Contractor shall deliver data rights in technical data, computer software, and computer software documentation with no less than Government Purpose Rights. If the PCS system contains any commercial Technical Data (TD)/Computer Software (CS)/Computer Software Documentation (CSD), the Contractor shall deliver a license to the TD/CS/CSD that would grant the Government the equivalent of Government Purpose Rights.

The Contractor shall provide a list, entitled "Background Inventions--Identification and Licensing" (the BIIL List), identifying all inventions described in and covered by any patents or pending patent applications in which the Contractor (1) has any right, title, or interest; and (2) intends to include in any Items, Components, Processes (ICP) to be developed or delivered under the resulting contract, or that are described or disclosed in any TD, CS, or CSD to be developed or delivered under the resulting contract. Such inventions are hereafter referred to as "background inventions."

The Contractor's failure to identify a background invention in the BIIL List, as set forth above, shall constitute a grant to the Government of a nonexclusive, nontransferable, irrevocable, worldwide, paid-up license to practice, and to have practiced for or on its behalf, such invention for Government purposes related to the affected Combat System(s).

The Contractor shall establish and maintain a process that will provide ‘early and often’ design disclosure directly to the Government, Government support contractors and third party development partners via electronic access to in-process design documentation and computer software. The Contractor shall support an Open Source Initiative with other participants within the Shipboard Combat Systems development community, using modular design, standards-based interfaces, and widely-supported consensus-based standards. The Contractor shall establish an Associate Contractor Agreement with each third party developer and coordinate disclosure directly with the developers. The exchange of information shall be structured so as to protect the Contractor's and third party developers’ proprietary rights in the information. The Contractor shall furnish to the PCO a copy of the Associate Contractor Agreement and copies of all written communication between the Contractor and the third party developers that is pertinent to this contract. The Contractor shall discuss and attempt to resolve any problems between the Contractor and the third party developers and notify the PCO if required, in writing, of any problems including documentation of problem resolution.

3.9.2 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 Contract Data Requirements Lists (CDRLs).

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 maintain and deliver a Data Accession List (DAL) to track all data used to fulfill the requirements of the contract. [CDRL A012] The Contractor shall provide the DAL on a monthly basis, concurrent with submission of the Contractor Progress, Status and Management Report

The Contractor shall establish a collaborative Integrated Digital Environment among all participants in the contract.

All data shall be developed, managed, used, and delivered/exchanged electronically to the greatest extent practical.

The Contractor shall maintain proper levels of data control and security, in accordance with the appropriate Program Protection Plans and Information Assurance guidelines, for all materials and information developed, processed, maintained or transmitted for AN/BYG-1. The Contractor shall comply with the requirements of the DD254 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 and IPT's.

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

A scan report verifying the appropriate markings, including security classification and data rights shall be delivered with the product.

The Contractor shall upload all unclassified 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 “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 (UID)s to clearly identify the CDRL delivery.

E-mail shall be used by the Contractor for the efficient transfer of unclassified data only and to conduct informal communications with the Navy. E-mail is not an authorized means to alter the scope of this contract. If the Contractor feels he has received a communication that provides direction outside the scope of the contract, he shall notify the Procuring Contracting Officer (PCO) within 48 hours of occurrence and prior to compliance.

The Government reserves the right to witness all Contractor efforts to accomplish the Statement of Work (SOW) requirements and maintains the right to comment on processes. The Contractor shall make available to Government on-site technical representatives (see SOW Paragraph 3.3) all program data (e.g. working documents, databases, tracking systems, test results), including electronic access to computer files, that pertain to the contractor and subcontractor activities in the performance of this contract. The Government may request the Contractor to deliver internal data developed or modified under this contract

3.9.4 Public Key Infrastructures

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 30 days of contract award.

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.10 Government Furnished Information (GFI) Management

The Contractor shall manage and control the GFI identified in Attachment 3 in accordance with the provisions of the contract. The Contractor shall provide E-mail notification of receipt of all GFI to the PMS425 COR and the PMS425 Logistics Manager. The Contractor shall thoroughly inspect GFI and report deficiencies. [CDRL A013]

3.11 Government-Furnished Property/Equipment/Material (GFP/E/M) Management

The Contractor will be provided with GFP/E/M including weapon launchers, test equipment and Simulation/Stimulation (SIM/STIM) equipment as identified in the GFP/E/M List Attachment 4. The Contractor shall manage the GFP/E/M in accordance with the provisions of this contract. The Contractor shall provide E-mail notification of receipt of all GFP/E/M to the PMS425 COR and the PMS425 Logistics Manager. The Contractor shall report to the Government any GFP/E/M found damaged, malfunctioning, or otherwise unsuitable for use.

[CDRL A014]

APPENDIX A

TO

TI-16/APB-17 Development, Integration, Testing and Delivery [CLIN 0005]

B-1

DRAFT ACQUISITION SENSITIVE

APPENDIX A

1. SYSTEMS ENGINEERING 2

1.1 Systems Engineering Management Plan (SEMP) 2

1.2 Engineering Documentation Database 3

1.3 Studies and Analyses 3

1.4 Meetings, Integrated Product Teams (IPTs) and Working Groups (WGs) 3

1.5 System Requirements 3

1.5.1 Requirements Documentation 4

1.5.2 Interface Requirements Management 4

1.5.3 System Architecture and Design 5

1.5.4 Safety 8

1.5.5 Information Assurance (IA) 9

2. SYSTEM DEVELOPMENT 9

2.1 TI‐16/APB‐17 Software Development 9

2.1.1 Software Resources Data Report (SRDR) 10

2.2 Problem Reporting 10

2.3 System Integration Planning 11

2.4 Test Documentation 11

2.4.1 Test and Evaluation Program Plan 11

2.4.2 Test Procedures 11

3. TEST AND EVALUATION 11

3.1 Test Conduct 12

3.2 Testing Support to the Government 12

4. PLATFORM INTEGRATION 12

4.1 System Delivery 12

5. INTEGRATED LOGISTICS SUPPORT 12

5.1 Interactive Electronic Technical Manual (IETM) Source Data 12

5.2 Ready Reference Manual (RRM) 13

5.3 OD 44979 Redlines 13

6. FACILITIES 13

6.1 Hardware/Software Integration and Test (HSIT) Facilities 13

6.2 Licenses 14

B-2

APPENDIX A TO ATTACHMENT 2

FOR

TI-16/APB-17 DEVELOPMENT, INTEGRATION, TESTING AND DELIVERY

[CLIN 0005]

The Contractor shall design, develop, test, integrate and deliver the AN/BYG-1 PCS TI-16/APB-17 PCS for variants

(V) 1, 2, 6 and 9 and accomplish common efforts for (V)8 under CLIN 0005. Paragraphs 1 through 6 of this Appendix C apply to CLIN 0005.

The Contractor shall use the AN/BYG-1 TI-16/APB-15 WCS capabilities as the baseline for developing the core TI-16/APB-17 PCS and shall ensure the TI-16/APB-17 PCS performance is in accordance with the Performance…