GPNTS Software SOW_(Synopsis Draft).pdf

STATEMENT OF WORK (SOW)

FOR

GLOBAL POSITIONING SYSTEM (GPS)-BASED POSITIONING, NAVIGATION, AND

TIMING SERVICE (GPNTS)

SOFTWARE SUPPORT CONTRACT

10 October 2017

PROGRAM EXECUTIVE OFFICE COMMAND, CONTROL, COMMUNICATIONS,

COMPUTERS AND INTELLIGENCE (PEO C4I), NAVY COMMUNICATIONS AND

GPS NAVIGATION PROGRAM OFFICE (PMW 170)

(SR-2017-124) Distribution Statement A: Approved for public release, distribution is unlimited (8

February 2017)

Table of Contents

1.0 SCOPE

2.0 REQUIREMENTS

2.1 PROGRAM AND DATA MANAGEMENT

2.1.1 Program Management

2.1.1.1 Contract Fund Status Report (CFSR)

2.1.1.2 Manpower Reporting

2.1.1.3 Post Award Conference (PAC)

2.1.1.4 Program Management Reviews (PMRs)

2.1.1.5 Program Protection Implementation Plan (PPIP)

2.1.1.6 Integrated Master Schedule (IMS)

2.1.2 Design Reviews

2.1.2.1 Software Design Reviews

2.1.2.2 Software Requirements Review (SRR)

2.1.2.3 Preliminary Design Review (PDR)

2.1.2.4 Critical Design Review (CDR)

2.1.2.5 Software Test Readiness Review (TRRs)

2.1.2.6 System Test Readiness Review (TRRs)

2.1.2.7 Functional Configuration Audit (FCA)

2.1.3 Automated Interchange of Technical Information Management

2.1.4 Technical Data Management

2.1.5 Modular Open Systems Approach/Open System Architecture

2.1.6 Net-Centric Enterprise Solutions for Interoperability (NESI) Compliance

2.2 STUDIES AND ANALYSIS

2.3 GOVERNMENT PROPERTY

2.3.1 GFP Reporting

2.3.2 GFP Marking

2.3.3 GFP Tracking

2.3.4 GFP Return

2.3.5 Contractor Acquired Property

2.3.6 Item Unique Identification (IUID)

2.4 CONFIGURATION MANAGEMENT PROGRAM

2.4.1 Configuration Management and Planning

2.4.2 Configuration Identification

2.4.2.1 Identification, Labeling and Marking

2.4.2.2 Technical Baseline

2.4.3 Configuration Control

2.4.4 Configuration Status Accounting

2.4.4.1 Configuration Verification and Audits

2.5 SOFTWARE SUPPORT ACTIVITY ENGINEERING

2.5.1 Technical Approach

2.5.1.1 Software Development Approach / Software Development Plan (SDP)

2.5.2 Systems Engineering Management Plan

2.5.3 System Performance Specification/ System/Subsystem Specification

2.5.4 Software Support Activity Engineering Approach

2.5.4.1 Human System Integration/Human Factors Engineering

2.5.4.2 Cybersecurity Engineering

2.5.5 Software Quality Assurance

2.5.5.1 Management of Quality Assurance

2.5.5.2 Standards for Quality Assurance

2.5.5.3 Software Reviews for Quality Assurance

2.5.5.4 Problem Reporting and Corrective Plans for Quality Assurance

2.5.5.5 Risk Management for Quality Assurance

2.5.5.6 Records Management for Quality Assurance

2.5.6 Software Delivery

2.5.7 Software Sustainment Support

2.5.8 Software Integrated Process Teams

2.5.9 Software Development

2.5.9.1 Problem Report (PR) Analysis

2.5.9.2 PR Resolution

2.5.9.3 New Development and Upgrades

2.5.9.4 Software Builds

2.5.9.5 Engineering Drops

2.5.9.6 Information Assurance Vulnerability Alert (IAVA) Updates and Patches

2.5.10 Software Documentation

2.5.10.1 Software Requirements Specification

2.5.10.2 Software Version Description

2.5.10.3 Software Product Specification

2.5.10.4 Software Design Description

2.5.10.5 Interface Design Description

2.5.10.6 Interface Control Document

2.5.10.7 Software Installation Plan

2.5.11 Software Testing

2.5.11.1 Acceptance Testing in the Contractors Lab

2.5.11.2 Acceptance Testing at Government Facility

2.5.11.3 Pre-Qualification Acceptability Testing

2.5.11.4 Software Verification Matrix

2.5.11.5 Automated Testing

2.5.11.6 Verification, Validation, and Accreditation

2.5.12 Software Interface

2.5.13 Source Code Analysis

2.5.14 Software System Safety

2.5.15 System Testing

2.5.15.1 System Requirements Verification Matrix

2.5.15.2 System Integration Testing

2.5.15.3 Formal Qualification Testing (FQT)

2.5.15.4 Verification, Validation, and Accreditation

2.5.16 Interactive Electronic Technical Manual (IETM)

2.6 ENGINEERING SUPPORT

2.6.1 Engineering Support

2.6.2 Field Engineering Support

2.6.3 Military Code (M-Code) Integration Engineering Support

2.7 SECURITY PROGRAM IMPLEMENTATION

