ePS_RFP_Attach_01_Performance Work Statement (PWS)_20170712.pdf

Electronic Procurement System Request for Proposal

Attachment 1: Performance Work Statement

Acquisition Category (ACAT 1) Version: 1.0 12 July 2017

Distribution Notice D: Authorized to the Department of Defense (DoD) and DoD Contractors only. This document is for administrative or operational use, as of the date of approval for this document. Refer to the Program Manager (PM), PMW 220 Navy Enterprise Business Solutions (Navy EBS), Program Executive Office Enterprise Information System (PEO EIS), Washington Navy Yard, 1325 10th St. SE, Bldg. 196, Washington, D.C. 20374 for additional document requests.

Handling and Destruction Notice: Comply with distribution statement and destroy by any method that will prevent disclosure of contents or reconstruction of the document.

ePS Performance Work Statement

(PWS)

File name:

EPS_RFP_Attach_01_Performance

_Work_Statement_(PWS).docx

Page:

2/115

Version:

Version 1.0

Date of Creation:

N00039-17-R-0002

Table of Contents 1 Introduction

1.1 PMW 220 NAVEBS

1.2 The ePS Program

1.3 Background

1.3.1 DON Legacy Procurement Systems

1.3.1.1 SPS

1.3.1.2 ITIMP

1.3.1.3 SeaPort-e

1.3.1.4 PRISM

1.3.2 NDAA

1.3.3 Users, Stakeholders, and Other Background Information

1.3.3.1 Installations and Logistics, Headquarters, U.S. Marine Corps (HQMC, I&L) ... 12

1.3.3.2 Marine Corps Systems Command (MARCORSYSCOM)

1.3.3.3 Military Sealift Command (MSC)

1.3.3.4 Naval Air Systems Command (NAVAIR)

1.3.3.5 Naval Facilities Engineering Command (NAVFAC)

1.3.3.6 Naval Sea Systems Command (NAVSEA)

1.3.3.7 Naval Supply Systems Command (NAVSUP)

1.3.3.8 Office of Naval Research (ONR)

1.3.3.9 Space and Naval Warfare Systems Command (SPAWAR)

1.3.3.10 Strategic Systems Programs (SSP)

1.3.3.11 Bureau of Medicine and Surgery (BUMED)

2 Scope

2.1 Acquisition of ePS

2.2 Terms of Reference

2.2.1.1 Out-of-the-Box (OOTB)

2.2.1.2 OOTB-Configuration

2.2.1.3 Future Enhancement to COTS

2.2.1.4 Business Process Re-engineering (BPR)

2.2.1.5 Extension

2.2.1.6 Plug-In

2.2.1.7 Other Customization

2.2.1.8 Modification (Software)

2.2.1.9 Software Maintenance

2.2.1.10 Regulation/Data Updates

2.2.1.11 Configuration Item

3 Applicable Regulations and Directives 4 Navy ePS Solution Capability and Requirements

_Work_Statement_(PWS).docx

Page:

3/115

Version:

Version 1.0

4.1 Product

4.1.1 CWS COTS Software Licenses

4.1.2 CWS COTS Software Support

4.1.3 Enterprise Service Bus (ESB) COTS Middleware

4.1.4 License Management

4.1.4.1 Technical Data Packages (TDP)

4.1.4.2 Government Purpose Rights

4.1.5 Application Management Requirements

4.1.6 Account Creation

4.1.7 Training Materials

4.1.7.1 Training Concept

4.1.7.2 Training Tiers

4.1.8 Technical Manuals

4.1.9 Warranty Support

4.1.10 Auditability

4.1.11 Cybersecurity Features

4.1.12 Counterfeit Prevention

4.2 Application Hosting Support

4.3 Integration

4.3.1 Systems Engineering and Design Support (SEDS)

4.3.2 Systems Engineering Technical Review (SETR) Support

4.3.3 Software Engineering

4.3.4 Requirements Support

4.3.5 Gap Closure

4.3.6 Enterprise Architecture (EA) Support

4.3.7 Interface Development and Management

4.3.8 Change Management Support

4.3.9 Configuration Management Support

4.3.10 Release Management Support

4.3.11 Test and Evaluation

4.3.12 Auditability

4.3.13 Cybersecurity

4.4 Implementation

4.4.1 Role Assessment

4.4.2 Role Mapping

4.4.3 Training Delivery

4.4.3.1 Vendor Training

4.4.3.2 Instructor Led Delivery

4.4.3.3 eLearning/CBT Training

4.4.4 Procurement Community Stakeholder Engagement

_Work_Statement_(PWS).docx

Page:

4/115

Version:

Version 1.0

4.4.5 Deployment

4.4.5.1 Deployment Strategy

4.4.5.2 Deployment Support

4.4.6 Cutover

4.4.7 Data Management

4.4.7.1 Data Migration

4.4.7.2 Data Conversion

4.4.7.3 Data Quality Assurance

4.4.7.4 Post Go-Live/Release

4.5 Transition to Sustainment

4.5.1 Interim Contractor Support (ICS)

4.5.2 Service Desk Operations, Escalation, and Metrics

4.5.2.1 Service Desk Option 1 Details

4.5.2.2 Service Desk Option 2 Details

4.5.3 Transition Management

4.5.3.1 User Management Transition Management

4.5.3.2 Service Desk Transition Management

4.5.3.3 Training Delivery Transition Management

4.5.4 HCA Transition Activities

4.5.4.1 HCA Business Operations

4.5.4.2 HCA Data Analysis

4.5.4.3 HCA Transition Operations

4.6 Sustainment

4.6.1 Logistics

4.6.1.1 Training

4.6.1.2 Service Desk Operations, Escalation, and Metrics

4.6.2 Engineering

4.6.2.1 Systems Engineering and Design Support (SEDS)

