Attach 1 - Statement of Work - Basic Contract - Cyber TRIDENT.pdf

SOW-2020-011

STATEMENT OF WORK

for the

Cyber Training, Readiness, Integration, Delivery and Enterprise Technology (Cyber TRIDENT)

U.S. Army Program Executive Office for Simulation, Training, and Instrumentation (PEO STRI)

12211 Science Drive Orlando, FL 32826-3276

Revision Number Date Log of Changes Made and Description of

Reason Changes Approved By

Table of Contents

1. SCOPE

1.1 Introduction

1.2 Goals and Objectives

1.3 Method of Tasking

1.4 Background

2. APPLICABLE DOCUMENTS

2.1 Department of Defense Specifications

2.2 Availability of Department of Defense Specifications

2.3 Department of Defense Standards

2.4 Availability of Department of Defense Standards

2.5 Department of Defense Directives

2.6 Availability of Department of Defense Directives

2.7 Department of Defense Instructions

2.8 Availability of Department of Instructions

2.9 Other Government Documents, Drawings, and Publications

2.10 Availability of Other Government Documents and Publications

2.11 Non-Government Standards and Other Publications

2.12 Availability of Non-Government Standards and Other Publications

3. REQUIREMENTS

3.1 Program Management

3.1.1 Post Award Conference (PAC) and Kickoff

3.1.2 Contract Management

3.1.3 Subcontractor Management

3.1.4 Associate Contractor Agreements (ACAs)

3.1.5 Schedule (Release, Hardware)

3.1.6 Financial and Cost Management

3.1.6.1 Earned Value Management System (EVMS)

3.1.6.2 Contractor Integrated Performance Management

3.1.6.3 Integrated Baseline Reviews (IBR)

3.1.7 Risk Management

3.1.8 Program Management Reviews (PMRs)

3.1.9 Transition Plan (In and Out)

3.1.9.1 Transition In (Initial Operations)

3.1.9.2 Sensitive Compartmented Information Facility (SCIF)

3.1.9.3 Transition Out (Turnover)

3.1.10 Facilities

3.1.11 Material Acquisition - Computer Hardware, Enterprise Software Solutions

(CHESS) Program

3.1.12 Customer Support

3.2 Development Operations (DEVOPS) Process

3.2.1 Capability Development, Integration, Delivery and Sustainment

3.2.2 Integration Factory

3.2.3 Agile Ceremonies

3.2.4 Third Party Onboarding and Orchestration

3.2.5 Continuous Integration (CI)/Continuous Delivery (CD) Pipeline

3.2.5.1 Agile Systems Engineering

3.2.5.2 Requirements

3.2.5.3 Architecture

3.2.5.4 Design

3.2.5.5 Capability Development

3.2.5.6 Integration

3.2.5.7 Test

3.2.5.8 Configuration Management

3.2.5.9 Release Management

3.2.5.10 DEVOPS Feedback

3.2.6 Quality Assurance

3.2.7 Metrics

3.2.8 Enterprise Initiatives

3.3 Operations

3.3.1 Site Activation

3.3.2 Help and Technical Support Desk

3.3.3 Event and Exercise Support

3.3.4 Technical Operations Management (TOM)

3.3.5 Baseline Management

3.3.6 Production RCS Management

3.3.7 Liaison Officers (LNO)

3.4 Cybersecurity

3.4.1 Risk Management Framework (RMF)

3.4.2 Security Engineering

3.4.3 Army Training and Certification Tracking System (ATCTS) Training

3.4.4 Patch Management

3.4.5 Security Operations Center (SOC)

3.4.6 OPSEC Clauses/ COMSEC/ Declassification

3.4.7 Requirements for OPSEC Training

3.4.7.1 Anti-Terrorist Training (AT Level 1)

3.4.7.1.1 Area of Responsibility (AOR) Specific AT Awareness Training

3.4.7.2 Active Shooter Training

3.4.7.3 Access to Government Information Systems

3.4.7.4 Professional Training and Certification

3.4.7.5 Personal Identifiable Information (PII)

3.4.7.6 General Security

3.4.7.7 Security Clearances

3.4.7.8 Access and General Protection/Security Policy and Procedures

3.4.7.8.1 Common Access Card (CAC)

3.4.7.8.2 Accountability for Government-Provided Identification Credentials

3.4.7.8.3 Individuals Not Requiring CAC

3.4.7.9 Handling or Access to Classified Information

3.4.7.10 Effective Use of Controls

3.4.7.11 System Security Plan (SSP)

3.5 Training

3.5.1 Training Packages and Delivery

3.6 Logistics

3.6.1 Maintenance Support

3.6.2 Property Accountability and Management

3.6.3 Inventory Support

3.6.4 Supply Management

3.6.5 Licensing and Warranty Management

3.6.6 Supportability

3.6.7 Data Rights

3.6.8 Transportation and Transportability

3.6.9 Disposal

3.6.10 Obsolescence Management/Diminishing Manufacturing Sources and

Material Shortages (DMSMS)

3.6.11 Item Unique Identification (IUID)

3.7 Test

3.7.1 CI/CD Testing

3.7.2 Developmental Testing

3.7.3 Operational Testing

3.7.4 Defect Management and Resolution

3.8 Foreign Military Sales and Cooperative Agreements

4. ADDITIONAL CONTRACTOR REQUIREMENTS

