Attachment 1 - GPNTS Software SOW.pdf

STATEMENT OF WORK (SOW)

FOR

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

TIMING SERVICE (GPNTS)

SOFTWARE SUPPORT CONTRACT

2 November 2018

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 (2 November 2018)

Table of Contents

1.1 SCOPE

2.0 PERSONNEL QUALIFICATIONS

2.1 KEY PERSONNEL

3.0 REQUIREMENTS

3.1 PROGRAM AND DATA MANAGEMENT

3.1.1 Program Management

3.1.1.2 Manpower Reporting

3.1.1.3 Post Award Conference (PAC)

3.1.1.4 Program Management Reviews (PMRs)

3.1.1.5 Program Protection Implementation Plan (PPIP)

3.1.1.6 Integrated Master Schedule (IMS)

3.1.1.7 Integrated Program Management System

3.1.1.8 Integrated Program Management Report (IPMR)

3.1.1.9 Integrated Baseline Review (IBR)

3.1.1.10 Integrated Subcontract Management

3.1.1.11 Schedule Risk Assessment (SRA)

3.1.1.12 Over Target Baseline (OTB)/Over Target Schedule (OTS) Approval

3.1.1.13 Contract Funds Status Report (CFSR)

3.1.1.14 Contract Work Breakdown Structure (CWBS)

3.1.2 Design Reviews

3.1.2.1 Software Design Reviews

3.1.2.2 Software Requirements Review (SRR)

3.1.2.3 Preliminary Design Review (PDR)

3.1.2.4 Critical Design Review (CDR)

3.1.2.5 Software Test Readiness Review (TRRs)

3.1.2.6 System Test Readiness Review (TRRs)

3.1.2.7 Functional Configuration Audit (FCA)

3.1.3 Automated Interchange of Technical Information Management

3.1.4 Technical Data Management

3.1.5 Modular Open Systems Approach/Open System Architecture

3.2 STUDIES AND ANALYSIS

3.3 GOVERNMENT PROPERTY

3.3.1 GFP Reporting

3.3.2 GFP Marking

3.3.3 GFP Tracking

3.3.4 GFP Return

3.3.5 Contractor Acquired Property

3.3.6 Item Unique Identification (IUID)

3.4 CONFIGURATION MANAGEMENT PROGRAM

3.4.1 Configuration Management and Planning

3.4.2 Configuration Identification

3.4.2.1 Identification, Labeling and Marking

3.4.2.2 Technical Baseline

3.4.3 Configuration Control

3.4.4 Configuration Status Accounting

3.4.4.1 Configuration Verification and Audits

3.5 SOFTWARE SUPPORT ACTIVITY ENGINEERING

3.5.1 Technical Approach

3.5.1.1 Software Development Approach / Software Development Plan (SDP)

3.5.2 Systems Engineering Management Plan

3.5.3 System Performance Specification/ System/Subsystem Specification

3.5.4 Human System Integration/Human Factors Engineering

3.5.5 Cybersecurity

3.5.5.1 Cybersecurity Engineering

3.5.5.2 System Security Plan

3.5.5.3 Cyber Incident Reporting

3.5.5.4 Security Controls

3.5.6 Software Quality Assurance

3.5.6.1 Management of Quality Assurance

3.5.6.2 Standards for Quality Assurance

3.5.6.3 Software Reviews for Quality Assurance

3.5.6.4 Problem Reporting and Corrective Plans for Quality Assurance

3.5.6.5 Risk Management for Quality Assurance

3.5.6.6 Records Management for Quality Assurance

3.5.7 Software Delivery

3.5.8 Software Sustainment Support

3.5.9 Software Integrated Process Teams

3.5.10 Software Development

3.5.10.1 Problem Report (PR) Analysis

3.5.10.2 PR Resolution

3.5.10.3 New Development and Upgrades

3.5.10.4 Software Builds

3.5.10.5 Engineering Drops

3.5.10.6 Information Assurance Vulnerability Alert (IAVA) Updates and Patches .. 36

3.5.11 Software Documentation

3.5.11.1 Software Requirements Specification

3.5.11.2 Software Version Description

3.5.11.3 Software Product Specification

3.5.11.4 Software Design Description

3.5.11.5 Interface Design Description

3.5.11.6 Interface Control Document

3.5.11.7 Software Installation Plan

3.5.12 Software Testing

3.5.12.1 Acceptance Testing in the Contractors Lab

3.5.12.2 Acceptance Testing at Government Facility