4.6.2.2 Systems Engineering Technical Review (SETR) Support

4.6.2.3 Software Engineering

4.6.2.4 Requirements Support

4.6.2.5 Enterprise Architecture (EA) Support

4.6.2.6 Interface Development and Support

4.6.2.7 Change Management Support

4.6.2.8 Configuration Management Support

4.6.2.9 Release Management Support

4.6.2.10 Test and Evaluation

4.6.2.11 Auditability

4.6.2.12 Cybersecurity

4.6.3 Application Management

_Work_Statement_(PWS).docx

Page:

5/115

Version:

Version 1.0

4.6.4 HCA Sustainment Activities

4.6.4.1 HCA Sustainment Operations

4.6.4.2 HCA Training

4.7 Program Management

4.7.1 Quality Management

4.7.2 Quality Control Plan (QCP)

4.7.3 Contractor Cost Data Reporting (CCDR)

4.7.3.1 Software Resources Data Reporting (SRDR)

4.7.3.2 Contract Work Breakdown Structure (CWBS)/CWBS Dictionary

4.7.3.3 Cost and Software Data Reporting (CSDR)

4.7.4 Earned Value Management System

4.7.4.1 Integrated Program Management Report (IPMR)

4.7.4.2 Integrated Baseline Review (IBR)

4.7.4.3 Integrated Subcontract Management

4.7.4.4 Schedule Risk Assessment (SRA)

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

4.7.5 Contract Funds Status Management Report (CFSR)

4.7.6 Risk Management

4.7.7 Training Management

4.7.8 Travel

4.7.8.1 Classroom Training

4.7.8.2 User Management

4.7.8.3 Deployment

4.7.8.4 Data Management

4.7.9 Failure Reporting, Analysis, and Corrective Action System (FRACAS) Data

4.7.10 Diminishing Manufacturing Sources and Material Shortages (DMSMS), and

Technology Refresh Planning 5 Security 6 Incidental and Government Furnished Property

Table of Figures Figure 1: ePS Users by Location

_Work_Statement_(PWS).docx

Page:

6/115

Version:

Version 1.0

Table of Tables Table 3-1: Applicable Regulations and Directives - General Documents Table 3-2: Applicable Regulations and Directives - DON Documents Table 3-3: Applicable Regulations and Directives - DoD, Federal, and International Standards 20 Table 4-1: IBR Entrance & Exit Criteria

Table of Appendixes Appendix 1: Critical User Counts by Location and Release Appendix 2: ePS Deployment Sequence

_Work_Statement_(PWS).docx

Page:

7/115

Version:

Version 1.0

1 INTRODUCTION

1.1 PMW 220 NAVEBS

Space and Naval Warfare Systems Command (SPAWAR), Program Executive Office for Enterprise Information Systems (PEO-EIS), Program Manager-Warfare (PMW) 220 Navy Enterprise Business Solutions (NAVEBS), located at the Washington Navy Yard, Washington, DC, is the program office responsible for overseeing the acquisition of the Navy Electronic Procurement System (ePS). PMW 220’s mission is to provide enterprise business and information technology (IT) leadership and governance that enable the programs and operations of the Department of the Navy (DON) to deliver their respective missions in an efficient, effective, and secure manner with IT solutions and services. It is the vision of PMW 220 to become the preferred organizational catalyst for change and world-class leader in delivering technology solutions and services that directly contribute to mission accomplishment for the US Navy – and as an essential partner in business transformation – provide excellence in customer service and secure infrastructures with cost efficient performance. More specifically, PMW 220 strives to accomplish the following strategic goals:

• Optimize information technology policy and applications

• Leverage management to increase performance, efficiency and alignment

• Achieve audit-readiness

• Optimize sustainment operations

PMW 220 will achieve their strategic goals with supporting technologies, established governance bodies for decision making and guidance, and IT best practices and standards for managing the entire portfolio.

1.2 The ePS Program

PEO-EIS, on behalf of Deputy Assistant Secretary of the Navy for Acquisition and Procurement (DASN AP), is seeking to provide the Department of Navy (DON) with a Commercial-off-the- Shelf (COTS) end-to-end (E2E) Electronic Procurement System (ePS), capable processing of contract requirements electronically from inception to closeout, while incorporating flexibility to interface with other electronic systems as necessary. The ePS is a modernization effort to replace the DON’s legacy Contract Writing Systems (CWS) and other ancillary procurement systems or portals, to include the Standard Procurement System (SPS) (i.e., the Navy substantiation of Procurement Desktop Defense (PD2)), Integrated Technical Item Management and Procurement (ITIMP), SeaPort-e, and PRISM systems. These procurement systems write and manage the majority of DON’s contracts under ten (10) Heads of Contracting Activity (HCAs). Consequently, ePS is targeted to consolidate the functional capabilities of multiple legacy systems into an integrated solution.

_Work_Statement_(PWS).docx

Page:

8/115

Version:

Version 1.0

The ePS is designated as a Department of Defense (DoD) Acquisition Category (ACAT) IAM Major Automated Information System (MAIS), Defense Business System (DBS). The ePS Program will provide the DON with standardized, E2E contract management (i.e., sourcing) of services, supplies, and construction. The ePS will also support mission-related assistance through assistance agreements such as grants. The ePS will deliver the following functional/technical capabilities:

• Provide robust functional capabilities to support the E2E Procure-to-Pay (P2P) process

• Capture data at the source (i.e., no redundant data entry via touch labor)

• Leverage a data-centric and DoD/DON standard-compliant design for data storage and exchanges

• Provide industry partners with a web-enabled interface to support procurement communications and actions

• Enforce business process controls and system controls to support a clean audit opinion

• Inform decision making through available, accurate, timely, and visible reporting and metrics