4.1 Travel

4.2 The Enterprise-Wide Contractor Manpower Reporting Application

(eCMRA)

4.3 Contract Data Requirements List (CDRL)

Statement of Work

SOW-2020-011

Cyber Training, Readiness, Integration, Delivery and Enterprise Technology (Cyber

TRIDENT)

1. SCOPE

This Statement of Work (SOW) defines the scope of the Project Manager Cyber Test and Training (PM CT2) Product Manager Cyber Resiliency and Training (PdM CRT) Cyber Training, Readiness, Integration, Delivery and Enterprise Technology (Cyber TRIDENT). The Cyber TRIDENT may be utilized by Department of Defense (DoD) organizations and other non- DoD agencies that have related cyber training needs. These agencies include, but are not limited to, Army Program Executive Offices (PEOs) and Navy, Marine Corps, Air Force, National Guard, Reserves, Federal Agencies, and Joint Cyber Community organizations in support of DoD cyber training. The Cyber TRIDENT will provide the management, integration, maintenance, and evolution for the PCTE platform, and will provide total system/subsystem acquisition life cycle support for the PCTE system baseline.

This SOW defines the general tasks that PdM CRT desires to have performed under the Cyber TRIDENT contract in support of the PCTE platform. Individual Delivery Orders (DOs) will define the detailed requirements in each respective DO SOW. PM CT2 envisions management, maintenance, and evolution of the PCTE platform under Cyber TRIDENT to include but not be limited to:

• Platform Architecture and Product Management

• Agile Development and Delivery Systems Engineering processes

• Development & Automation

• Hardware and Software Infrastructure Management

• User Event Support (First Use Events, Operational Assessments, Cyber Flag Excursions)

• Cyber Innovation Challenge (CIC) Capability Integration and Event Support

• Development Operations (DevOps) Environment Management

• Third party technology insertion, orchestration and integration into PCTE platform

(Commercial Off-the-Shelf (COTS), Government Off-the-Shelf (GOTS), etc.)

• Distributed Configuration Management amongst various vendors and stakeholders

• Training as a Service (TaaS)/Cloud Computing Initiatives

• Product Development, Enhancements and Deployment

• Platform Governance

• Product Sustainment (synchronization with Joint Staff J7 Technical Operations

Management)

• PCTE Infrastructure Tool Management

• Testing Across the Product Release Cycles

• PCTE Current Vendor Collaboration

• License Management

• Help Desk Support

• Onsite and Remote Support

1.1 Introduction

The Cyber TRIDENT contract will satisfy PM CT2, PdM CRT requirement for a consolidated, streamlined approach for integrating, incrementally releasing and maintaining cyber training capabilities in support of Army PEOs and Navy, Marine Corps, Air Force, National Guard, Reserves and Joint Cyber Community organizations in support of DoD and non-DoD (State and Local Governments) cyber training. This enterprise approach protects and leverages the Army’s future investments in cyber training and related infrastructure. The contract will provide acquisition life-cycle optimization for PCTE as well as continue to evolve the platform, architectural frameworks, and the DevOps environment while continuing to provide PdM CRT an efficient, effective, and agile method to accomplish:

• Management, maintenance, and evolution of the PCTE products, processes, standards, and platform.

• Acquisition, Technology and Logistics Life-Cycle System Management in support of capabilities/products within PCTE.

• Identify repeatable Acquisition, Technology and Logistics Life-Cycle System Management optimization of systems/products that are developed within PCTE.

• Support of external interoperability initiatives and synchronization with Technical Operations Management (TOM) organization.

• Insertion and integration of emerging technologies from third parties into the PCTE platform baseline

1.2 Goals and Objectives

The objective of Cyber TRIDENT is to provide for the managed evolution of the PCTE Platform and to provide support across all facets of the Acquisition Life Cycle for PCTE. The goal of Cyber TRIDENT is to continue development operations with the integration of software and hardware enhancements from third party vendors as technology insertion occurs while conducting testing, providing periodic system updates, and fielding technology upgrades of PCTE to the Cyber Mission Forces (CMF) through an agile cadence. The vision is to leverage the existing PCTE baseline and investment in cyber training software and related infrastructure through Associate Contractor Agreements (ACAs) or subcontracts with current platform vendors. In addition, Cyber TRIDENT will provide limited operations and maintenance support for PCTE to ensure high system availability throughout the acquisition life cycle. Cyber TRIDENT must be dynamic and agile to support a highly complex joint program operating in a number of classifications at geographically disparate sites.

Cyber TRIDENT has the underlying need for standardization, synchronization and management to ensure and maximize reuse, commonality and availability. The support must include dynamic mechanisms for multiphase configuration management, development and support, integration and sustainment labs, and technology insertion and growth.

The Cyber TRIDENT contract should support the business goals of PCTE to include:

• Decreasing time to produce and present training scenarios

• Increasing training throughput

• Increasing quality of training

• Increasing the reuse of training scenarios/emulated environments.

1.3 Method of Tasking

Government requirements issued under the basic Indefinite Delivery Indefinite Quantity (IDIQ) Contract will be met through individual Delivery Orders (DOs) with a DO SOW containing the requirements for specific tasks relating to training system products. DOs may be issued at any time during contract performance, and will be related to scope task outlined in the basic SOW.