3.5.12.3 Pre-Qualification Acceptability Testing

3.5.12.4 Software Verification Matrix

3.5.12.5 Automated Testing

3.5.12.6 Verification, Validation, and Accreditation

3.5.13 Software Interface

3.5.14 Source Code Analysis

3.5.15 Software System Safety

3.5.16 System Testing

3.5.16.1 System Requirements Verification Matrix (SRVM)

3.5.16.2 System Integration Testing

3.5.16.3 Formal Qualification Testing (FQT)

3.5.16.4 Verification, Validation, and Accreditation

3.5.17 Interactive Electronic Technical Manual (IETM)

3.6 ENGINEERING SUPPORT

3.6.1 Engineering Support

3.6.2 Field Engineering Support

3.6.3 Military Code (M-Code) Integration Engineering Support

3.7 SECURITY PROGRAM IMPLEMENTATION

4.0 APPLICABLE DOCUMENTS

4.1 GPNTS DOCUMENTS

4.2 SECURITY DOCUMENTS

4.3 OTHER DOCUMENTS

5.0 ADMINISTRATIVE MATTERS

5.1 CONTRACTING OFFICER’S REPRESENTATIVE

Acronyms

1.1 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 PERSONNEL QUALIFICATIONS

The personnel qualifications listed in Attachment 5 are required for all personnel performing on this contract. During performance, the Government reserves the right to require the Contractor to submit resumes for Government review/approval for personnel performing on this task (this includes the addition or substitution of personnel). Each resume must clearly demonstrate compliance with the personnel qualification requirements in Attachment 5 as it relates to the labor category for which they are being proposed. Upon review, the Government, either the Contract Officer’s Representative (COR) or the Contracting Officer, will inform the Contractor as to the acceptability of the proposed individual(s) as it relates to the Attachment 5 requirements. Please note, the Government, either the COR or the Contracting Officer, reserves the right, at its discretion, to waive required personnel qualifications on a case by case basis when in the best interest of the Government.

2.1 KEY PERSONNEL

(a) The contractor agrees to assign to this contract those key personnel listed in paragraph (d) below. No substitutions shall be made except in accordance with this text.

(b) The offeror agrees that during the first (to be determined at task order level) days of the contract performance period no personnel substitutions will be permitted unless such substitutions are necessitated by an individual's sudden illness, death or termination of employment. In any of these events, the contractor shall promptly notify the Contracting Officer and provide the information required by paragraph (c) below. After the initial (to be determined at task order level) day period, all proposed substitutions must be submitted in writing, at least fifteen (15) days (thirty (30) days if a security clearance is to be obtained) in advance of the proposed substitutions to the contracting officer. These substitution requests shall provide the information required by paragraph (c) below.

(c) All requests for approval of substitutions under this contract must be in writing and provide a detailed explanation of the circumstances necessitating the proposed substitutions. They must contain a complete resume for the proposed substitute or addition, and any other information requested by the Contracting Officer or needed by him to approve or disapprove the proposed substitutions. All substitutions proposed during the duration of this contract must have qualifications of the person being replaced. The Contracting Officer or his authorized representative will evaluate such requests and promptly notify the contractor of his approval or disapproval thereof in writing.

(d) List of Key Personnel (to be determined at task order level)

(e) If the Contracting Officer determines that suitable and timely replacement of key personnel who have been reassigned, terminated or have otherwise become unavailable for the contract work is not reasonably forthcoming or that the resultant reduction of productive effort would be so substantial as to impair the successful completion of the contract or the service order, the contract may be terminated by the Contracting Officer for default or for the convenience of the Government, as appropriate. In addition, if the Contractor is found at fault for the condition, the

Contracting Officer may elect to equitably decrease the contract price or fixed fee to compensate the Government for any resultant delay, loss or damage.

(f) If the offeror wishes to add personnel to be used in a labor category he shall employ the procedures outlined in paragraph (c) above. Adding personnel will only be permitted in the event of an indefinite quantity contract, where the Government has issued a delivery order for labor hours that would exceed a normal forty-hour week if performed only by the number of employees originally proposed.

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

3.1 PROGRAM AND DATA MANAGEMENT

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

3.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)

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

CDRL Deliverable(s):

A002 - Labor Hours Reporting

3.1.1.3 Post Award Conference (PAC)

The Contractor shall hold a PAC no later than forty-five (45) 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 TO 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

CDRL Deliverable(s):

A003 - Conference Agenda A004 - Presentation Material A005 - Report, Record of Meeting/Minutes

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