• Comply with DON-specific architecture, cybersecurity, and environmental constraints (e.g., Navy/Marine Corps Intranet (NMCI) and Outside Contiguous US (OCONUS) Navy Enterprise Network (ONE-NET))

• Deliver a flexible solution that allows changes to be made promptly and cost-effectively

• Support 100% of the DON contracting actions in a fully auditable and traceable environment

• Provide procurement actions in a Disconnected State

1.3 Background

1.3.1 DON Legacy Procurement Systems

As aforementioned, the ePS is a modernization effort to replace the DON's legacy CWSs and other ancillary systems or portals, including SPS, ITIMP, SeaPort-e, and PRISM. All of these systems interface with financial systems, such as Navy Enterprise Resource Planning (ERP), and/or reporting systems. These systems will allow the migration and interfacing of data from existing systems in the Procurement Data Standard (PDS)/Purchase Request Data Standard (PRDS) compliant format and content. PDS compliance is an on-going effort. Attachment 25 displays the historical annual PDS compliance statistics for the past five years. The following sections provide further information on these legacy systems.

_Work_Statement_(PWS).docx

Page:

9/115

Version:

Version 1.0

1.3.1.1 SPS

Currently, the DON uses SPS as its primary CWS for simplified acquisitions, Fleet Supply procurements, major weapon systems (MWS), ship construction, and related complex contracting. The DON performs buys with the SPS platform for the United States Marine Corps (USMC), the fleet at Naval Sea Systems Command (NAVSEA), Military Sealift Command (MSC), air wings at Naval Air Systems Command (NAVAIR), facilities at Naval Facilities Engineering Command (NAVFAC), operations and logistics at Naval Supply Systems Command (NAVSUP), for requirements of the Space and Naval Warfare Systems Command (SPAWAR), and Strategic Systems Programs (SSP). In a single year, the DON obligates approximately $70B with SPS, which represents approximately 80% of the DON’s Total Obligation Authority (TOA).

This workload placed on SPS by DON contracting, has pushed the system past its design limits.

The system received several enhancements, to include automating integration capabilities, improving product documentation, and a shift from client-server architecture towards web application architecture. However, delays in the contracting and acquisitions processes continually occur as the SPS struggles to process the DON’s ever-expanding complex contracting environment. As a result, SPS is inadequate to perform the required integrated DON contracting functions without further upgrades and intervention.

1.3.1.2 ITIMP

NAVSUP Weapon System Support (WSS), with sites in Mechanicsburg and Philadelphia, PA, is responsible for the life cycle support of naval aircraft, ships, submarines, weapon systems, and equipment. The WSS contracting mission includes, but is not limited to support for overhaul, repair, and procurement of systems, components, and spare parts. The Base Realignment and Closure (BRAC) process in 2006 realigned part of the contracting function to Defense Logistics Agency (DLA) detachments in Mechanicsburg and Philadelphia. Acquisition professionals from both NAVSUP WSS and DLA Detachments utilize the ITIMP system to execute those procurement actions. NAVSUP Business Systems Center (BSC) (the Central Design Authority) designed ITIMP in late 1980s/early 1990s to manage contracts for weapon system National Item Identification Numbers (NIINs). When SPS was fielded in 1996, it was incapable of large-scale batch processing jobs, and deployment ceased before this functionality was fully fielded. As a result, ITIMP remains mission-essential. Yet, as it is programmed in Common Business- Oriented Language (COBOL), it also has become increasingly costly and difficult to maintain and will therefore be replaced as part of ePS.

1.3.1.3 SeaPort-e

SeaPort-e is the Navy's premier electronic web based portal and the preferred method for competitively procuring and acquiring professional support services in 22 designated functional areas. SeaPort-e is used by NAVSEA, NAVAIR, NAVFAC, SPAWAR, USMC, ONR, and NAVSUP, as well as over 2,400 companies and growing (85% which are small businesses) who

_Work_Statement_(PWS).docx

Page:

10/115

Version:

Version 1.0 hold Multiple Award Contracts (MACs) within SeaPort-e. SeaPort-e is used to electronically issue Requests for Proposals (RFPs) and Invitation for Bids (IFBs), respond to Offeror/Bidder questions, receive proposals/bids electronically from vendors, conduct sealed bidding and source selection, award Task Orders (TO), and administer TO awards in a virtual environment. Without SeaPort-e online, processing and administration of Navy engineering and professional support services would revert to SPS, or manual/paper procedures which would double the workload, at a minimum.

The current interface allows for decreased cycle times and manual workload from the receipt of the Procurement Requests (PR) to the time of obligation, thus speeding the process for procuring the services necessary to support the Warfighter. It also ensures data integrity and consistency between the data in Navy ERP and the associated data in SeaPort-e. Without SeaPort-e online, this process would also be reverted to manual procedures, which would potentially result in loss of data integrity.

1.3.1.4 PRISM

PRISM-Procurement is a web-based 508 compliant COTS procurement writing system used by the Office of Naval Research (ONR) to meet all of the day-to-day acquisition needs of the program officers (e.g., requisitioners), procurement officers (i.e., 1102s), procurement systems, and procurement managers. This includes full lifecycle support for standard federal acquisition activities from advanced acquisition planning through requisition, solicitation, award, post-award management, reporting, and closeout.

ONR is responsible for awarding and administering contracts and other instruments for assigned DON Science and Technology (S&T) research. ONR’s unique contracting responsibilities include the award and administration of contracts to the Navy's Federally Funded Research Development Centers (FFRDCs). ONR holds approximately 106 full-license users for PRISM and uses Navy ERP as its financial system of record.

1.3.2 NDAA