Additionally, the Government will include a set of data item requirements for the DO in the form of Contract Data Requirements List (CDRL) items.

1.4 Background

The United States faces threats from cyber warfare, and needs a realistic, persistent training platform that enables personnel to develop the required skills to execute mission. PM CT2 was tasked with developing a training platform to enable individual through force level training for the CMF and entire Department of Defense (DoD) Cyber Workforce. To maintain the operational readiness of a geographically dispersed CMF and entire DoD Cyber Workforce, the training platform must be persistently available around the clock (24/7). The purpose of PCTE is to enable the CMF to conduct joint training, exercises, mission rehearsals, experimentation, certification, re-certification, and assessments of cyber capabilities in support of the National Security Strategy (NSS).

For the CMF who need a realistic, high fidelity persistence training environment to conduct the spectrum of cyberspace operations, the Persistent Cyber Training Environment (PCTE) materiel solution provides a holistic, on-demand standardized training platform that enables the end-to-end planning, preparation, execution and assessment various cyber training events across individual, collective, and force level continuum. Unlike the current stove-piped, manpower and time intensive training environments, PCTE provides the CMF a standardized platform with ecosystem of capabilities to rapidly shape, execute, and reuse scenarios and multiple environments simultaneously, thereby increasing training quality and throughput. This supports the PdM CRT strategic vision to enable cyberspace dominance for the DoD CMF.

PCTE is a capability providing the DOD cyberspace workforce the ability to conduct cyberspace training (including exercises and mission rehearsals), experimentation, and certification, as well as the assessment and development of cyber capabilities and tactics, techniques, and procedures for missions that cross boundaries and networks. PCTE provides the capability required to train forces operating in cyberspace in accordance with congressional and DOD mandates.

The PCTE acquisition and integration strategy has been composed of procuring advanced prototypes that are able to efficiently integrate within the PCTE platform due to the fact that the capability is required quickly and the technology is readily available. The Program Office has integrated best of breed products and components from a number of vendors to create and establish a baseline PCTE platform. The Program Office is utilizing a SCRUM-like process to enable the rapid prototyping, and produce capability drops on a periodic basis (i.e., every six (6) months) while encouraging CMF feedback throughout the process. Once the required authorizations are granted, the capability drops will be deployed to the CMF’s at the seven (7) sites. The scrum-like approach will be utilized until the PCTE platform is fully operationally capable.

In an over-simplified analogy, PCTE is somewhat analogous to an individual and team/unit collective training event on a marksmanship range. Using this analogy, PCTE must build virtual firing positions, targets, obstacles, range towers, etc. It must also build the tools necessary to efficiently and effectively execute a range training exercise, such as command and control, boundaries, after action review, instructors, threat/opposing forces, other role players, etc. (called Event Management).

Unlike a physical marksmanship range, however, PCTE must also virtually build every aspect of the range to provide a realistic landscape like the dirt, bushes, wind, rain, buildings, personnel traffic, etc. (called Environment). It must also connect geographically displaced CMF personnel so that individuals/units can access and participate in training (called Connectivity). In short, PCTE is not a cyber range. It is every aspect of a training exercise that would take place on a range.

Ultimately, PCTE will be a cloud-based training platform to support CMF individual sustainment training, team certification, and provide the foundations for a collective training network (i.e., Cyber Flag, Cyber Guard). It will leverage existing architecture and capability, including current Service tools and be connected to the various cyber ranges, in order to provide the emulated environments for virtual cyber training. The materiel development activities for PCTE will include integrating hardware and software into a training platform that orchestrates event planning, training resources, and after-action review into a cohesive and networked training event.

The PCTE platform will utilize integrated virtual machines connecting to Service and Cyber Training and Test Ranges. It will be a part of the Cyber Range cloud-based environment allowing the ability to share resources, such as scenarios and content, and providing additional “maneuver space” such as emulated Red (adversarial), Blue (friendly), Gray (neutral), and Industrial Control System (ICS) environments.

PCTE will be located at a number of sites enabling cyber range transport capabilities and existing emulated network environments (maneuver areas). The installed sites include, but are not limited to:

1. Fort Gordon, GA

2. Ft. Meade, MD

3. Suffolk, VA

4. Joint Base San Antonio, TX

5. Oahu, HI

6. Vicksburg, MS

7. Orlando, FL (Development and Operations)

2. APPLICABLE DOCUMENTS

The following documents form a part of this SOW to the extent specified herein. In the event of a conflict between documents referenced herein and the contents of this SOW, the contents of the SOW shall be the governing requirements.

2.1 Department of Defense Specifications

2.2 Availability of Department of Defense Specifications

Copies are available on the WWW at URL: http://quicksearch.dla.mil/

2.3 Department of Defense Standards

MIL-STD-3046 (ARMY) Configuration Management, Interim Standard Practice

MIL-STD-130 Identification Marking of U.S. Military Property MIL-STD-31000 Technical Data Packages MIL-STD-40051 Page-Based Technical Manuals GEIA-STD-0007 Logistics Product Data

2.4 Availability of Department of Defense Standards

Copies are available on the WWW at URL: https://assist.dla.mil/online/start/

2.5 Department of Defense Directives

DODD 8570.01 Information Assurance (IA) Training, Certification, and Workforce Management DoDD 5000.01 The Defense Acquisition System, dated 20 November 2007