3.0 APPLICABLE DOCUMENTS

3.1 GPNTS DOCUMENTS

3.2 SECURITY DOCUMENTS

3.3 OTHER DOCUMENTS

Acronyms

1.0 SCOPE

This Statement of Work (SOW) sets forth the Contractor’s requirements to act as the software design agent for the existing Global Positioning System (GPS)-Based Positioning, Navigation, and Timing Service (GPNTS) system; perform development, integration and test of improvements; correct deficiencies; provide inputs for the control of the GPNTS software requirements and configuration baseline; prepare engineering drops; and prepare and test of formal software builds for the existing GPNTS software being installed on U.S. Navy ship and shore platforms. This common approach reduces the overall implementation, operational, system and hardware maintenance, training, and logistic costs to the Government.

All work to be performed under this SOW will be defined and implemented via the issuance of

Task Orders (TOs) that will specify the type of effort, the level of effort, data requirements, funding authorization, and the period of performance.

Work shall maintain the performance of the existing system with respect to its applicable performance specification.

The Government plans to use the Rapid Integration and Test Environment (RITE) to control the

GPNTS baseline. The RITE process provides comprehensive oversight of software development from initial design to customer acceptance. RITE provides a standard operating procedure and describes the agile method used for incremental capability development and integration employing Scrum. Scrum involves iterative development, continuous integration, frequent and early testing, and periodic product demonstrations within short, predefined durations. This facilitates smaller, modular products, allowing more rapid delivery and deployment of new capabilities while providing improved oversight and teaming through frequent planning and review meetings. RITE provides a standardized approach to software testing that requires the frequent use of automated testing tools at key development gates for early identification of software defects, and then validates the results through repeatable system integration events.

RITE also calls for establishment of a software repository for strong configuration control and sharing of program information, tools, and lessons learned across a distributed environment promoting a culture of open interfaces, modularity, and reuse to keep pace with evolving technologies. The RITE life cycle includes the implementation of front-end engineering, source code quality management, a distributed development environment, and automated development and test tools.

2.0 REQUIREMENTS

The TOs issued under this contract will require the contractor to provide inputs for the control of the software requirements database, control the GPNTS software baseline, provide platform-specific software configurations, provide and prepare software documentation, and implement software improvements. The Contractor shall assess the impacts of potential design changes to the GPNTS functional baselines and execute the changes. This tasking will help to ensure and enhance the quality of the GPNTS software and will support the needs of the existing platforms as they evolve and other platforms in the future.

2.1 PROGRAM AND DATA MANAGEMENT

As directed by individual TO the Contractor shall perform the following:

2.1.1 Program Management

The Contractor shall provide program management to ensure all work conducted under the contract is planned and executed in a manner that that will achieve all management, technical, logistics, cost, and schedule objectives. The Contractor shall manage and execute the program using an Integrated Product Team (IPT) structure with the Government participating in the IPTs.

The Contractor shall maintain awareness of all aspects of the GPNTS program and ensure the

Government management team has insight into all the Contractor’s program activities. The

Contractor shall document progress of work in a Contractor's progress, status and management report (CPSMR). This report shall include status of the program, and information of potential problem areas and all options exercised on this contract.

Contract Data Requirements List (CDRL) Deliverable:

A001 - Contractor’s Progress Status and Management Report (CPSMR)

2.1.1.1 Contract Fund Status Report (CFSR)

The Contractor shall submit a quarterly CFSR in accordance with the Data Item Description (DID) and tailored instructions provided in the CFSR CDRL. The CFSR shall be used by the Contractor and the Government to update and forecast contract funds requirements; to plan and communicate funding changes; to develop funding requirements for approved efforts; to determine funds in excess of contract needs and available for de-obligation; and to obtain rough estimates of termination liability and open commitment costs.

CDRL Deliverable(s):

A002 - Contract Fund Status Report (CFSR)

2.1.1.2 Manpower Reporting

The Contractor shall report all Contractor labor hours (including subcontractor labor hours) required for performance of services provided under this contract for the Space and Naval

Warfare Systems Command (SPAWAR) via a secure data collection site. The Contractor is required to completely fill in all required data fields using the following web address https://doncmra.nmci.navy.mil.

Reporting inputs (from Contractors) will be for the labor executed during the period of performance during each Government fiscal year (FY), which runs October 1 through September

30. While inputs may be reported any time during the FY, all data shall be reported no later than

October 31 of each calendar year. Contractors may direct questions to the help desk, linked at https://doncmra.nmci.navy.mil

A003 - Labor Hours Reporting

2.1.1.3 Post Award Conference (PAC)

The Contractor shall hold a PAC no later than thirty (30) calendar days after award of the first task order, and at a time that is mutually agreeable to both the Government and the Contractor.

The contract and first task order will be awarded simultaneously. The PAC shall be used to discuss contract management plans. At a minimum, the Contractor shall discuss the following topics at the conference:

a. Identify and introduce Contractor management, engineering, and other key personnel to the Government representatives. Each individual shall define his/her area of responsibility and accountability

b. Explain the Contractor’s organization, plans, procedures, and schedules to execute SOW and perform to the standard of the GPNTS Technical Requirements Document (TRD)