The Fiscal Year (FY) 2013 National Defense Authorization Act (NDAA) Section 862 required the use of electronic contract writing systems approved in accordance with established uniform data standards, internal control requirements, independent verification and validation requirements, and business process rules for processing procurement requests, contracts, receipts, and invoices by the Department of Defense or other executive agencies. Consequently, the Under Secretary of Defense for Acquisition, Technology, and Logistics (USD (AT&L)) initially established a goal that no new contracts, agreements, or orders be awarded through SPS after September 30, 2015 and that use of SPS cease by September 30, 2017. On January 12, 2017, USD (AT&L) revised/extended the SPS sunset goal for which no new contracts, agreements, or orders be awarded through SPS after September 30, 2020, with SPS usage ceasing by September

_Work_Statement_(PWS).docx

Page:

11/115

Version:

Version 1.0

30, 2023. The memo further directed each service component to plan and budget for future contracting capabilities. Subsequently, the Navy Resources and Requirements Review Board (R3B) approved the ePS Problem Statement in May 2014.

1.3.3 Users, Stakeholders, and Other Background Information

Ultimately, ePS must provide E2E procurement capability to an estimated 5,500 critical users (e.g., Contracting Officers and Specialists) within the authority of the DON HCAs and subsequent Budget Submitting Offices (BSOs). These activities span approximately 445 locations around the globe (see Figure 1 below and Appendix 1). However, the processes of creating (writing), managing, and executing contracts within the DON is not limited to those with the authority to obligate funds on behalf of the Government. These processes are also supported by no less than 10,000 non-critical users (e.g., Managers, Approvers, Requestors, and Reporters), spanning complementary functional areas including Legal, Small Business Review, Requiring Activities, and Finance. In addition to these users, there are industry vendor users, which could exceed 100,000 based on number of industry partners, many requiring multiple accounts. Together, these groups are responsible for the successful execution of the DON’s contracting mission.

Figure 1: ePS Users by Location

_Work_Statement_(PWS).docx

Page:

12/115

Version:

Version 1.0

To support these user groups, the ePS solution must be procured, modified (to close functional gaps and integrate with DON financial systems), and delivered via a web-enabled application and instructor led training activity.

Once ePS is ready for use, it must be accessible to the users over the NMCI and other approved Navy networks, and accessible via authorized internet browsers (e.g., Internet Explorer) from authorized client machines. The ePS should have a, “zero client footprint,” which means that users will only need a DON-approved internet browser (no additional application will need to be certified to run on an NMCI client machine), nor will any non-standard Web plugins be required.

The industry portal component will be web-enabled, accessible from the internet from non- NMCI machines. The CWS will be Public Key Infrastructure Common Access Card (PKI-CAC) enabled while the industry portal will be CAC enabled for internal Navy users; for industry partners, CAC enabling will not be required. The ePS is envisioned to be composed of a COTS CWS, including an Industry Portal, an Enterprise Service Bus (ESB), and gap closure methodology. The intent of the ESB should be to provide an insulating interfacing capability for the CWS, for ease of integration and maintenance within the DON enterprise environment.

The functional proponent for ePS is the Deputy Assistant Secretary of the Navy (DASN) for Acquisition and Procurement (AP), but the system will be used across all Systems Commands (SYSCOMS) within the DON, to include Major Commands (MAJCOM) and subsequent BSOs that fall under the authority of the HCAs. Other primary organizational stakeholders include, but are not limited to, Assistant Secretary of the Navy (ASN) Financial Management and Comptroller (FM&C), Office of Financial Operations (FMO), Chief of Naval Operations (OPNAV) Logistics Programs and Corporate Operations (N41), United States Marine Corps (USMC) Programs and Resources (P&R), DASN Command, Control, Communications, Computers, Intelligence, Information Operations and Space (C4I, IO, & Space), and other industry partners.

The primary user organizations are within the ten (10) Heads of the Contracting Activity (HCA) commands and one (1) non-HCA command, as outlined below, which is shown in greater detail in Appendix 1 and Appendix 2 of this PWS.

1.3.3.1 Installations and Logistics, Headquarters, U.S. Marine Corps (HQMC, I&L)

HQMCL, I&L, is responsible for the award and administration of contracts for supplies and services to support installation and logistics requirements of the Marine Corps Operating Forces and supporting establishments.

_Work_Statement_(PWS).docx

Page:

13/115

Version:

Version 1.0

1.3.3.2 Marine Corps Systems Command (MARCORSYSCOM)

MARCORSYSCOM is responsible for awarding and administering contracts for assigned Marine Corps programs, assigned IT systems programs or components, and relevant professional, research and engineering services, except for naval aviation programs.

1.3.3.3 Military Sealift Command (MSC)

MSC is responsible for awarding and administering contracts for services of ocean-going ships, craft, floating dry docks, and other repair facilities, for purposes such as oceanographic research and survey, underwater research, cable laying, and range instrumentation; and contracts for the maintenance, conversion, and modernization of assigned vessels. MSC’s unique contracting responsibilities include contracts for services of ferries and tugs, but exclude contracts for: (i) pilot services, and (ii) ferries and tugs used for husbanding services, including water taxi contracts awarded outside the continental United States under husbanding services contracts.

The Defense Transportation Regulation identifies MSC transportation responsibilities.

1.3.3.4 Naval Air Systems Command (NAVAIR)

NAVAIR is responsible for awarding and administering contracts for naval aviation programs and efforts supported by the Naval Air Warfare Centers, to include relevant logistics, training and professional, research, and engineering services. In addition, NAVAIR unique contracting responsibilities include designing, developing, procuring, and supporting naval aviation systems used by the Navy and Marine Corps.

1.3.3.5 Naval Facilities Engineering Command (NAVFAC)

NAVFAC is responsible for awarding and administering contracts for all architect-engineer, construction, utilities, energy, facilities support, and assigned weapon and IT system programs or components associated with Navy expeditionary forces.