2.6 Availability of Department of Defense Directives

Copies are available on the WWW at URL: http://www.dtic.mil/whs/directives/

2.7 Department of Defense Instructions

DODI 5230.24 Distribution Statements On Technical Documents, 23 August

2012, Incorporating Change 2, 1 November 2017 DODI 8500.01 Cybersecurity, 14 March 2014 DoDI 8510.01 Risk Management Framework (RMF) for DoD Information

Technology (IT), 28 July 2017, Incorporated Change 2 DoDI 8582.01 Security of Unclassified DoD Information on Non-DoD

Information Systems, 6 June 2012 DoDI 5000.02

DoDI 5200.46

Operation of the Defense Acquisition System, Change 3 dated 10 Aug 2017 DoD Investigative and Adjudicative Guidance for Issuing the Common Access Card (CAC), 9 Sept 2014

DoDI 5000.74 Defense Acquisition of Services, Change 1, dated 5 October 2017.

2.8 Availability of Department of Instructions

Copies are available on the WWW at URL: http://www.dtic.mil/whs/directives/

2.9 Other Government Documents, Drawings, and Publications

DoD 8570.01-M Information Assurance Workforce Improvement Program, 19

December 2005, Incorporating Change 4, 10 November 2015 (http://www.esd.whs.mil/Portals/54/Documents/DD/issuances/do dm/857001m.pdf).

DoD 5220.22-M National Industrial Security Program Operating Manual, 28 February 2006, Incorporating Change 2, May 18, 2016 (http://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dod m/522022M.pdf).

FAR 52.204-2 Security Requirements, August 1996 (www.acquisition.gov/far/).

CNSS No. 11 Acquisition of Information Assurance (IA) and IA-Enabled Information Technology (IT) Products, 10 June 2013 (https://www.cnss.gov/CNSS/issuances/Policies.cfm).

CTO 07-12 Deployment of Host Based Security System (HBSS), 9 October 2007 (https://www.jtfgno.mil/).

MIL-HDBK-189C Reliability Growth Management, 14 June 2011 Notice 1 dated 18 Mar 2016.

(http://www.dote.osd.mil/docs/dote-temp-guidebook/MIL- HDBK-189C.pdf).

MIL-HDBK-61A Configuration Management Guidance, 7 February 2001 ( acc.dau.mil/adl/en-US/142238/file/27622/MIL-HDBK- 61A(SE)%20Configuration%20Management%20Guidance.pdf )

IEEE 12207-2008 International Standard ISO/IEC 12207 dated 2008-02-01- Systems and software engineering – Software Life Cycle Processes

National Security Telecommunications and Information Systems Security Policy (NSTISSP) No. 11, Subject: National Policy Governing the Acquisition of Information Assurance (IA) and IA-Enabled Information Technology (IT) Products.

AR 25-2 Information Assurance AR 25-2 BBP 08-CO-M-0001, Information Technology Contingency Plans and

Testing.

AR 602-2 Human Systems Integration in the System Acquisition Process.

AR 70-1 Army Acquisition Policy (Research, Development and Acquisition) dated

16 Jun 2017

AR 73-1 Test and Evaluation Policy, dated 1 Aug 2006 AR 380-5 Department of the Army Information Security Program AR 380-10 Foreign Disclosure and Contacts with Foreign Representatives AR 380-49 Industrial Security Program 20 March 2013

2.10 Availability of Other Government Documents and Publications Copies of the above documents are available at Army Contracting Command - ORlando, ATTN:

Rebeca Gonzalez, 12350 Research Parkway, Orlando, FL 32826-3276

2.11 Non-Government Standards and Other Publications

ANSI/EIA-748 Earned Value Management System

2.12 Availability of Non-Government Standards and Other Publications Copies are available on the WWW at URL: http://www.nssn.org/search.html

3. REQUIREMENTS

The contractor shall provide overarching support for the life cycle operations and products of the PCTE. The contractor shall deliver platform capabilities for integration, to include performing testing prior to fielding the platform. This will require such activities that include software development, system integration, test, system delivery, and upgrades to ensure compliance with contract requirements and timely delivery of required products. The contractor shall provide engineering, materials, equipment, testing, technical and operations support for the PCTE as described in this SOW.

3.1 Program Management

The contractor shall provide the overall management and administrative effort necessary to ensure that the requirements of this contract are accomplished. The contractor shall track program progress utilizing metrics specified by the Government. The contractor shall implement an agile process to address improved performance for time to award DOs. The contractor shall plan, implement, and maintain a Life Cycle Cost (LCC) management process to minimize the system cost and use LCC to conduct trade studies, evaluate design, support alternatives, and recommend resource support requirements. As directed by the individual DOs, the contractor shall provide support to participate in such activities as requirements reviews, agile ceremonies, design reviews, product demonstrations, Integrated Product Team (IPT) meetings, partnering, transition meetings, conferences, fieldings, post fielding assessments, and life cycle planning of current and future systems/software releases. In addition, the contractor shall establish Associate Contractor Agreement(s) (ACAs) as required.

3.1.1 Post Award Conference (PAC) and Kickoff

A PAC shall be conducted between the Government and the Contractor within thirty (30) days after contract award at the contractor’s site. The conference shall introduce key participants with emphasis on top level management of the program, identify points of contact within an organizational chart breakdown, discuss both parties’ understanding of the requirements to be performed, areas of responsibilities, identify any partnering approach, and other contract topics.

The Contractor shall provide the conference materials and minutes to the Government within five (5) business days after the PAC.

3.1.2 Contract Management

The Contractor shall plan, budget, schedule, and control resources allocated to meet requirements of the Delivery Order. In addition, the Contractor shall prepare, implement, and utilize the Contract Work Breakdown Structure (CWBS) to define the work required for the proposed effort. The Contractor shall identify elements of subcontracted work in the extended CWBS and may propose changes to the CWBS to enhance its effectiveness in satisfying program objectives.

3.1.3 Subcontractor Management

As required by the Delivery Order, the Contractor shall implement a subcontract management plan that ensures all Contract requirements are met. The Contractor shall maintain the capability to manage subcontractors in accordance with the Subcontractor Management Plan (SMP). The Contractor shall integrate all subcontractor schedules, accomplishments, metrics, risks, issues, problems, and deficiencies into the Contractor’s management control and reporting processes.

Additionally, subcontractors shall be included in program management and tracking systems such as management information systems.

3.1.4 Associate Contractor Agreements (ACAs)

To ensure the greatest degree of cooperation to meet Government requirements outlined in individual DOs, the Contractor shall implement ACAs with other program and third-party contractors as required for exchanging data, accessing and using third party software and equipment, receiving technical support, working interface and integration issues, and DoD Cyber user event planning and execution. The Contractor shall ensure that ACAs are maintained to achieve and maintain program interoperability and event planning and execution, as applicable.

ACAs shall provide for and permit the complete and unbiased exchange of technical information and data relating to program integration, development and deployment. Agreements shall be structured so that all Cyber TRIDENT and other program contractors are obligated to protect proprietary information from all unauthorized use or disclosure. ACAs shall be submitted to the PCO for review prior to execution.

3.1.5 Schedule (Release, Hardware)

As specified by individual DOs, the contractor shall develop a schedule tailored to the objective.

The contractor shall manage to and maintain the schedule it has developed for each specific order. As specified by the individual DO, the schedule shall be aligned to an Integrated Master Schedule (IMS) for tasks with a clear objective and end goal or shall be aligned to an Agile software development methodology with traceability to the software release schedule for software intensive DOs.

For DOs with an IMS, the contractor shall document the planned events and milestones, accomplishments, exit criteria, and activities from contract award to the completion of the contract. The IMS shall include a detailed account of all tasks necessary to accomplish the goals and objectives of the specific DO. The contractor shall demonstrate that IMS activities are synchronized across all other active DOs. In addition, the contractor shall conduct critical path analysis of the tasks and identify problem areas and corrective actions required to eliminate or reduce schedule impacts. The contractor shall quantify risks in hours, days, or weeks of delay and provide the most likely duration for each IMS activity and event.

For software intensive DOs, the contractor shall align the schedule to trace to the Agile ceremonies and Industry best practices such as sprint duration, release planning, and other appropriate Agile planning processes. The contractor shall ensure the Agile planning processes are able to support the DOs goals and objectives

3.1.6 Financial and Cost Management

As specified by the Delivery Order, the contractor shall plan, budget, schedule, and control resources allocated to meet requirements of the contract. The contractor shall maintain a detailed cost and schedule status of work progress on the contract and procedures for planning work, controlling costs, measuring performance, and generating timely and reliable information. The contractor shall document and track the expenditure of all appropriated funds associated with the contract against each contract line item and sub-line item. The contractor shall maintain integrated cost and schedule information on those subcontracts which, based on risk, schedule criticality or dollar value, have the potential to impede the successful completion of the contract.

The contractor shall document and track the status of all appropriated funds associated with the contract to include payments, cancellations and invoices against each contract line item and sub-line item.

3.1.6.1 Earned Value Management System (EVMS)

The contractor shall use EVMS as each specific DO defines.

3.1.6.2 Contractor Integrated Performance Management

As specified by individual DOs, the contractor shall establish, maintain, and use in the performance of each DO, an integrated performance management system. Central to this integrated system shall be a validated EVMS in accordance with the basic contract clauses and the EVMS guidelines contained in ANSI/EIA-748. To establish the integrated performance management system, the EVMS shall be linked to and supported by the contractor’s management processes and systems to include the IMS, contract work breakdown structure, change management, material management, procurement, cost estimating, and accounting. The correlation and integration of these systems and processes shall provide for early indication of cost and schedule problems, and their relation to technical achievement.

3.1.6.3 Integrated Baseline Reviews (IBR)

As specified by individual DOs, the contractor shall engage jointly with the Government’s program manager in IBRs to evaluate the risks inherent in the contract’s planned performance measurement baseline. The IBR shall occur as required by the individual DO, and subsequently following all major changes to any DO. Each IBR shall verify that the contractor is using a reliable performance measurement baseline, which includes the entire contract scope of work, is consistent with contract schedule requirements, and has adequate resources assigned. Each IBR shall also record any indications that effective EVM is not being used. IBRs shall also be conducted on subcontracts that meet or exceed the EVM application threshold. The prime contractor shall lead the subcontractor IBRs, with active participation by the Government.

3.1.7 Risk Management

As specified by individual DOs, the contractor shall implement an integrated risk management system with risk planning, identification, assessment, mitigation and monitoring functions to improve technical, cost and schedule performance. This will be documented in a Risk Management Plan (RMP).

The contractor shall utilize the risk management process for:

a) Identification and documentation of moderate and high-risk items for each risk assessment area [i.e. cost, technical, and schedule] to be presented at management reviews.

b) Identification and implementation of risk handling approaches and track over time each moderate and high-risk item.

c) Documentation of risk issues that have been successfully resolved and scheduling each open item into the program schedule.

d) Development of mitigation plans to identify the recommended critical path for contract completion and the appropriate risk handling approach to lower the level of uncertainty identified.

e) Recommendation of decision points in terms of cost, schedule, and performance objectives to facilitate management and technical control.