c. Present the Contractor’s business and technical management procedures (e.g., technical point of contact assignments, status reporting procedures, designated lines of authority) that shall be implemented to accomplish the requirements of the contract

d. Present the Contractor’s current staffing plan

e. Identify status of subcontracts in effect or anticipated

f. Allocate time for the Government to present its organization, plans, procedures, schedules, and concerns

g. Allocate time for an open forum to discuss contract-related issues

A004 - Conference Agenda

A005 - Presentation Material

A006 - Report, Record of Meeting/Minutes

2.1.1.4 Program Management Reviews (PMRs)

The Contractor shall conduct one (1) PMR annually, and the review shall occur at the

Contractor’s facility unless specifically requested by the Government to occur elsewhere. The review shall address the status of all ongoing studies, which may include design, development, software changes, test and evaluation, and field engineering studies. The Contractor shall provide selected view graphs and spreadsheets to support program office briefing requirements for documenting program activities. The Contractor shall report on cost, schedule, technical progress, program risks and mitigations, and technical performance measures. The Contractor shall present the risk management database and risk management chart as part of the PMR

Presentation Materials. The Contractor shall develop agendas and minutes for each program review. The Government reserves the right to modify the agenda and the minutes. The PMR content shall contain all aspects of each TO addressing cost, schedule, and performance, (e.g.

schedule status, progress against major milestones, cost/funding status, risk management, manpower, configuration management, software engineering, and quality assurance). The

Contractor’s lead managers shall report on their various tasks. The Government reserves the right to schedule additional reviews or working groups if critical issues arise or significant events or changes have occurred. The Contractor shall specifically address known or anticipated impacts to systems and terminal performance.

A005 - Presentation Material

A006 - Report, Record of Meeting/Minutes

2.1.1.5 Program Protection Implementation Plan (PPIP)

The Contractor shall provide a Program Protection Implementation Plan (PPIP) in accordance with the PPIP CDRL to the Government within 30 days of receiving countermeasures direction from the Government and provide periodic countermeasure and implementation status to the

Government. The PPIP shall document the Contractor’s policies, processes, and physical measures implemented for the protection of GPNTS technologies and information. The

Contractor shall provide technical support for the Government’s Program Protection Plan (PPP) process performed in accordance with Department of Defense Instruction (DoDI) 5200.39 and

DoDI 5200.02. This shall include support for a Critical Functionality Analysis of the acquisition program. The Contractor shall provide Operations Security (OPSEC) training to Contractor personnel with access to sensitive technology and CPI annually. These requirements shall flow down to all subcontractors.

A007 - Program Protection Implementation Plan

2.1.1.6 Integrated Master Schedule (IMS)

The Contractor shall develop, maintain, and deliver a logically networked IMS as directed by individual TOs. The IMS shall contain the planned events and milestones, all activities from task order award to task order completion, activity entrance and exit criteria, and risk(s) mitigation activities identified. The IMS shall reflect the tasks, dates (baseline, forecast, and actual), external and internal dependencies, and relationships necessary to support accurate forecasts of contract milestone delivery dates by both the Contractor and the Government. The

Contractor shall support monthly teleconferences, as needed, to discuss IMS progress and issues.

A008 - Integrated Master Schedule

2.1.2 Design Reviews

2.1.2.1 Software Design Reviews

The Contractor shall conduct a Software Design Review for each major software modification to be performed on the GPNTS system. The software design presentations shall include an overview of the proposed modification (e.g., modules, external interfaces, interfaces between modules) and a description of each module (e.g., allocated requirements, interfaces and processing, language, new/reused/modified/commercial item code). The presentations will include traceability of requirements to each software configuration item and shall clearly demonstrate how the design meets these requirements.

The software design reviews shall clearly show how the software can be expanded to incorporate future growth. The software design review shall discuss coding standards, the extent of new/reused/modified/commercial item code, languages, and division of software. The design review shall discuss cybersecurity implementation (e.g., code review and evaluation, risk assessment, modification of implemented controls). The software design review shall provide a rationale for the use of new/reused/modified code considering factors such as the state of code being considered (e.g., extent of verification, extent of operational certification, extent of security accreditation/certification), current and future obsolescence and compatibility. The software design review shall provide rationale for the use of commercial item code considering factors such as suitability, ease of use, state of code being considered (extent of verification, extent of operational certification, extent of security accreditation/certification), and life-cycle support and obsolescence.

2.1.2.2 Software Requirements Review (SRR)

The Contractor shall conduct SRRs to finalize the GPNTS software requirements. The Software

Requirements Specification (SRS) shall be updated and delivered as the baseline following the

SRRs.

A005 - Presentation Material

A009 - Software Requirements Specification / Interface Requirements Specification

2.1.2.3 Preliminary Design Review (PDR)

The Contractor shall conduct a PDR as defined in SPAWARINST 5400.3A, for each increment/version of the GPNTS system. The PDR shall serve to:

a. Evaluate the progress, technical adequacy, and risk resolution of the selected design approach.

b. Determine compatibility with performance and engineering requirements for the development specifications.

c. Establish the existence and compatibility of the physical and functional interfaces among items of equipment, facilities, computer programs, and personnel.

d. Identify the user system interface requirements definition.