CDRL Deliverable(s):

A003 - Conference Agenda A004 - Presentation Material A005 - Report, Record of Meeting/Minutes

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

CDRL Deliverable(s):

A006 - Program Protection Implementation Plan

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

A007 – Integrated Program Management Report (IPMR)

3.1.1.7 Integrated Program Management System

The Contractor will establish, maintain, and use in the performance of this portion of the contract, an integrated performance management system. Central to this integrated system will be an Earned Value Management System (EVMS) in accordance with DFARS 252.242-7001 and DFARS 252.242-7002 Earned Value Management System (DEVIATION) (SEP 2015) and the Guidelines for an EVMS contained in EIA-748. In compliance with DFARS 252.242-7001 and 252.242-7002 Earned Value Management System (DEVIATION) (SEP 15), the Contractor will have an EVMS complying with EIA-748; however, the Government will not formally validate/accept the Contractor's management system unless the contract value including all known options is greater than or equal to $100M. While no validation is required below $100M, the Government will observe compliance during the course of the contract through the PMO assessment of the content, validity and the timeliness of the reports; For applicable CLINs valued over $100M, Defense Contract Management Agency (DCMA) EVMS validation is mandatory.

EVM will be applied to the individual task orders or group of related task orders in accordance with the requirements referenced in DoDI 5000.02, EVM requirements.

To establish the integrated performance management system, the EVMS will be linked to and supported by the Contractor's management processes and systems to include the IMS, Contract Work Breakdown Structure (CWBS), change management, material management, procurement, cost estimating, and accounting, as well as Agile processes if implemented on the contract.

The correlation and integration of these systems and processes will provide for early indication of cost and schedule problems, and their relation to technical achievement. Formal risk management will also be an integral part of the Contractor’s integrated performance management system and Integrated Program Management (IPMR) deliverables. Outputs of the integrated performance management system will be used as the single basis for timely, reliable, and auditable reporting of performance information in CDRLs, PMR and the data contained in the Contractor’s Progress, Status Management Report (CPSMR). Updates to the IMS will be reported as part of the schedule analysis section in IPMR Format 5 for the IPMR CDRL.

The Contractor's EVMS will be maintained in accordance with EIA-748, current version guidelines and requirements, DFARS Clause 252.234-7002 Earned Value Management System (DEVIATION) (SEP 15), and the Contractor's own documented EVMS Description. If the Government determines from Integrated Baseline Review (IBR) results, Joint Surveillance with the DCMA (if applicable), or quality assessments of cost and schedule data delivered in the IPMR, that EVMS deficiencies exist, the Government may perform a Compliance Review of the Contractor's EVMS.

3.1.1.8 Integrated Program Management Report (IPMR)

The Contractor will provide monthly IPMR detailing the integrated cost and schedule status of work progress on the contract in accordance with the IPMR CDRL. Written Government approval will be required before implementing any formal re-baseline of the Performance Measurement Baseline (PMB). The Government reserves the right to adjust the reporting levels and thresholds throughout the lifecycle of the program. DI-MGMT-81861A contains the content of each of the formats. And Block 16 of the IPMR CDRL further defines requirements. The IPMR formats are briefly described as follows:

• Format 1 (Mandatory) (DD Form 2734/1), WBS, defines cost and schedule performance data by product-oriented Work Breakdown Structure (WBS) comprising the hardware, software, and services the Government is buying.

• Format 2 (Optional for contract values less than $50M. Mandatory for contract values equal to/greater than $50M in then-year dollars) (DD Form 2734/2), OBS, defines organizational cost and schedule performance data rather than by individual CWBS elements. It also identifies each major subcontractor and material purchases.

• Format 3 (Optional for contract values less than $50M. Mandatory for contract values equal to/greater than $50M in then-year dollars), (DD Form 2734/3), Baseline, defines changes to the PMB which performance is measured.

• Format 4 (Optional for contract values less than $50M. Mandatory for contract values equal to/greater than $50M in then-year dollars), defines staffing forecasts for the Most Likely EAC by the same organizational categories as defined in Format 2.

• Format 5 (Mandatory) (DD Form 2734/5), Explanations and Problem Analyses, is a narrative report used to provide the required analysis of data contained in Formats 1and 3and to explain significant cost and schedule variances and other identified contract problems and topics. The report will address, at a minimum the cause(s), impact(s), and corrective action(s) of reporting elements exceeding thresholds.