CDRL Number CDRL Name CDRL A001 Risk Management Plan (RMP), DI-MGMT-81808

3.1.8 Program Management Reviews (PMRs)

As specified by individual DOs, the Contractor shall host PMRs to inform the Government of program risks and issues. The reviews shall provide a forum for IPT members to clarify development, integration, installation, and management issues. The contractor shall provide conference agenda, presentation material, and meeting minutes, document action items, coordinate resolutions, and track action items until closure. The contractor shall provide all logistical requirements, to include but not limited to meeting rooms and projection capability.

The Contractor senior management shall brief their Government counterparts of program risks, status, and future support, and proactively participate in discussions to resolve issues. PMRs are considered complete when all action items are completed and deliverables are accepted by the Government.

3.1.9 Transition Plan (In and Out)

3.1.9.1 Transition In (Initial Operations)

When executed on a DO, the contractor shall implement and complete its Transition-In Plan, Attachment 13 of the contract. All transition-in activities listed in the plan checklist shall be completed within ninety (90) calendar days after DO award. The Cyber TRIDENT Transition-In Plan shall include but not be limited to the contractor’s plan to:

• A core meeting space that supports as least one hundred (100) participants for conducting Agile Ceremonies, traditional Government Ceremonies, and any other ceremonies/meetings required by the contractor’s Agile system engineering process.