e. Present any changes to the modification since previous design reviews, as applicable.

f. Provide traceability from software requirement to TRD requirement

g. Provide summary list on any modification to existing CDRL for a new requirement change or design change.

2.1.2.4 Critical Design Review (CDR)

The Contractor shall conduct a CDR as defined in SPAWARINST 5400.3A, for each increment/version of the software to baseline the software section of the GPNTS and to insure the final software design satisfies the performance and engineering specifications listed in the

GPNTS System/Subsystem Specifications. The Contractor shall establish detail design compatibility among system components, assess configuration item risk areas and review preliminary product specifications. The Contractors input shall focus on determination and acceptability of the design, risk mitigation, and testing strategy. During the CDRs, the

Contractor shall present those items below as they relate to the new and modified software:

a. Establish that the detailed design solutions, as reflected in the design documentation, satisfy the requirements established in the Government-provided specifications.

b. Demonstrate control of the overall technical program risks associated with technical, cost, and schedule aspects.

c. Present status of software languages and applications to be used in the overall GPNTS software.

d. Demonstrate the establishment of an effective human-machine interface.

e. Establish the adequacy of specific software documentation that will be released for coding and testing.

f. Present preliminary test results on critical requirements.

g. Present the status of specifications and acceptance test plans.

2.1.2.5 Software Test Readiness Review (TRRs)

The Contractor shall conduct TRRs as defined in SPAWARINST 5400.3A, prior to formal testing of software releases. Software deficiencies that may impact the test results shall be presented for Government approval. The reviews shall address what testing the Contractor has already accomplished and the results of those tests, and a proposed approach to resolve outstanding deficiencies. Software Test Procedures to be used shall also be presented along with any recommended modifications. The TRR shall include any test tool validation and verification result to ensure test integrity. TRR criteria are defined in GPNTS Software Development Plan

(SDP).

2.1.2.6 System Test Readiness Review (TRRs)

The Contractor shall conduct TRRs as defined in SPAWARINST 5400.3A, prior to formal testing of software releases. System deficiencies that may impact the test results shall be presented for Government approval. The reviews shall address what testing the Contractor has already accomplished and the results of those tests, and a proposed approach to resolve outstanding deficiencies. System Integration Test Procedures used shall also be presented along with any recommended modifications. The TRR shall include any test tool validation and verification result to ensure test integrity. TRR criteria are defined in System Integration Plan.

2.1.2.7 Functional Configuration Audit (FCA)

The objective of the FCA is to verify the Configuration Items (CI’s) and system’s performance against its approved functional and allocated configuration documentation. The software CI (or

Computer Software Configuration Item (CSCI)) FCA ensures that all requirements have a related test step, and the test, as performed by test engineers, passes successfully.

The Contractor shall:

a. Conduct the FCA to verify that the CI meets its performance requirements as documented in the approved Functional Configuration Documentation and Allocated Configuration

Documentation.

b. Not audit the CI without prior Government approval of the Functional Baseline and

Allocated Baseline of the CI or system involved.

c. Conduct the FCA for designated CIs to verify the system allocated and product configuration baselines.

d. Support and participate in the FCA for related CIs, as identified by the Government.

e. Conduct incremental, lower-level CI audits leading up to the system level audits.

f. Establish the schedule for audits to be conducted at Contractor’s facilities including the agenda for each configuration audit in consonance with the Integrated Master Schedule

(IMS) and obtain Government’s approval.

g. Ensure that each configuration audit schedule is compatible with the availability of the necessary information and contract articles, (e.g., system engineering data, released engineering documentation, trade study results, producibility analysis results, risk analysis results, product specifications, quality control records, manuals, drawings, reports, hardware, Interface Design Document, and Software Version Description (SVD) for software, or firmware code).

h. Ensure sub-contractors participate in planning and conducting configuration audits and an audit plan is prepared to identify their requirements and responsibilities.

i. Designate a representative for the audit.

j. Provide a current listing of all changes against the CI either requested or approved.

k. Ensure that participating Contractor and Sub-contractor personnel are prepared to discuss the technical detail of the presented materiel.

l. Participate in the resolution of discrepancies identified during the FCA.

m. Summarize conclusions and add appropriate comments summarizing the side meetings and the main meeting into the official minutes.

n. Document significant questions and answers, action items, conclusions, and recommended courses of action resulting from each audit.

o. Record all discrepancies identified during the audit and process each one until it is closed out or a suitable residual task, including identification of responsible activities and suspenses, has been established which will lead to the close out of the discrepancy/action item.

p. Verify the implementation of engineering changes and variance corrective actions to confirm consistency is maintained between the product, its product configuration information and related supported assets.

q. Be completed prior to closing out the CSCI-related trouble report(s).

r. Document each FCA non-compliance and provide to the government for appropriate action.

s. Use test data from the verification of the CI for the FCA.

When audits are conducted in increments, the Contractor shall support a final audit to ensure that all requirements of the Functional Baseline (FBL), Allocated Baseline (ABL) and Product

Baseline (PBL) have been satisfied.

Contractor shall complete all audit entry and exit criteria prior to completion or close-out of the audit.

The Contractor shall provide the following information to the Government prior to the audit date:

a. List of items to be audited to include documents.

b. List of tasks to be accomplished at the FCA for the CI.

c. Matrix that identifies and provides traceability for all requirements; includes a cross reference to the test plans, test procedures, test programs with automatic/automated test equipment (when applicable), test reports (results of demonstrations, inspections and analyses for each requirement) and any known deficiencies supported by applicable deficiency report numbers.

The Contractor shall provide the following information and data necessary to support the FCA:

a. The configuration documentation for the CI being audited.

b. All approved changes.

c. An account of the changes incorporated and tested as well as proposed.

d. Test plans, specifications, descriptions, procedures, recorded results and analyses for the

CI.

e. A general discussion of the entire CI test effort delineating problem area accomplishments.

f. CI requirements that were not met, including a proposed remedy for each item.

g. Complete list of test requirements not yet performed and a plan for accomplishing each requirement.

h. Analyses or simulations for those requirements which cannot be completely verified using testing.

i. Provide the following for CSCIs:

1. Database characteristics, storage allocation data and timing and sequencing characteristics for compliance with specified requirements.

2. Documents that comprise or describe the contents or the use of the software product for format and completeness (e.g., Software Product Specification, User’s

Manual, SVD))

3. Records that reflect the changes made to the developmental configuration for the

CSCI.

4. Listing of all versions of the developmental and non-developmental software, firmware for the CSCIs that are in the software library.

5. Findings of all internal CM and software, firmware QA audits of the CSCI.

j. Preliminary and Critical Design Review (CDR) minutes for the Government’s examination to ensure that all findings have been incorporated and completed and that all action items are closed.

The Supplier shall provide the FCA minutes to include the requirements traceability and test matrix.

A005 - Presentation Material

A006 - Report, Record of Meeting/Minutes

A010 - Configuration Audit Plan

2.1.3 Automated Interchange of Technical Information Management

The Contractor shall deliver all contract, technical, and/or engineering documentation required by this statement of work in digital format and shall post one electronic copy to a Government shared server as specified in the CDRLs (DD Form 1423). CDRLs shall be scanned and debugged of computer viruses. Unless otherwise approved by the Government, the Contractor shall use Microsoft Office 2010 (e.g. Microsoft Word 2010, Microsoft Excel 2010, Microsoft

PowerPoint 2010) (or latest Government supported version) and Microsoft Project 2010 (or latest

Government supported version), AutoCAD 2012, and Adobe PDF format for the preparation of documents. At the Government’s request, the contractor shall submit documents with write-to privileges, as opposed to read-only privileges, via electronic format.

The Contractor shall develop technical information data exchange procedures that standardize the format, information structure, and transfer methods for exchanging CDRL items electronically. The Contractor shall provide information via electronic mail notification to the personnel identified on the CDRL Addressee List within twenty-four (24) hours of CDRL delivery. The contractor shall provide an outline of the procedures for providing soft copy distribution of data items, as specified in the contract CDRLs (DD Form 1423). This outline shall be developed and included in the first progress report.

2.1.4 Technical Data Management

The Government will retain unlimited rights to the Technical Data Package (TDP) as defined by

DFARS 252.227-7013 and 252-227-7014. The GPNTS TDP includes GPNTS Master Ordering

List, Production Drawings, Family Tree, System Interconnect Drawings, and Software Source

Code. The TDP will be delivered to the Contractor as Government Furnished Information (GFI), and the Government will maintain configuration management of the TDP.

2.1.5 Modular Open Systems Approach/Open System Architecture

The Contractor shall maintain an open architecture that incorporates appropriate considerations for interoperability, supportability, composability, technology insertion, vendor independence, reusability, scalability, upgradeability, and long-term supportability as required by the 23 DEC

2005 Office of the Chief of Naval Operations (OPNAV N6/7) requirements letter.

The Contractor shall maintain an open architecture that supports a Modular Open System

Approach (MOSA), and deliver an Open System Management Plan. The open architecture shall support a layered and modular implementation approach, which maximizes the use of available

COTS technology (e.g., hardware, operating systems, software, and middleware) and

Government-Off-The Shelf (GOTS), where development is required for building systems.

MOSA and analysis of long term supportability, interoperability, and growth for future modifications shall be major factors in the Contractor’s final integration approach. All the system components shall facilitate future upgrades and permit incremental technology insertion to allow for incorporation of additional or higher performance elements with minimal impact on the existing systems.

The architectural approach shall provide a viable technology insertion methodology and refresh strategy that supports application of a MOSA and is responsive to changes driven by mission requirements and new technologies.

The Contractor shall maintain a detailed open architecture modular design and integration that takes into consideration system interoperability, intra-operability, upgradeability, reconfigurability, transportability, software standards, interface standards, long-term supportability, sources of supply and/or repair, business strategies, and other entities that affect application of a MOSA.

For those portions of software that are driven to proprietary and/or closed system architectures by mission specific requirements, a software partitioning or other design features to mitigate the system level impacts shall be provided to and approved by the Government.

The Contractor shall provide an orderly, planned approach to address migration of proprietary or closed software components or interfaces to a modular design when technological advances are available.

The Contractors modular design and integration shall preclude long term dependence on closed or proprietary interface standards, technologies, products, or architectures. Secure or classified data systems shall also conform to the modular design approach as much as practicable. The