• Format 6 (Mandatory) (DD Form 2734/5), IMS defines and contains the Contractor’s IMS with the Contractor’s integrated network, significant external interfaces, Government furnished equipment/information/property and relationship dependencies for the entire contractual effort.

• Format 7 (Mandatory) (DD Form 2734/5), Electronic History and Forecast File, defines the time-phased historical & forecast cost information in the DoD-approved electronic XML format, by WBS.

3.1.1.9 Integrated Baseline Review (IBR)

The Contractor will engage jointly with the Government's PM and technical staff in conducting IBRs focused on evaluating the realism and inherent risks in the Contractor's integrated PMB plan. The Contractor will present the contents and underlying/supporting assumptions of its initial PMB to Government representatives via an IBR to be held at the Contractor's facilities. At the discretion of the Government, subsequent IBRs will be conducted, as needed. At the contract PAC, the initial IBR event will be discussed to establish the soonest feasible date (e.g., as soon as the PMB is established and documented) but no later than 180 calendar days after contract award. However, in situations where the entire work scope is not known in the 180 days, the IBR will be conducted in stages, such as with an Undefinitized Contract Action (UCA). A review of the known work scope should be conducted within the 180-day window with follow-up IBRs scheduled at a later time for the work not yet completed in the context of the entire performance measurement baseline. As a rule of thumb, the initial IBR should run through the first major milestone for the program.

Each IBR will verify the Contractor has established and has maintained a reliable PMB that includes the entire contract scope of work; is consistent with contract cost targets and schedule requirements; has adequate resources assigned; and uses effective Earned Value (EV) techniques/methods to accurately reflect technical achievement/progress. Each IBR will record any indications that effective EVM is not being used. The scope of any subsequent IBRs will be tailored to the nature of the event, activity or work effort and the IBR will be conducted within a reasonable time after the occurrence of the program event. The Contractor will flow-down IBR requirements to those Subcontractors who meet the applicable thresholds for EVM reporting.

The Government may participate in Subcontractor IBR’s.

During contract performance, the Contractor will provide ongoing access to its records and data that underlie and support the PMB and cost and schedule data reported. The Contractor will provide IBR planning, documentation, artifacts, and close out activities as specified in the IBR

CDRL.

IBR entrance and exit criteria will include, at a minimum:

Entrance Criteria

• A plan for the integrated baseline has been established.

• The IBR conference location has been determined.

• An agenda has been formulated, accepted, and sent to all participants prior to the review.

• Advance IBR planning documentation and artifacts have been submitted in accordance with the IBR CDRL requirements.

• The Government APM/PM/COR and the Government EVMS representative have determined the Contractor is ready for the IBR based on comprehensive review of IBR artifacts.

Exit Criteria:

• All artifact concerns have been identified, and closure plans have been developed.

• Action items have been included in the risk management plan and mitigation strategies are in place.

• The PMB reflects the scope of contracted work and determines the PMB is achievable.

• Close-out activities and documentation of action items into the program’s tracking tool, and action item closure has been completed.

A008 – Integrated Baseline Review (IBR)

3.1.1.10 Integrated Subcontract Management

The Contractor will flow down the contractual reporting requirements to Subcontractors meeting the applicable thresholds (e.g. exceeding $20 million in then-year dollars). EVMS flow down to Subcontractor cost or incentive contracts of less than $20 million in then-year dollars, or to Firm Fixed Price subcontracts is a risk-based decision to be mutually agreed on between the prime Contractor and the COR prior to award. Any Subcontractor with a contract flow down requirement for EVM will also be included in the IBR. A separate IBR may be conducted at the Subcontractor’s facility, in which case the prime Contractor will take the lead in conducting the IBR, with Government participation. Alternatively, the Subcontractor may participate as part of the prime contract IBR. On subcontracts where EVM and IMS requirements are not flowed down, subcontracted scope and performance information will be incorporated/integrated into and reported in cycle with the Prime’s reporting via the Contractor's integrated performance management system and EVMS. The Contractor is responsible for reviewing and assuring the validity of all Subcontractors’ EVM reporting through surveillance and other means. It may be necessary to conduct IBRs even with Subcontractors who do not meet the dollar value threshold because of the risk inherent in their work, criticality of their performance to the total program, or percent of the total work share. Exceptions will be mutually agreed upon by the Contractor and the Government.

3.1.1.11 Schedule Risk Assessment (SRA)