• Facility to support PCTE CMF user events (First Use Events, Cyber Flag Excursions, etc.)

for up to 30 users

• At least five (5) break-out rooms that accommodate at least twenty (20) participants per room.

• Video and audio teleconferencing tools for remote participants in each space / room.

• Video projection system in each space / room.

• Internet and power access for attendees in each space / room.

• Audio system and microphones for projecting participants voice in each meeting space / room.

• Whiteboards and office supplies in each space/room to support Agile Ceremonies, traditional Government Ceremonies, and any other ceremonies/meetings required by the contractor’s Agile system engineering process.

• Assumption of GFE as per Government provided GFE list

• Transition (transport of GFP), setup, and implementation of Development RCS infrastructure

• Network connectivity to support Agile ceremonies, user events, and Development RCS

• Establish IPT structure across the PCTE program to include external stakeholders

• Business systems to support development environment

Inspection and acceptance of the transition activities shall consist of the contractor reaching full operational capability of the development environment and successfully completing all checklist activities of the transition plan.

3.1.9.2 Sensitive Compartmented Information Facility (SCIF)

When executed with a DO, the contractor shall provide a SCIF at the contractor’s location within 12 months of issuance of the order. The SCIF shall be fully operational and with all requirements to commence the Government accreditation process and sponsorship. During the Government accreditation process, the contractor shall provide all necessary support in order to obtain accreditation, to include remediation of any adverse findings during the accreditation process.

At a minimum, the SCIF shall:

• Have ability to enable remote access to the RCS fleet (up to Top Secret),

• Have capability to conduct test activities,

• Be able to perform unclassified and classified content authoring and development to support a team of up to 20 workstations.

• Provide the necessary physical space, power, cooling, and network connectivity for a

SCIF that can handle up to Top Secret/SCI clearance level access located no more than ten (10) miles from PEO STRI at 12211 Science Dr, Orlando, FL 32826.

Inspection and acceptance of the SCIF requirements shall consist of the contractor providing a fully operational SCIF ready for Government accreditation activities, to include completion of all required documentation in accordance with Intelligence Community Directive (ICD) 705 and successfully completing all checklist activities of the transition plan.

3.1.9.3 Transition Out (Turnover)

As required by the individual DO, the Contractor shall provide for an unimpeded transition for the turnover/assumption of work. The Contractor shall coordinate with the Contracting Officer’s Representative (COR) to identify existing challenges, unresolved actions, and/or property accountability pertaining to a transition out plan.

The Transition-Out Plan shall include: a written comprehensive plan explaining actions required to complete the total transition effort within a sixty (60) calendar day transition period; details of accounts, software licenses and subscription services to be terminated or transferred; a process to conduct a full joint inventory and transference of all Government Furnished Property (GFP) inventory; status of all ongoing and upcoming agile ceremony and user events and plans for transition; details for the removal of all incumbent contractor owned items; and a schedule for risk mitigation during the transition period.

3.1.10 Facilities

As specified by individual DOs, the contractor shall establish and enforce security procedures in accordance with (IAW) security classification of products and services and the Contracts Security Classification Specifications, DD Form 254 and addendum sheets according to the National Industrial Security Program Operating Manual (NISPOM) requirements.

3.1.11 Material Acquisition - Computer Hardware, Enterprise Software Solutions (CHESS) Program