Contractor shall provide sufficient growth and open interface standards to allow future reconfiguration and addition of new capabilities without large-scale redesign of the system.

A011 - Open System Management Plan

2.1.6 Net-Centric Enterprise Solutions for Interoperability (NESI) Compliance

Net-Centric Enterprise Solutions for Interoperability (NESI) compliance shall be presented at all design reviews to ensure system and software design conforms to NESI tenants described in the

NESI evaluation checklists. Below is a list of NESI items that the Contractor shall follow:

a. All software shall follow NESI Part 3 located at http://nesipublic.spawar.navy.mil for transitioning software solutions.

b. All software shall follow NESI Part 4 located at http://nesipublic.spawar.navy.mil for building nodes.

c. All software shall follow NESI Part 5 located at http://nesipublic.spawar.navy.mil for developing software solutions.

d. All software development will be required to assess compliance using the NESI evaluation checklists for Parts 4, and 5 located at http://nesipublic.spawar.navy.mil.

The Contractor shall develop a NESI Assessment and Migration Plan, with emphasis on the SOA

Migration Plan. The plan shall contain the Contractor’s proposed use of guidance and best practices from the NESI Part 3: Migration Guidance. This plan shall also contain the results of the assessment described in item d above.

CDRL Deliverable:

A012 - NESI Assessment and Migration Plan

2.2 STUDIES AND ANALYSIS

As authorized by individual TOs, the Contractor shall conduct studies and analyses as authorized by the Government in the areas of software engineering for new requirements, correction of test and evaluation deficiencies, operational improvements, and technology improvements to the

GPNTS software. The studies shall address cybersecurity implementation, analysis and risk assessment. The studies shall address Engineering Change Proposals (ECPs) and other related documents (See Section 3.0 of this SOW). The Contractor shall provide technical reports assessing any potential performance, schedule, technical, logistic, or cost impacts to GPNTS software and provide a supporting analysis and a recommended course of action. All Contractor deliveries shall meet the requirement of this SOW, TRD, GPNTS System Performance

Specification, Software Requirement Specification and GPNTS TDP. Whenever the Contractor’s modification does not match the existing package, the Contractor shall document these changes through an ECP and receive Government authorization prior to implementation. As authorized by individual TOs, the studies shall also include research into emerging GPNTS requirements.

A013 - Technical Report – Study/Services

A014 - Engineering Change Proposal

2.3 GOVERNMENT PROPERTY

Government Furnished Property (GFP) is property in the possession of, or directly acquired by, the Government and subsequently furnished to the contractor for performance of a contract.

Government furnished property is made up of equipment and material and includes, but is not limited to, spares and property furnished for repairs, maintenance, overhaul, or modification.

2.3.1 GFP Reporting

In accordance with DFARS clause 252.211-7007 the performer shall report Government-furnished property to the Item Unique Identification (IUID) Registry and update the IUID

Registry as the status of the property changes based on property lifecycle events.

A015 - Government Furnished Property Report (GFPR) http://nesipublic.spawar.navy.mil/

2.3.2 GFP Marking

In accordance with DFARS clause 252.245-7001 the performer shall tag, label, or mark government furnished property that is not already tagged, labeled, or marked with a 2D compliant data-matrix per the DoN IUID Marking Guide: Applying Data Matrix Identification

Symbols to Legacy Parts Version 1.1 dated September 2011.

2.3.3 GFP Tracking

The Contractor shall also be responsible for tracking all GFP which includes both equipment and material provided under the contract. The Contractor shall provide a quarterly GFP report to include all Government Furnished Equipment (GFE) in support of this contract per Government

Furnished Property Report (GFPR).

2.3.4 GFP Return

All of Government Furnished Equipment (GFE) and any excess Government Furnished Material

(GFM) will be returned to the Government upon completion of task at the below point of contact and address. For a list of associated GFP, please see Attachment X (Scheduled GFP List).

SPAWAR Systems Center Pacific, Code 5235

4297 Pacific Highway, Building 7

San Diego, CA 92110-5000

Mark for Building 48 (GPNTS)

Attn: Leslie White (619) 553-5948 office, (619)552-5773 Lab

2.3.5 Contractor Acquired Property

In support of engineering efforts and as authorized by TOs, the Contractor shall make the necessary equipment and material purchases to implement software design modifications to the

GPNTS system. The Contractor shall provide pricing and delivery information for this material support as requested by the Government. The schedule for any material delivery shall be mutually agreed upon between the Contractor and the Government.

2.3.6 Item Unique Identification (IUID)

The Department of Defense (DoD) policy is that Government Furnished Equipment (GFE) shall be recorded in the DoD IUID Registry in accordance to DFARS 211.274-4, and as defined in the clause at 252.211-7007 Reporting of Government-Furnished Property. Data can be submitted to the IUID Registry via Invoicing, Receipt, Acceptance, and Property Transfer (iRAPT) for new acquisition item registration or property transfers for GFP items, by submitting an XML file or flat file through the Global Exchange (GEX) Service, or, for some items, via the IUID Registry within the WAWF e-Business Suite https://wawf.eb.mil. The Contractor shall update the DoD