1.3.3.6 Naval Sea Systems Command (NAVSEA)

NAVSEA is responsible for awarding and administering contracts for ships and submarines, assigned weapon systems and platforms, and relevant professional, research, and engineering services. NAVSEA unique contracting responsibilities include awarding and administering contracts for construction, maintenance, and modernization of ships and submarines, nuclear propulsion, watercraft, submersibles, equipage for towing, diving and salvage, and University Affiliated Research Centers (UARCs).

1.3.3.7 Naval Supply Systems Command (NAVSUP)

NAVSUP is responsible for awarding and administering contracts in support of assigned logistics support functions. NAVSUP’s unique contracting responsibilities include procuring

_Work_Statement_(PWS).docx

Page:

14/115

Version:

Version 1.0 supplies and services for all non-contracting Navy activities, offices or commands for which no other HCA is delegated authority (e.g., US Navy Bureau of Medicine and Surgery) or delegating limited procurement authority to such activities.

1.3.3.8 Office of Naval Research (ONR)

ONR is responsible for awarding and administering contracts and other instruments for assigned DON Science and Technology (S&T) research. ONR unique contracting responsibilities include the award and administration of contracts to the Navy’s Federally Funded Research and Development Centers (FFRDCs) and other grants. ONR administers all DoD contracts and grants to universities and non-profits when delegated.

1.3.3.9 Space and Naval Warfare Systems Command (SPAWAR)

SPAWAR is responsible for awarding and administering contracts in the information dominance domain, including assigned programs in the areas of research and development, systems engineering and development, and other relevant professional services associated with production, installation and sustainment for Command, Control, Communications, Computers, Intelligence Surveillance, and Reconnaissance Systems (C4ISR); Joint Tactical Radios Systems (JTRS), Space Systems; Enterprise Information Systems (EIS); and Navy Chief Information Officer (CIO) supported information technology initiatives.

1.3.3.10 Strategic Systems Programs (SSP)

SSP is responsible for awarding and administering contracts in support of the development, production, and lifecycle support of the Navy’s Strategic Weapon Systems, and other assigned programs under the cognizance of the Director, SSP (DIRSSP).

1.3.3.11 Bureau of Medicine and Surgery (BUMED)

BUMED is responsible for providing, coordinating, and executing health care services acquisition and contracting activities. BUMED’s unique contracting responsibilities include coordinating the supply of medical and dental materiel management and logistic support to the Operating Forces and shore activities, and procuring and maintaining life cycle management of Expeditionary Medical Facilities. Although BUMED is not an HCA, it is a BSO with some delegated primary contracting responsibility.

_Work_Statement_(PWS).docx

Page:

15/115

Version:

Version 1.0

2 SCOPE

2.1 Acquisition of ePS

The ePS program intends to follow an Acquisition Model 3 Incrementally Deployed Software Intensive Program, a defense model structure described in the DoD Instruction (DoDI) 5000.02.

This contract will include all efforts necessary to accomplish the Full Deployment (FD) of ePS.

Full Deployment is intended to occur within one acquisition increment, which will consist of a Limited Deployment (LD) release with a subsequent Release 1 and Release 2. Release 1 will address functional requirements with moderate levels of configuration and additional functionality. Release 2 will introduce additional functionality to support remaining procurement requirements and automatic order writing functionality, such as found in NAVSUP’s ITIMP system. It should be noted that this model does not have a Milestone (MS) C. Acquisition Model 3 contains requirements and product definition analysis, risk reduction, development, testing, production, deployment, and sustainment phases punctuated by major investment decisions at logical programmatic and contractual decision points.

The DoD acquisition lifecycle management framework will be used to deliver the ePS capability.

The Program Management Office (PMO) has tailored and streamlined this framework to deliver the users the capability as fast as possible. The framework process provides for phases and multiple entry points consistent with a program's technical maturity, validated requirements, and funding.

2.2 Terms of Reference

The following sections will define terms to ensure consistency in context.

2.2.1.1 Out-of-the-Box (OOTB)

The released version of a COTS solution that includes those functions, capabilities, tasks forms, or other operations that are available to any authorized user upon initial hardware setup and software installation.

2.2.1.2 OOTB-Configuration

Configuration of a COTS solution includes any change within the defined set of COTS product parameters where a government user with proper permissions can set with no engineering services performed by the Contractor, and does not result in customization of the COTS product.

Software configuration typically:

• Enables or disables functionality that is readily available in the COTS product

_Work_Statement_(PWS).docx

Page:

16/115

Version:

Version 1.0

• Includes the steps/tasks in the initial setup of a large system (e.g., install parameters, data-element names, functional security model, user interface (UI) modification, settings, processes) available to government users with proper permissions

• Includes the use of available menus and/or wizards to set the parameters that determine the workflow

2.2.1.3 Future Enhancement to COTS

Enhancements are capabilities that result from changes to the core code of a COTS product in order to improve existing functionality that cannot otherwise occur through configuration.

Enhancements shall be included in future releases of the COTS product. Enhancements are anticipated to be system upgrades necessary to ensure continued alignment, improvement, and standardization of E2E contracting processes and maturation of infrastructure to handle the large transaction volume and data demands. This may include:

• Application version upgrades

• Automation of manual business process steps

• Automated access to additional data required for report completeness

• Major updates to meet changes in compliance requirements and infrastructure modernization to address additional users

• System scalability

• Technology refresh

• Prevailing industry standards

• Emerging technologies

2.2.1.4 Business Process Re-engineering (BPR)

A logical methodology for assessing process weaknesses, identifying gaps, and implementing opportunities to streamline and improve these processes to create a solid foundation for success in changes to the full spectrum of operations.

2.2.1.5 Extension