The contractor shall comply with the Army’s Computer Hardware, Enterprise Software Solutions (CHESS) program as defined within and across DOs/Task Orders (TOs). Under PEO EIS, CHESS is the mandatory source for commercial Information Technology (IT) purchases.

CHESS contracts provide IT products and services that comply with U. S. Army Network Enterprise Technology Command (NETCOM), Army and DoD policy and standards. Purchasers of commercial hardware and software must satisfy IT requirements by utilizing CHESS contracts and DoD Enterprise Software Initiative agreements first, regardless of dollar value. Any purchase made outside of CHESS contracts requires a waiver. A complete list of CHESS contracts and the on-line waiver process can be found at https://chess.army.mil.

3.1.12 Customer Support

The contractor shall support customer interface management activities to assist the Government with planning, support, and implementation of future customer requirements. The Government will address the specific requirements in each DO.

The following table provides a representative list of tasks and activities that could be required by specific delivery orders with respect to customer support:

Trade Studies Training Subject Matter Expertise Help Desk Integrated Development Environment Software Engineering Environment Tool Support Publishing Technical Library Agile Development and Support Environment

(design, development, support, operations, maintenance)

Network Operations and Maintenance Prototyping Integration Testing Quality Assurance System Transition Planning Cyber Content Development and Procurement

Cyber Training System Development

Cyber Architecture Support Cyber Operations and Planning Enterprise Infrastructure Development Hardware and Software Procurement Cyber Training Event Operations Cyber Tool Development Cloud Computing Initiatives System Automation

3.2 Development Operations (DEVOPS) Process

3.2.1 Capability Development, Integration, Delivery and Sustainment As specified by the individual DOs, the contractor shall perform the necessary tasks and activities for product development integration, prototype production, testing, installation, and sustainment. The Government will address the specific requirements in each DO.

The following table provides a representative list of tasks and activities that could be required by specific delivery order(s) with respect to Product Development, Integration, Fielding and Sustainment:

Concept Development Functional Analysis

Requirements Analysis System Engineering Software Engineering System Design Prototyping Software Integration System Integration Testing & Test Engineering Installation Training Verification Testing Validation Testing Post-Deployment Software Support

(PDSS)

Post-Production Software Support (PPSS)

System Demonstration RMF Testing and Certification Configuration Management Security Engineering Trade Studies Quality Engineering

The contractor shall provide a Systems Engineering Management Plan that is expanded to include a holistic DevOps process for developing, integrating, testing, fielding, and sustaining products.

CDRL Number CDRL Name CDRL B001 Systems Engineering Management Plan (SEMP), DI-SESS-81785

3.2.2 Integration Factory

As specified by the individual DOs, the contractor shall leverage the remotely accessible Integration Factory environment to plan, build, integrate, test and deploy contributions across multiple contractors and the Government in support of CI/CD. The contractor shall leverage the Integration Factory to manage and monitor multiple contractors’ software contributions to reduce cost and risk as each component is integrated within the environment. The Integration Factory will be comprised of modules/environments to include but not limited to the following:

Onboarding Environment (Initial Training) Tool Repository Development Environment Staging Environment Testing Environment Production Environment Quality Assurance Environment Vendor Environments (Sandbox within

Development)

3.2.3 Agile Ceremonies

As specified by the individual DOs, the contractor shall execute the necessary Agile ceremonies to conduct the planning for the development, testing, integration, operations, and sustainment of the capability. The contractor shall establish a collaborative environment to execute the Agile ceremonies. The Government will address the specific requirements in each DO.

The following table provides a representative list of Agile ceremonies that could be required by specific delivery orders:

Capability Envisioning Release Planning Capability Increment Planning Daily Planning Capability Increment Demonstration Retrospective

3.2.4 Third Party Onboarding and Orchestration

As specified by the individual DOs, the contractor shall host and participate in third party contractors’ interaction and handover meetings; including working with other industry partners and users of the system to identify, develop and integrate capabilities that support cross-developer interactions, and service-specific uses of system. In addition, the contractor shall monitor the system capabilities that are developed/integrated by third party contractors, and keep the Government informed on the progress of such efforts. These capabilities shall become part of the formally managed software baseline.

3.2.5 Continuous Integration (CI)/Continuous Delivery (CD) Pipeline As specified by the individual DOs, the contractor shall implement CI pipelines that automate the staged build, test, integration and release of capabilities. The contactor shall implement CI pipelines with the required stages to automate functional and nonfunctional gates to progress capabilities across but not limited to Development, Test, Quality Assurance, Security, and Scalability. In addition, the contractor shall implement CI pipelines that promote capabilities between stages via human in the loop or when automated testing passes.

As specified by the individual DOs, the contractor shall implement CD pipelines that rapidly and safely test capabilities in a production-like environment and deploy the capabilities to production. The contractor shall implement CD pipelines that build upon the CI pipelines. In addition, the contractor shall implement stages in the pipelines that allow the capabilities to go through automated testing in a production-like environment and allow the organization to make the decision on whether to deploy the capabilities to production when the capabilities pass automated testing.

3.2.5.1 Agile Systems Engineering

As specified by the individual DOs, the contractor shall apply Agile methodologies based on industry best practices. In addition, the contractor shall plan, schedule, and lead all agile ceremonies, including sprint planning, daily sprint standups, sprint retrospectives and sprint demonstrations.