The Contractor will conduct Schedule Risk Assessments (SRAs) in accordance with DI-MGMT- 81861A and the tailoring instructions provided in the Integrated Program Management Report CDRL. SRAs will be incorporated into the Contractor’s program risk management process and be produced from the Contractor’s schedule analysis tool. The Government may elect to participate in the SRA process. Any anticipated/ expected Government support will be identified at the contract PAC, or similar post award meeting, along with the anticipated Government response times, to avoid schedule disruption/delays. Block 16 of the IPMR CDRL, will define all required deliveries during program execution as well as the IBR. The results from the SRA will be submitted as attachments to the IPMR Format 5. SRA’s will also be required should the following situations occur on the program:

• Over Target Baseline (OTB)/ Over Target Schedule (OTS): An SRA will be submitted along with the request to initiate an OTB or OTS.

• Re-baseline or Single Point Adjustment. An SRA will be submitted before implementing a significant cost and schedule reset.

3.1.1.12 Over Target Baseline (OTB)/Over Target Schedule (OTS) Approval

The Contractor will implement an OTB/OTS if the PMB is no longer adequate to provide performance measurement information relative to the remaining work using the principles of

EVM and where improved control of the project would result. To prevent unnecessary and uncontrollable changes to the baseline, the Contractor will not implement an OTB/OTS without formal approval from the PCO. The Contractor will submit a formal request to the PCO requesting permission to implement an OTB and or OTS. The request will include a detailed plan and schedule for implementing the OTB/OTS that includes the ground rules, assumptions, remaining work scope impacted, variance adjustment plans and justifications, potential reporting changes/suspensions, documentation recommendations, and planned dates for implementation.

The Contractor will also identify EVMS discipline problems that contributed to rendering the current work plan unrealistic and provide plans/corrective actions that will prevent these problems from reoccurring. Following implementation of any Government approved OTB/OTS, an IBR will be conducted and IPMR variance thresholds specified in the CDRL may be reevaluated to ensure continued visibility into significant cost and schedule variances.

3.1.1.13 Contract Funds Status Report (CFSR)

The Contractor will develop a quarterly CFSR in accordance with DI-MGMT-81468, to include tailoring instructions provided in the CFSR CDRL. The CFSR will 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. The Contractor will present the data in accordance with Government fiscal year.

The Contractor will provide a reconciliation from the IPMR data to the CFSR as an attachment to IPMR Format 5 in the months when a CFSR is due.

The notes section of the CFSR will contain the information below. The information will be complete and not limited to the space on the CDRL form. Use additional page(s) as necessary to explain:

• The elements which formulate the open commitments

• The elements contained in termination liability

• Changes to the total contract funding as well as changes to the time phasing of funding as it relates to Government fiscal years

• The fee structure used to formulate the funding stream (particularly important for contracts with cost or schedule incentives using share ratios).

CDRL Deliverable(s):

A009 – Contract Funds Status Report (CFSR)

3.1.1.14 Contract Work Breakdown Structure (CWBS)

The CWBS shall be based on the WBS/Program Plan included in the RFP as Attachment 6. The Contractor shall extend the program WBS provided in Attachment 6 down to appropriate levels required to provide adequate internal management, surveillance, and performance measurement.

The Contractor shall submit its extended CWBS as part of its proposal response and use the extended CWBS in its proposal pricing submittals as appropriate. The Contractor deliver a Contract Work Breakdown Structure (CWBS) in accordance with Attachment 6 and CDRL DID requirements except or as modified by instructions in the CDRL

CDRL Deliverable(s):

A010 – Contract Work Breakdown Structure (CWBS)

3.1.2 Design Reviews

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

CDRL Deliverable(s):

A003 - Conference Agenda

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

A011 - Software Requirements Specification / Interface Requirements Specification

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

CDRL Deliverable(s):

A003 - Conference Agenda

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

3.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).

CDRL Deliverable(s):

A003 - Conference Agenda

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

CDRL Deliverable(s):

A003 - Conference Agenda

3.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 suspense’s, 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 - Report, Record of Meeting/Minutes A012 - Configuration Audit Plan

3.1.3 Automated Interchange of Technical Information Management

The Contractor shall deliver all contract, technical, and/or engineering documentation required by this SOW in digital format and shall provide one (1) electronic copy to the Government.

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 reference Block 14 and 16 of the CDRL for guidance on delivery of the CDRL. The contractor shall provide an outline of the procedures for providing soft copy distribution of data items, as specified in the contract CDRLs. This outline shall be developed and included in the first progress report.

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

3.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 Commercial-Off-the-Shelf (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.

A013 - Open System Management Plan

3.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…