An extension is a software component that is installed or integrated with an existing COTS product in order to enhance its functionality. An extension provides additional functionality in the new solution without disturbing the core software code. It may include additional interfaces, automation of additional contract writing/administration processes, and new data fields.

_Work_Statement_(PWS).docx

Page:

17/115

Version:

Version 1.0

2.2.1.6 Plug-In

A plug-in is a software component that provides capability not provided by the core COTS solution, and which requires a secondary license or separately loaded application to execute the desired operation. This component will be installed or integrated with the existing COTS product(s) and should not require changes to the core code of the existing COTS product(s). It may include additional interfaces, automation of additional contract writing/administration processes, and new data fields. Once installed/integrated, the operations should seamlessly execute and be unnoticeable to the user.

2.2.1.7 Other Customization

Customization of a COTS solution includes software development work to change or extend the functionality of an existing COTS product, without resulting in changes to the core code of the COTS product. Customization is any software change intended to address specific DON requirements that is not configuration as defined above.

Software customization may be used to create reports, interfaces, conversion objects, extensions, forms, or other capability to satisfy requirements specific to the DON that could not otherwise be implemented by the configuration process. Customization of the COTS product requires a detailed understanding of the COTS implementation and data schemas in order to develop new or change existing functionality of the product.

Customization includes corrections/repairs to defects due to customization that do not involve changes to core code of the COTS product applications.

2.2.1.8 Modification (Software)

Modification of a COTS solution includes a change to a software component that is necessary to:

• Enhance the software capability that results from changes to the core code of a COTS product in order to improve existing functionality, or close functionality gaps that configuration or customization cannot otherwise accomplish. The COTS vendor should perform any modification of core code.

• Maintain the COTS product configuration and ensure stable operations for applications and data. Modifications will include, but are not limited to, preventive and perfective maintenance services; e.g., application of system patches and proactive performance tuning to ensure applications operate at peak efficiency as well as minor updates to meet changes in compliance requirements.

• Correct/repair defects to COTS product applications and/or infrastructure components in order to provide the required functionality to meet the service level requirements.

_Work_Statement_(PWS).docx

Page:

18/115

Version:

Version 1.0

2.2.1.9 Software Maintenance

Software Maintenance of a COTS solution includes a change to a software component that is necessary to:

• Update the COTS product to ensure stable operations for applications and data.

Maintenance will include, but may not be limited to, preventive and perfective maintenance services; e.g., application of system patches and proactive performance tuning to ensure applications operate at peak efficiency as well as minor updates to meet changes in compliance requirements.

• Correct/repair defects to COTS product applications and/or infrastructure components in order to provide the required functionality to meet the service level requirements. This may include application version upgrades.

2.2.1.10 Regulation/Data Updates

Regulation and data updates include updates from authoritative sources. For example: pushing data updates to the system that only involve updates to the data within the existing databases, and do not involve any programmatic changes to the software (e.g., North American Industry Classification System (NAICS) code updates, PSC code updates).

2.2.1.11 Configuration Item

A configuration item (CI) is any item that satisfies a system end use function and designates it for separate CM because the item meets or impacts one or more of the following:

• An item critical to the functioning of the system

• An item whose failure might result in loss of the primary system capability

• Is under Government control as designated by the Government

• Is critical or high risk and failure would have significant financial impact

3 APPLICABLE REGULATIONS AND DIRECTIVES

During performance of the contracted work, the Prime Contractor shall adhere to the following documentation and any revisions/updates thereof where approved for implementation.

Notification of revisions/updates in the documents shall be provided by the Prime Contractor to the PCO and COR. In the event that a revision or update is perceived to create price, schedule or technical changes to the contracted agreement, the Contracting Officer shall be notified of the impacts of the change in accordance with the Changes clause of the contract. Prime Contractor implementation of Changes shall follow PCO instruction.

_Work_Statement_(PWS).docx

Page:

19/115

Version:

Version 1.0

Tables 3-1, 302, and 3-3 outline the Applicable Regulations and Directives in regards to General Documents, DON Documents, and DoD, Federal, and International Standards:

Table 3-1: Applicable Regulations and Directives - General Documents

GENERAL APPLICABLE DOCUMENTS

1. DoD Cloud Computing Security Requirements Guide v1 r2, 18 March 2016

2. DoDI 5015.02, DoD Records Management Program, February 24, 2015

3. DoD Manual 5200.01, Volume 4, DoD Information Security Program: Controlled Unclassified Information (CUI), February 24, 2012

4. DoD CIO Memo July 3, 2007, Encryption of Sensitive Unclassified Data at Rest on Mobile Computing Devices and Removable Storage Media

5. DoD Information Enterprise Architecture v2.0, Appendix G, August 10, 2012

6. DoDI 5000.2, Operation of the Defense Acquisition System, January 7, 2015

7. DoDI 5000.64, Accountability and Management of DoD Equipment and Other Accountable Property, May 19, 2011

8. MIL-STD-881C, Department of Defense Standard: Work Breakdown Structures (WBS) For Defense Materiel Items, October 3, 2011

9. NIST SP 800-61, Computer Security Incident Handling Guide, Revision 2, August 2012

10. IEEE 1220-2005, Standard for Application and Management of the Systems Engineering Process

11. Privacy Act of 1974, Public Law 93-579, (5 U.S.C. 552a)

12. Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs, Jun 2015

13. DoD 5015.02-STD, Electronic Records Management Software Applications Design Criteria Standard, April 25, 2007

14. NARA Bulletin 2010-05, Guidance on Managing Records in Cloud Computing Environments, September 08, 2010

15.

M-05-24, Office of Management and Budget Memorandum of 5 August 2005, Subject:

Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a Common Identification Standard for Federal Employees and Contractors

Table 3-2: Applicable Regulations and Directives-DON Documents