As specified by individual DOs, the contractor shall provide the requisite technical and programmatic support to complete the required tasks of the individual DOs associated with engineering and management. These tasks shall encompass the efforts associated with the development, dissemination, engineering, management, and maintenance of the architecture, system components, and documentation. In addition, these tasks shall also include the work efforts associated with the engineering, management, and tracking of fielded products, services and architecture platform.

3.2.5.2 Requirements

As specified by individual DOs, the contractor shall deliver software in accordance with the requirements in the contractor's software development process plan. The requirements defined herein form the basis for all efforts outlined in the DOs issued under this contract for the design, development, integration, production, testing and fielding of major and minor iterations of the system. The contract shall deliver systems, including ancillary support services, which support the enterprise management. All analysis and results shall be documented in an integrated database.

3.2.5.3 Architecture

As specified by individual DOs, the contractor shall develop system requirements and architecture in accordance with the contractor’s Agile system engineering process. When developing the architecture, the contractor shall consider the entire lifecycle of the system including development, maintenance, and deployment. All analysis and results shall be documented in an integrated database. As part of this activity, the contractor shall work within the IPT to iterate on the system architecture. The contractor is encouraged to suggest revisions to Government requirements where such revisions would result in cost or schedule reduction or performance improvements. The contractor shall define and record the operational concept for the system, architectural design of the system (identifying the components of the system, their interfaces, and a concept of execution among them), and the traceability between the system components and system requirements. The contractor shall evaluate the cybersecurity requirements to assess any impacts on developed capability and provide potential solutions, if applicable. In addition, the contractor shall determine if existing open source products are capable of meeting any operational capabilities, perform a detailed product reuse evaluation, and document the results of the analysis. The contractor shall conduct architecture working groups with participation from stakeholders external to the contractor’s organization.

3.2.5.4 Design

As specified by individual DOs, the contractor shall design capability to meet system requirements throughout the entire lifecycle of the system. The contractor shall design the capability to be highly cohesive, loosely coupled, and have severable components that can be competed separately and acquired from independent contractors. Design includes not only design to requirements, but selection of existing products, including open source, to meet system requirements and iterating the requirements to allow use of existing products throughout the life of each delivery order. Products that perform IA functions are considered cybersecurity or cybersecurity-enabled IT products and shall be selected from the DOD Unified Capabilities Approved Product List and configured in accordance with DOD-approved security configuration guidelines. These include databases which must comply with the DISA database Security Technical Implementation Guide (STIG). The contractor shall document the capability designs including but not limited to components of the system, their interfaces, and a concept of execution among them. The contractor shall work within the IPT to iterate on capability designs.

3.2.5.5 Capability Development

As specified by individual DOs, the contractor shall develop the system software and firmware following the contractor's organizational software development practices. The contractor shall follow formal industry-accepted software development practices that are consistent with at least Level 3 of the Capability Maturity Model Integration for Development (CMMI-DEV). In addition, the contractor shall conduct market surveillance and market investigations, in order to maximize the use of open source software, commercial software and non-developmental software.

3.2.5.6 Integration

As specified by individual DOs, the Contractor shall support the acceptance, modification, integration, and test of future capabilities in order to deliver a comprehensive system. The contractor shall establish an integration environment that provides an online, interactive, and collaborative environment, which is protected with access control.

3.2.5.7 Test

As specified by individual DOs, the contractor shall support testing across the agile software development lifecycle. The contractor shall test, stage, and release products by applying iterative processes utilizing the proposed Agile methodology within the delivery order specified release cycle.

3.2.5.8 Configuration Management

As specified by individual DOs, the Contractor shall manage the technical and administrative direction and surveillance actions used to identify and document the functional and physical characteristics of a Configuration Item (CI), to control changes to a CI and its characteristics, and to record and report change processing and implementation status IAW the Contractor's Configuration Management Plan (CMP). The CMP and tools shall provide bi-directional configuration management auditing rigor within the DevOps process from vendor "black box" delivery to authoritative component builds to final product "releases." The contractor shall establish a secure environment in which configuration managed products, builds and other artifacts are backed up locally and remotely.

3.2.5.9 Release Management

As specified by individual DOs, the contractor shall manage the release management process by planning, coordinating, and verifying the deployment of release into production. The contractor shall collaborate with each contractor and the Government by holding release management reviews. The contractor shall ensure each contribution meets the criteria governing the overall release effort.

3.2.5.10 DEVOPS Feedback

As specified by individual DOs, the contractor shall use the DEVOPS feedback loop as a key enabler in the delivery process to ensure customer feedback is used to focus on changes and improvements to the environment. In addition, the contractor shall use the feedback to amplify and shorten changes/improvements to each component in the environment and to inform data-driven decisions.

3.2.6 Quality Assurance

As specified by individual DOs, the contractor shall implement the quality program that meets the requirements of contractor-developed Quality Program Plan (QPP), which will be approved by the Government. It is the contractor's requirement to ensure appropriate quality control measures are implemented under the contract for each individual delivery order.

3.2.7 Metrics

As specified by individual DOs, the contractor shall capture and report operational effectiveness and suitability, usability, Agile Development, technical performance (e.g., performance scaling, pub-sub, serialization, and API conformance), programmatic,…