IUID Registry for changes in status, mark, custody, or disposition of items:

a. Delivered or shipped from the Contractor's plant, under Government instructions, except when shipment is to a subcontractor or other location of the Contractor;

b. Consumed or expended, reasonably and properly, or otherwise accounted for, in the performance of the contract as determined by the Government property administrator, including reasonable inventory adjustments;

c. Disposed of; or

d. Transferred to a follow-on or other contract.

The Contractor shall comply with DoD IUID policy for equipment, spares, and storage containers provided and acquired in accordance with DFARS 252.211-7003, MIL-STD-130N and PMW/A 170 UID Plan. The Contractor shall submit an IUID Marking and Verification

Report, which lists each end item and corresponding IUID.

A016 - Unique Identification (IUID) Marking and Verification Report

2.4 CONFIGURATION MANAGEMENT PROGRAM

As authorized by individual TOs, the Contractor shall establish, implement and control a

Configuration Management (CM) program to control all configuration documentation representing or comprising the configuration item. The Contractor shall utilize the Government

Configuration Management process within the RITE to manage all source code and documentation. The latest revisions of the configuration baseline documents shall serve as the configuration baseline from which engineering changes will be developed under this contract.

2.4.1 Configuration Management and Planning

The Contractor shall define a configuration management approach and shall perform the following activities appropriate for the work under this contract:

a. Objectives of the CM program and of each applicable CM element.

b. Appropriate level of CM activity for each CM function throughout the product’s life cycle.

c. CM organization and organizational relationships.

d. Responsibilities and authority of CM professionals.

e. CM resources to be used (tools, techniques, training, and methodologies).

f. Coordination activities to be used with internal and external agencies (e.g., Government, other Contractors, other Government agencies, foreign governments).

g. Functions, responsibility, and authority of CCBs.

h. A release process for product configuration documentation.

i. Methods to be used to ensure the effectiveness of sub-Contractor/sub-vendor CM processes.

j. CSA activities for creating, editing, reviewing, approving, releasing, publishing, and distributing product configuration documentation and configuration change documentation.

k. Identification and labeling structure for CIs.

The Contractor shall document this approach in a Configuration Management Plan (CMP). The

Contractor shall submit the CMP for review to the Government, in accordance with the CDRL, describing the processes, methods and procedures used to manage the functional, logical and physical characteristics of the assigned CI(s) for the life of the contract.

A017 - Configuration Management Plan (CMP)

2.4.2 Configuration Identification

The Contractor shall use a documented process for configuration identification. Refer to paragraph 2.3.6 for unique identification details.

2.4.2.1 Identification, Labeling and Marking

The Contractor shall accomplish the following:

a. Establish a CI structure and hierarchy.

b. Select configuration documentation to be used to define configuration baselines for each

CI.

c. Identify and control interfaces.

d. Assign system product-unique identifiers to elements of the software development environment such as Commercial-Off-the-Shelf (COTS) development products like compilers, linkers, loaders, binary developmental libraries, configuration settings, automation scripts, and other elements that are part of the system and will conform to the format specified in the CMP.

e. Ensure the part number and the software medium is labeled with the Contractor’s code/name identification and marked separately on the device.

f. Include the CAGE Code of the Design Activity for software and affix those CAGE codes to all CIs, their subordinate parts and assemblies, configuration documentation, software media, and products.

g. Place each item of configuration documentation (e.g., item, material, or process specifications) and software specification, SVD, etc. under configuration control.

h. Establish and manage the functional, allocated and product baselines at the appropriate points in the system/CI life cycle, upon Government approval/contractual implementation of the configuration documentation.

i. Mark or label items and documentation with their applicable identifiers that correlates to the item, configuration documentation and other associated data,

j. Obtain government approval of the type designation and nomenclature for each CI that is designated by the government for control, tracking and logistics purposes.

k. Embed software identifier and version in the source code header.

l. Mark each software medium (i.e., disks, hard drives) with a label.

m. Each label shall contain, or provide cross-reference to, a list of the applicable software identifiers of the entities it contains.

n. The label shall also indicate the status of the software maturity on the medium, e.g., whether this software is a release candidate or if the software has been tested and verified."

o. Mark with a label all CSCIs deliverable media. Label shall contain:

1. Government Contract number.

2. CSCI Number (include a designator indicating whether source or executable code).

3. Design activity Cage Code.

4. Media Number (e.g., 1 of 2, 2 of 2) if there are multiple units per set. Each time a new version of software is issued, new copy numbers, starting from 1, must be assigned.

2.4.2.2 Technical Baseline

The Contractor shall generate the configuration documentation required for the configuration baselines being established by the Government, as required by the contract. The Contractor shall ensure each succeeding baseline is traceable to, and a detailed extension of, its predecessor(s).

A018 - Baseline Description Document

2.4.2.2.1 Functional Configuration Documentation

The Contractor shall document the FBL of a CI by:

a. Describing its functional, performance, interoperability and interface requirements.

b. Describing the verifications required to demonstrate achievement of those requirements.

c. Identifying any specialized software and documenting the operating environment used to author the above requirements.

2.4.2.2.2 Allocated Configuration Documentation

The Contractor shall document the ABL of a CI by:

a. Describing its functional, performance, and interoperability requirements that are allocated from those of a system or higher-level configuration item; and interface requirements with interfacing configuration items.

b. Describing the verifications required to demonstrate achievement of those requirements.

c. Identifying any specialized software and documenting the operating environment used to author the above requirements.

2.4.2.2.3 Product Configuration Documentation

The Contractor shall document the PBL of a CI by:

a. Describing its detailed design including necessary physical (form, fit, and function) characteristics and selected functional characteristics designated for production, acceptance testing and production test requirements.

b. Identifying the verifications necessary for accepting product deliveries (first article and acceptance instructions).

c. Identifying and documenting the design of any special tooling, software, equipment and facilities required to manufacture, operate, maintain, calibrate, or inspect items contained in the design.

d. Identifying and documenting the design of any special packaging parts required to package the CI.

e. Including any quality assurance provisions required to accept deliveries of the CI (first article or acceptance inspection).

f. Including any unique process specifications required to manufacture, operate, maintain, or calibrate items contained in the design.

g. Identifying any specialized software and documenting the operating environment used to author the detailed design.

h. Include technical data which provides instructions for the installation, operation, maintenance, training, and support of a system or equipment.

2.4.3 Configuration Control

The Contractor shall not perform any changes to contract delivered software, unless authorized by the responsible Contracting Officer’s Representative (COR), Alternate COR (ACOR), and/or

Procuring Contracting Officer (PCO). All software changes shall be documented. The

Contractor shall also propose changes to the performance specifications for systems included in this SOW. Formal baseline changes under this contract will occur following successful testing of each engineering change, delivery of documentation supporting the changes, and approval by the Government.

The Contractor shall use the latest documented revisions of the baselines from which engineering changes will be developed under this contract. The Contractor shall document proposed changes to the latest documented revision of the GPNTS baseline.

Within the CMP, the Contractor shall describe the change management processes. At a minimum, the Contractor shall address change initiation, change disposition, change reviews, change approval, and change implementation. Additionally, the Contractor shall ensure that the processes conform to the terms of the DO and contract with respect to changes in contracted work.

The Contractor shall apply configuration control to each CI, its components and configuration documentation. The Contractor shall ensure that:

a. Configuration baselines are maintained and controlled.

b. Configuration identification control of all CIs and their associated configuration documentation is maintained.

c. Product configuration changes and variances are documented, coordinated, evaluated, dispositioned, and recorded in a CM/status accounting system and reported to the

Government.

d. Requested configuration changes and variances address all areas of impact, to include cost, operational, sustainment, and implementation actions (e.g., ordering material, designing tooling, manufacturing planning, and interface design, support equipment, software code, producing parts, retrofit).

e. Released/approved configuration changes are incorporated into all product configuration information including the CM/status accounting system, and implemented into each product/CI/component impacted, in a timely manner.

f. Released/approved configuration changes are verified as being incorporated to maintain product configuration control and product configuration information consistent and prepare release authorization documentation.

g. Released/approved variance corrective actions are implemented and verified.

2.4.4 Configuration Status Accounting

Within the CMP, the Contractor shall describe the mechanism for recording, tracking, and reporting the status of Configuration Items (CIs). Upon the Government’s request, the

Contractor shall create and deliver Configuration Status Accounting Information (CSAI) to provide details about the status of CIs associated with the work performed by the Contractor pursuant to this contract.

The Contractor shall:

a. Make CSA system and product configuration information readily available to the

Government, via on-site inspection, remote access, or regular submissions of CSA information and updates in accordance with the contract.

b. Be in compliance with DoD Cyber Security requirements for interoperating with the

Government’s system as in an integrated digital environment.

c. Ensure recorded product configuration information is adequately secured, safeguarded and retrievable after extended storage.

Provide a digital delivery to the Government upon the completion of the contract, CSA information and configuration baseline documentation created, collected, and managed during the contract. The form, format and delivery date for this data delivery will be in accordance with

DID.

A019 - Configuration Status Accounting Information (CSAI)

2.4.4.1 Configuration Verification and Audits

Within the CMP, the Contractor shall describe the process for auditing configurations. At a minimum, the Contractor shall address the types of audits that are to be performed, the audit procedure, the frequency of audits, and the auditing authority.

2.5 SOFTWARE SUPPORT ACTIVITY ENGINEERING

As directed by individual DO the Contractor shall perform the following:

2.5.1 Technical Approach

The technical approach to this effort is based on the concept of GPNTS that includes a common open systems architecture, common software, common technical documentation, and a single

Software Support Activity (SSA). The common software configuration approach includes the structure of the code; the databases used to track requirements, software source files, baseline documentation, and the verification and validation process/ procedures. The Government requires that the GPNTS software be maintained and further developed using the common configuration approach. The contractor shall establish GPNTS software architecture, development environment and test environment comprised of Department of the Navy

Applications and Database Management System (DADMS) registered operating systems, applications and utilities. Any applications or utilities that are required to be a part of the

GPNTS configuration but for which an acceptable DADMS-registered alternative is not available must be identified, and time allocated for a discussion of alternatives.

The approach shall focus on commonality and the convergence of unique elements into GPNTS.

The Government shall control the software requirements database and control…