DEPARTMENT OF THE NAVY APPLICABLE DOCUMENTS

1. DDCIO(N) memo 5000 Ser N2N6BC/7U120028, 1 Feb 2017

2.

DON Chief Information Officer (CIO) Message Date Time Group (DTG) 122213Z MAY 08, Public Key Infrastructure (PKI) Software Certificate Minimization Effort for DON Unclassified Environments

3. DON CIO Memo on the Acquisition and Use of Commercial Cloud Computing Services, 15 May

4. Systems Engineering Technical Review Organizational Standard Process Handbook: Version 2.0, December 15, 2015

5. Navy Cyber Forces Network Operations Command and Control Implementation Plan, version 1.4, July 2011

_Work_Statement_(PWS).docx

Page:

20/115

Version:

Version 1.0

DEPARTMENT OF THE NAVY APPLICABLE DOCUMENTS

6. OPNAVINST 3030.5B, Navy Continuity of Operations (COOP) Program and Policy, October 2009

7. OPNAVINST N9210.3, Safeguarding of Naval Nuclear Propulsion Information, June 7, 2010

8. SECNAVINST 3030.4C, Department of the Navy Continuity of Operation (COOP) Program, July 22, 2009

9. SECNAVINST 3052.2, Cyberspace Policy and Administration within the DON, March 6, 2009

10. SECNAVINST 5230.15, Information Management/Information Technology Policy for Fielding of Commercial off the Shelf (COTS) Software, April 2009

11. SPAWAR SETR Organizational Standard Process Handbook v2.0 Feb 2015

12. PMW 220 Risk, Issue, and Opportunity Management (RIOM) Plan (Current Version)

13. Information Assurance Technical Authority (IA TA) Cyber Situational Awareness STD CSA -014

14. Information Assurance Technical Authority (IA TA) CYBERSAFE Security Standards STD CSC v1.0

15.

Information Assurance Technical Authority (IA TA) Security Information and Event Management

STD SIEM-006R0

16.

Information Assurance Technical Authority (IA TA) Information Security and Continuous Monitoring

STD ISCM-005R0

17. Information Assurance Technical Authority (IA TA) Boundary Protection STD BP-009R0

18. Information Assurance Technical Authority (IA TA) Trusted System Network STD TSN-015

19. Information Assurance Technical Authority (IA TA) Account Management STD-AM-016 v1.0

20. Information Assurance Technical Authority (IA TA) Host Level Protection STDHLP-001 R1

21. Information Assurance Technical Authority (IA TA) Firewall Standard STD FW-002 R0

22. Information Assurance Technical Authority (IA TA) Defense-in-Depth Functional Implementation Architecture STD DFIA-004 v1.0

Table 3-3: Applicable Regulations and Directives - DoD, Federal, and International Standards

DEPARTMENT OF DEFENSE, FEDERAL AGENCY, AND INTERNATIONAL STANDARDS

APPLICABLE DOCUMENTS

1. DoD Cloud Computing Security Requirements Guide v1 r2, 18 March 2016

2. DOD CIO Cloud Computing Strategy, July 2012

3. DoD 5200.2-R, Personnel Security Program, March 21, 2014

4. Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6211.02D, Defense Information System Network (DISN)Responsibilities, January 24, 2012

5. CJCSI 6510.01F, Information Assurance and Support to Computer Network Defense (CND), February 9, 2011

6. Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs)

7. DoD 5220.22-M, National Industrial Security Program Operating Manual (NISPOM), February 28,

8. DoDI 8500.01, Cybersecurity Mar 14, 2014

_Work_Statement_(PWS).docx

Page:

21/115

Version:

Version 1.0

9. DoDI 8510.01, Risk Management Framework (RMF) for DoD for Information Technology (IT), Mar 12, 2014

10. DoDI 8520.02, Public Key Infrastructure (PKI) and Public Key (PK) Enabling, May 24, 2011

11. DoDI 8520.03, Identity Authentication for Information Systems, May 13, 2011

12. DoDI 8523.01, Communications Security (COMSEC), April 22, 2008

13. DoDI 8551.1, Ports, Protocols, and Services (PPSM), May 28, 2014

4 NAVY EPS SOLUTION CAPABILITY AND REQUIREMENTS

The ePS program has an objective to procure a COTS based CWS to support the DON’s E2E procurement process that meets the requirements in the System Requirements Specification (SRS) (Attachment 02), allows a complete solution, including an ESB, and includes systems integration, training, deployment, and sustainment.

Specifically, the Contractor shall:

a. Provide a DON E2E procurement solution capability, including all required engineering, system design, and development of a conforming COTS-based CWS with Business Intelligence (BI)/Analytics, industry portal and ESB in accordance with the SRS (Attachment 02), the required software (SW) licenses and maintenance, interface design and development, testing, deployment of the solution, training, and supporting documentation with minimal customization.

b. Test all ePS SW applications and associated patches, including compatibility with approved NMCI/ONE-Net web browser(s)

c. Provide a support team that possesses the level of technical and program management knowledge and expertise that demonstrates the ability to effectively and efficiently plan, execute, monitor, and report the activities required in this Performance Work Statement (PWS). This includes providing program management, status, and participating in required program reviews, as necessary, for the successful completion of this effort.

The Navy ePS solution capability and requirements are divided into five primary areas of concern:

• Product

• Integration

• Implementation

• Sustainment

• Program Management

_Work_Statement_(PWS).docx

Page:

22/115

Version:

Version 1.0

4.1 Product

The ePS Capability Requirements Document (CRD) (Attachment 03) describes the key capabilities that the ePS program must deliver, and are translated into requirements, as shown in the SRS (Attachment 02). The CRD contains System Performance Measures (SPMs) and other attributes, with objective and threshold values used to evaluate the overall operational effectiveness and suitability of the system during operational testing.

4.1.1 CWS COTS Software Licenses

The Contractor shall:

a. Deliver all licenses necessary, associated software maintenance, and integrate the SW functionality required to operate the COTS based CWS with an industry portal capability for the ePS Contiguous US (CONUS) and OCONUS environments

4.1.2 CWS COTS Software Support

The Contractor shall:

a. Achieve end-to-end (E2E) system performance measures and other system attributes in accordance with the CRD and SRS.

b. Deliver an ePS solution that is accessible via an authorized (NMCI-compliant) internet browser from a PKI-enabled machine on any approved DON network

c. Propose improvements to the ePS suite (CDRL C001 Status Report)

i. Assess the risk of these SW improvements to service delivery, operations, and training for the Government and other service providers and recommend mitigation strategies

d. Implement improvements to the provided ePS suite in order to meet the capability requirements of the SRS (Attachment 02), as approved by the Government

e. Advise the Government on the prioritization of patches/upgrades from the product vendor that contain remediation of potential risks and threats. Vendor software code must be scanned for weaknesses and vulnerabilities to ensure protection against emerging threats (CDRL A002 DoD Risk Management Framework)

f. Plan for and implement countermeasures in accordance with the ePS Program Protection Plan (PPP)

g. Plan, implement, and maintain a user-friendly and 508/504 compliant solution as outlined in Enclosure 7 of the DoDI 5000.02

h. Provide required information to register all new SW in the DON Application and Database Management System (DADMS)

_Work_Statement_(PWS).docx

Page:

23/115

Version:

Version 1.0

4.1.3 Enterprise Service Bus (ESB) COTS Middleware

The ESB is the middleware that performs the required transformations and interaction with delineated external components and interfaces as part of the E2E solution.

The Contractor shall:

a. Provide an ESB that enables ePS to communicate with external components. The Contractor may also partially or wholly integrate the existing NAVEBS SoftwareAG WebMethods ESB with its COTS based solution, if necessary. Information pertaining to NAVEBS usage of SoftwareAG WebMethods can be found in the ePS Technical Data Repository (TDR), located at https://acqu.noblis.org/AccessTDR.

b. Deliver all necessary licenses, associated software maintenance, and integrate the middleware functionality required to operate an ESB, and enable the external system interfaces, in accordance with the established End User License Agreement (EULA) of this contract

c. Perform the data mapping, design, and implementation of the required external systems interfaces in accordance with the data models in the Integrated Architecture Products.

d. Provide and implement a Middleware Execution Plan detailing options evaluated and long term support considerations and the technical approach (data formats, transformation, timing, and transport) (CDRL A003 System Engineering Master Plan

(SEMP)

i. Detail the ESB approach to utilize middleware in support of implementation, operation, and maintenance of delineated external systems in accordance with the data models in the Integrated Architecture (CDRL A004 Baseline Description Document)

ii. Update the documentation for the ESB Application Program Interface (API) available to translator map developers. This documentation shall include those features, which enable translator maps already developed to be integrated into the ePS ESB (CDRL A004 Baseline Description Document)

e. Maintain a list of recommended software tools for implementing the ePS ESB. Provide the software tool list for Government approval (may be included in CDRL C001 Status Report)

f. Provide SW Testing for the deployed middleware to support ePS integration with external systems (CDRL A005 Test Report)

g. Implement the middleware in accordance with the process controls defined in the Contractor’s System Engineering Master Plan (SEMP) https://acqu.noblis.org/AccessTDR

_Work_Statement_(PWS).docx

Page:

24/115

Version:

Version 1.0

4.1.4 License Management

The Government expects to acquire user licenses to the selected software solution with different levels of access to support the capability requirements, as outlined in the SRS (Attachment 02).

The ePS will be accessible from DON workstations, and other workstations compliant with approved DoD requirements. The industry portal should not require any licenses for industry users.

The Contractor shall:

a. Provide the Contractor’s strategy for the maintenance and management of licenses, regardless of their type, and implement the strategy for the development, deployment, and sustainment of the ePS program (CDRL A006 Software License Report)

i. Provide, and with Government approval, implement an approach to distribute, manage and maintain Software Licenses across the enterprise

ii. Develop a Phase-in schedule to manage and maintain license without disrupting end user services

iii. Provide all licenses and license maintenance including service management responsibilities to deliver functionality

b. Validate that the SW application(s) are appropriately licensed for distribution throughout the DON authorized community

c. Retain master copies of all licenses for purposes of regulatory compliance and administration

d. Verify deployment, changes, and removal to ensure that actual configurations match inventory, and license agreements

e. Recommend, and with Government approval, implement all required repurposing and transition of license types

f. Ensure all license related activities are incorporated in the Government approved master schedule

g. Notify the Government when Contractor intends to discontinue maintenance agreements for non-Government directed licenses supporting system functionality (CDRL A006 Software License Report)

h. Provide a report with information regarding the licenses, to include at a minimum, the number of licenses installed, the total number of licenses allocated, and the number actually being used to support accounting and reconciliation processes, as well as validating compliance with license agreements (CDRL A006 Software License Report).

i. Maintain report accountability of the linkage between individual license, including type, and appropriate measure of distribution (i.e., HW it is installed on)

_Work_Statement_(PWS).docx

Page:

25/115

Version:

Version 1.0

ii. Notify the Government when the license count of Government directed licenses allocated and/or installed reaches 90% of the license counts to facilitate timely reordering/replenishment of software licenses (CDRL A006 Software License Report)

iii. Provide license data for license reallocation

i. Maintain compatibility with DON network operating system and browser configuration changes of the commercial software

4.1.4.1 Technical Data Packages (TDP)

The Government will retain only the necessary technical data required to support sustainment and Title 10 related activities.