PWS.pdf

CUI

Page 1 of 71 Pages

PERFORMANCE WORK STATEMENT (PWS)

Award/Mod Effective Version Date Award To Be Determined (TBD)

Contract Number: TBD Task Order Number: TBD Contractor Name TBD Tracking Number: 632469573 Follow-on to Previous Contract and Task Order Number:

Electromagnetic Spectrum Situational Awareness (EMS SA):

W52P1J18DA045, HC104720F0010

1 Contracting Officer’s Representative (COR).

a. Primary COR. See Defense Information Technology Contracting Organization (DITCO) Additional Text G1 - Points of Contact

b. Alternate COR. See DITCO Additional Text G1 - Points of Contact

c. Property Administrator (PA). See DITCO Additional Text G1 - Points of Contact

2 Contract or Task Order Title.

Global Electromagnetic Spectrum Information System (GEMSIS) Sustainment and Enhancement

3 Background.

The Defense Information Systems Agency (DISA) Program Executive Office (PEO) Spectrum must sustain the Joint Spectrum Data Repository (JSDR) and Integrated Spectrum Desktop (ISD), and the End-to-End Supportability System (E2ESS) along with other various Department of Defense (DoD) software requirements. This requirement will support the training, operations, maintenance, test, and enhancements of the current server, client, and software/system architecture, to include maintaining the systems usability, data administration activities, security posture, system administration and documentation, development of administrative interfaces, automation of data ingest, ingest of additional data sources, and additional User Interface (UI) customization.

JSDR/ISD is a National Security System (NSS) used by DoD to provide spectrum related data to support strategic and tactical electromagnetic spectrum operations. The system provides a suite of tools for accessing, viewing and analyzing DoD and related data needed for planning and conducting operations. (The current JSDR/ISD system is referred to as JSDR within this PWS.)

JSDR is a web application currently operating on Non-Secure Internet Protocol Router Network (NIPRNet) and Secure Internet Protocol Router Network (SIPRNet) using a common codebase. JSDR will also be deployed on Joint Worldwide Intelligence Communication System (JWICS). JSDR contains the following modules: Standard structured Queries, a Universal Query, Business Intelligence and Analytics, Content Management Information System, Satellite Line-of-Sight Heat Map analysis, 2-D and 4-D mapping interfaces, engineering services based on terrain based propagation modeling, and a terrain server. JSDR is an integration of multiple Commercial-off-the- Shelf (COTS) products as well as custom JavaScript UI components. JSDR currently interfaces with: the Spectrum XXI System (also in the DISA STRATUS cloud) for synchronization of frequency assignment data; the Weapons and Space Portal system for passing user queries and accepting returned data; Electromagnetic Battle Management – Joint (EMBM-J) (located in the Amazon Web Services (AWS) Gov Cloud) and, National Geospatial Agency (NGA) for obtaining map layers. JSDR currently has a Representational State Transfer (REST) Application Programming Interface (API) that can provide data to external systems in Standard Frequency Action Format (SFAF) and JavaScript Object Notation (JSON) formats.

E2ESS has been modernized and integrated into the JSDR architecture. As a web-based integrated tool, E2ESS has been built for use by the DoD combining the following capabilities in order to support all the functions related to Spectrum Certification and Host Nation Coordination (HNC)

Page 2 of 71 Pages

• Editor: for creating and maintaining Spectrum Certification records

• Integrated Web Services: for cloud-based data exchange with the National Telecommunications and

Information Administration (NTIA)

• Integrated Content Management System (Alfresco): for tracking the status of Spectrum Certification records as they move through the business process workflow, creating and tracking spectrum supportability requests for host nation coordination, and managing all the data content withing the E2ESS application.

4 Objectives:

This contract will primarily support the sustainment, training, operation, and enhancement of the GEMSIS capabilities by leveraging the existing JSDR, an operational enterprise capability within the DISA PEO SPECTRUM GEMSIS Program of Record. JSDR has capabilities that have been assessed to meet DoD operational requirements which will need to be sustained and expanded to further meet the operational spectrum needs of the DoD. This contract will support the extension of the current JSDR software architecture, data store, and feature set to support the integration of additional data sets and analytics for enhanced situational awareness to further meet DoD requirements where enhanced situational awareness includes the ability for users to configure their own operational picture. This contracting effort also includes for accelerating the development of blue system data, improving the data development processes, and enhancing the Joint Equipment Tactical and Space (JETS) database and data presentation features, additional data sources, and support the maintenance of additional data records for the JETS database which feeds the JSDR for the planning and execution of joint electromagnetic spectrum operations and the coordination of electronic warfare and spectrum management activities to support the DoD electromagnetic operating environment.

The JSDR and E2ESS objectives of this contract are to:

• Maintain JSDR capabilities to query and download data sets, to store and retrieve documents, and to perform analytics on data sources, while working with the customer base to address Change Requests (CRs).

• Collect and maintain extensive data on spectrum dependent equipment and spectrum usage to support tactical, training, or sustaining-base operations, operational assessments, and research and development efforts; and populating the unstructured repository with documentation of interest for the spectrum community.

• Extend the situational awareness capabilities of the current JSDR following software development and management best practices to ensure PWS requirements are met within cost and schedule.

• Integrate additional data and provide user access, filtering options, analytical tools to characterize and gain situation awareness of the data within JSDR.

• Provide configurable, layered, filterable, User Defined Operational Picture (UDOP) for display and analysis of JSDR data using engineering services.

• Enhance JSDR and E2ESS usability and streamline sustainment, to include the implementation of agile Development Security Operations (DevSecOps) pipeline to support Non-Secure Internet Protocol Routing (NIPR), Secure Internet Protocol Routing (SIPR) and Joint Worldwide Intelligence Communications System (JWICS) networks.

• Provide operations and sustainment of the E2ESS software that supports the business process for spectrum-dependent system (SDS) certification and host nation coordination requests in support of the Services and Combatant Commands.

• Support technical exchange meetings (TEMs) between E2ESS subject matter experts (SMEs) and the NTIA in support of evolutionary data exchange enhancements between E2ESS and Equipment Location- Certification Information Database (EL-CID) online.

• Provide management and engineering support for leveraging the GEMSIS architecture and products to address PEO SPECTRUM and external customer spectrum analytics in parallel with GEMSIS technical requirements.

Page 3 of 71 Pages

5 Scope.

This PWS provides for the operations, training, maintenance, sustainment, and enhancement of JSDR and E2ESS for the DoD and NTIA. The contractor shall provide all personnel, equipment, tools, materials, vehicles, supervision, and other items necessary to perform the tasks specified in this PWS.

This PWS also provides for PEO SPECTRUM and external customers leveraging the JSDR architecture to perform DoD spectrum analytics, national and international strategic planning, and answer rapid data calls. The contractor shall provide personnel, tools, and other items necessary to perform these optional tasks without impacting the performance of the PWS primary tasks. Additional extensions to the GEMSIS software base include the Joint Spectrum Interference Reporting Online (JSIRO) tool (Task 13), the Stepstone Query capability (Task 14), the JSDR Strategic Planning and Analysis Dashboard Extensions (JSPADE) (Task 16), the World Radio Conference (WRC) Strategic Planning Tool (SPT) (Task 17), and the JETS database editor (Task 19).

Wherever possible, integration with other Government-off-the-Shelf (GOTS) and DoD capabilities will be accomplished instead of developing custom software.

Primary Tasks:

Task 1 – Project Management

Task 2 – Engineering Support and Outreach

Task 3 – Software Maintenance and Enhancement

Task 4 – System Administration, Operations and Sustainment Support

Task 5 – Helpdesk Support

Task 6 – Training Support

Additional/Optional Tasks:

Task 7 – JSDR Frequency Assignment and Table of Allocations (TOAs) (Optional)

Task 8 – Provide Spectrum Supportability Operations (Optional)

Task 9 – Maintain JSDR Operational Data (Optional)

Task 10 – Provide JETS Data Maintenance (Optional)

Task 11 – Accelerated Blue Force Data Development (Optional)

Task 12 – Customer Support (Optional)

Task 13 – Modifications to JSIRO (Optional)

Task 14 – Extensions to Support Specialized User Requests (Optional)

Task 15 – JSDR Support of Engagements and Demonstrations (Optional)

Task 16 – JSDR Strategic Planning and Analysis Dashboard Extensions (Optional)

Task 17 – Operational Dashboard Development (Optional)

Task 18 – Artificial Intelligence/Machine Learning Framework (Optional)

Task 19 – Editor for JETS Record Production (Optional)

Task 20 – JSDR System and Database Administration Support - JWICS (Optional)

These requirements may in the future expand, change, or be revised due to upgrades to systems as a result of technology evolution, industry standard changes and DoD regulatory requirements.

The Government may require surge support during the base or any option period, and surge modifications will be within the scope of the contract and provide increased support for the defined task areas of this PWS. Surge support over the life of the contract will not exceed 50% of the contractor’s total proposed cost/price for the base and all option periods, excluding any six-month extension of services pursuant to Federal Acquisition Regulation (FAR) 52.217-8.

Page 4 of 71 Pages

6 Performance Requirements.

The JSDR system is composed of the following four Computer Science Configuration Items (CSCIs).

• Access Control CSCI

• Data Service CSCI

• Analytics CSCI

• UI/UX CSCI

Each CSCI is described in Appendix 1 - Computer Science Configuration Items, to aid in understanding the JSDR architecture and system documentation. Reference diagrams are included in Appendix 2 – System Architecture Diagrams. The ISD serves as the landing page for the GEMSIS enclave and provides users links to a variety of spectrum resources as well as spectrum and news related widgets. The goal for JSDR is to provide universal, standardized, layer-based display and manipulation of data containing a frequency component. The data may originate in disparate data sources; however, the goal for JSDR is to provide one common place where that data can be visualized and analyzed regardless of the user’s role within the spectrum community.

CSCIs shall comply with in place endpoint APIs within the JSDR. Any proposed modifications to the current architectures shall be identified within the first 60 business days to include COTS change out, additional servers or server capacity, etc.

The contractor shall ensure that the JSDR framework allows integration of additional engineering services and propagation loss models and associated algorithm in the future with minimal level of effort. The current JSDR API utilizes an open interface using web services over standard ports. JSDR extensions should also maximize utilization of web services over standard ports to the degree possible for data exchange. The current JSDR provides engineering services to support coverage analysis (i.e., calculation and map overlays of signal strength), point-to-point link analysis, and satellite line-of-sight analysis considering terrain or earth curvature blockage. The contractor shall maximize speed for JSDR engineering services. The contractor shall enable engineering analytics to be able to predict areas and times for congestion/interference, predict and deconflict Joint Restricted Frequency List (JRFL) conflicts, and assess impact of hostile jamming with minimal operator input required. The contractor shall implement, deliver and deploy software changes into the Government Master Repository (GMR) using agile software development life cycle (SDLC) best practices.

The contractor shall provide a Technical Data Package (TDP) or TDP Updates with each software release based on Appendix 3 – TDP Reference Documentation.

TDP Reference Documentation

Engineering and design-related information for JSDR are provided in a reference library as part of this PWS to support the bidding process. Reference documents are provided in the form of Technical Data Package (TDP) that include documents such as System and Sub-System Design Description, Interface Design Description (IDD), Interface Control Document (ICD), and User/Administrative Help manuals. There are four TDPs for JSDR, one for each CSCI listed in this section and in Appendix 3 – TDP Reference Documentation.

TDP Documentation Updates

The contractor will update the content of TDP documentation as necessary during the execution of the contract to reflect changes in software and system design, training or administrative updates, or changes related to COTS and GOTS. TDP documentation that may require updating are those included as part of the reference documentation in Appendix 1 and Appendix 3 – TDP Reference Documentation.

Changes to the architecture may impact documents in multiple TDP. Software updates may also affect more than one TDP document. The Government expects all relevant changes to be made as necessary to keep documentation current with the operational JSDR systems.

Source Code

Updated source code for bug fixes, enhancements, or other approved requirement shall be formally delivered prior to deployment for functional and security testing and accreditation. Under no circumstance shall source code developed under this PWS contain, rely on, or otherwise use proprietary information without prior written Government approval regardless of the category of proprietary information. Existing JSDR and E2ESS source code will be provided after contract award.

Page 5 of 71 Pages

TDP shall include:

• An Installation Package (IP) that includes all executables, installers, scripts and/or data needed for a full install and full uninstall. The installs shall be fully automated and include a “silent install” option (i.e., an option that does not require user interaction).

• Installation Guide which will identify all of the settings, steps for manual installation.

• A Source Code Package (SCP) that contains all source code, schemas, scripts, libraries, data and instructions needed to rebuild the executables and install package

• A Software Requirements Specification (SRS) that meets DI-IPSC-81433A requirements

• An IDD and ICD that addresses all machine-to-machine interfaces (e.g., file imports, exports, web service interfaces)

• System Design Documentation (SDD) - This group of documents includes a System Design Description conforming to Data Item Description (DID) DI-IPSC-81435A, and any other "contractor defined format" documents needed to describe the design and comply with security requirements.

• A Requirements Traceability Matrix (RTM) that maps the requirements in the High-Level Requirements document, to the requirements in the SRS, to the software component(s), and to the test cases.

• Risk Management Framework (RMF) documentation and traceability with Security Controls Traceability Matrix (SCTM), Security Technical Implementation Guide (STIG) checklists, source code review, data type data flow diagrams, network and database access analysis, and all phases of information assurance.

• A Test Plan, Test Description following DI-IPSC-81439A, Test Cases, Scripts, Data, and all software and data required for the Government to independently execute the automated and manual test cases, and a Test Report documenting the results of the contractor testing

• A Software Installation Plan (SIP), Installation guide, Software Version Description (SVD), and PEO Spectrum Form 19

• Maps and data needed

• Other data and documentation (e.g., Information Assurance (IA) documentation).

• Code Reviews Results

• Software Vulnerability Assessment Report

Additionally, user-training materials are to be delivered and updated with each release. The work performed under this contract shall meet GEMSIS Key Performance Parameter (KPP) requirements. The GEMSIS shall work with all browsers available to DoD as configured with applicable STIGs.

All TDP artifacts shall be delivered in editable file formats. If a locked version of the file is required, an editable unlocked version shall also be provided.

6.1 Task 1 – Project Management (Research, Development, Test, and Evaluation (RDT&E) and Operations and Maintenance (O&M), Firm Fixed Price (FFP)).

The contractor shall provide the management, personnel, planning, and coordination support necessary to accomplish all work requirements contained in this PWS. Project managers and technical staff are required to formally manage, track, and report project activities with respect to schedule, cost, risk, and key milestones in accordance with established PEO SPECTRUM business processes and direction from the Government. The contractor’s management effort shall include administration, program controls, product effectiveness, data and configuration management, risk and issue management, subcontract management, and security management. The contractor shall insure that all staff members comply with mandatory contractor training requirements.

The contractor shall ensure all activities under all tasks in this PWS are proposed, planned and executed in a realistic, technically sound, and low risk manner that makes an efficient use of resources. Moderate or high risk items, if any, must be identified and accompanied by risk mitigation plans to reach low risk status.

Page 6 of 71 Pages

The contractor shall identify and utilize software development-related best practices for all software activities under all tasks in this PWS. This includes requirements definition and analysis, software design and design documentation, code development, maximum use of automated testing, documentation and inspection, user interface development and inspection, testing (verification and validation (V&V)), configuration management, interface definition and controls, risk management, quality management, scheduling, and all planning. The contractor shall ensure their software development-related processes and procedures used for any tasks in this PWS are documented, and the processes include continuous process improvement.

The contractor shall develop software under this contract using an agile-like development methodology modified to comply with the GEMSIS Systems Engineering Plan and PWS requirements. Sprint planning will be conducted under Task 2 Engineering Support and Outreach, and sprint execution will be conducted under Task 3 GEMSIS Software Development. The contractor shall prepare a SRS and a Preliminary Design Review (PDR) (deliverables for Task 2) for each major sprint for approval by the GEMSIS Program Manager and the COR.

The contractor shall supply all subject matter expertise required to accomplish all tasks in this PWS, including data science, spectrum operations, spectrum engineering, operational support, electronic warfare, intelligence data, Joint Electromagnetic Spectrum Operations (JEMSO), E2ESS, EMS, JSDR expertise blue force SDS equipment and parametric data expertise, information assurance expertise, information technology (IT) expertise, system, web and database administration expertise.

The contractor shall comply with the GEMSIS Configuration Management Plan, and use configuration management and change management systems to ensure product version control is in place. As new capability is demonstrated, tested and fielded, the user community is able to make change requests through the GEMSIS Configuration Management process, including the Baseline Control Board (BCB). Stakeholders contribute suggestions for software and data changes to GEMSIS. The GEMSIS Configuration Control Board (CCB) and JSDR Project Control Board (PCB) evaluate and prioritize requirements, and the GEMSIS Program Management Office (PMO) defines the software release contents based largely on the CCB and PCB input. The contractor shall maintain CRs and product version records.

The contractor shall conduct both functional and physical configuration audits on the development and production environments and provide audit results to the Government. Configuration management of TDPs shall occur in the approved DoD enterprise collaboration/interoperability and IT project management services, and on delivered Digital Video Disks (DVDs). A TDP is not considered delivered until it is loaded into Confluence and Git repository and DVD media is provided to the COR.

6.1.1 Subtask 1 - Contract Management Reviews (CMRs). JSDR and E2ESS CMRs will be conducted monthly and cover all aspects of quality, resource utilization, and funding/invoicing. The contractor shall track and provide a presentation on all efforts/activities performed across all tasks. The review presentation shall address financial status (planned vs. actual), staffing levels, task costs, sprint costs, variances, organizational structure, work breakdown structure, schedule, risk, and quality issues for the contract. CMR presentation materials will be provided to the COR five business days prior to the CMR. The contractor shall make COR requested changes to the CMR presentation format and content within ten business days. The contractor shall document all issues and risks in the CMR that could cause problems with the software development lifecycle, sustainment, operational support, or operational availability of the JSDR and E2ESS web applications. Issues and risks identification will include probability, consequence, and mitigation approach information. The contractor is responsible for identifying that all personnel, to include any new personnel on the contract, have executed the DISA-provided Non-Disclosure Agreement (NDA). The contractor shall report on status of staff completion of mandatory training.

6.1.2 Subtask 2 - Interim Progress Reviews (IPRs). The Government will conduct bi-weekly IPRs throughout the Period of Performance (PoP). The contractor shall prepare agendas and presentation materials for the JSDR and E2ESS IPRs summarizing ongoing activities, accomplishments, deliverable status, and issues. The contractor shall prepare meeting minutes based on the content of the actual meetings to include a synopsis of discussion and action items and list of participants. These minutes and actions shall be reviewed and statuses presented at the next IPR.

6.1.3 Subtask 3 - Integrated Master Schedule (IMS). The contractor shall develop and maintain an integrated master schedule using Microsoft Project to track and monitor task activities. The IMS will include logically networked program activities and dependencies. The schedule shall contain the planned events and milestones, accomplishments, exit criteria, and activities from contract award to the completion of the contract. The IMS shall clearly link all subsystems and related activities for deployments to support GEMSIS operations and sustainment

Page 7 of 71 Pages planning. The contractor shall quantify risk in hours, days, or weeks of delay and provide most likely duration for each IMS activity and event. The contractor shall work with the GEMSIS Operations and Sustainment staff as well as the JSDR sustainment contractor to deconflict deployment tasks and maintenance releases for JSDR and E2ESS, and other deployment activities.

6.1.4 Subtask 4 - Technology Report. The contractor shall provide an informal report identifying all technologies embedded in the system and used by the contractor for the development, testing and operations of the JSDR and E2ESS systems. The report shall contain the following for each technology: Source, Purpose, Version utilized, Software License, End of Support Information (i.e., Dates, Options and Costs for extended support), and Proposed Approach for addressing technology obsolescence with related Non-Developmental Item (NDI) cost information.

The contractor shall notify the Government in writing and receive approval before adding any new technology into the JSDR and E2ESS baseline (i.e., any new technology required for development, testing or operations).

6.1.5 Subtask 5 - Technical Exchange Meetings (TEMs). The contractor shall support approximately 12 Government site visits to the contractor facility per year for Government review of:

a. Management Processes

b. Development processes

c. Test activities

d. Configuration control of software and TDP products

e. Monitoring and disposition of defect/problem reports

The contractor shall provide demonstrations of JSDR as requested by the Government for a variety of audiences including technical staff as well as senior leadership and shall support technical interchange meetings, and customer engagements at either the contractor site, PEO SPECTRUM, DISA Headquarters (HQ), Pentagon, or locations requiring travel. (See Task 2). The contractor shall document meeting minutes, outcomes and action items. The contractor shall support the Government as required supplying updated information/materials/slides for presentation to external parties and senior leadership.

Additional scope in 6.3.2 Subtask 2 (Software Enhancement) will be managed separately from JSDR and E2ESS implementation to the greatest possible extent.

6.1.6 Subtask 6 - Phase-In (RDT&E, O&M, FFP). The contractor shall support a Phase-In period during which transition between the contractor and the predecessor contractor is necessary to assure minimum disruption to vital services and Government activities. During this period, the incumbent contractor will continue to be fully responsible for the continuation of services. The Phase-In period is projected to be approximately 30 business days. The Phase- In period encompasses the people, processes, tools, technologies, and sequenced activities required to maintain system operation, sustainment and development activities. The contractor shall provide a transition Phase-In Transition Plan to the Government 14 business days after task start, detailing contractor tasks, task dependencies, and milestones during the transition period. The transition shall be handled with minimal disruption to the Government.

6.1.7 Subtask 7 - Phase-Out (RDT&E, O&M, FFP). The contractor shall support a Phase-Out period during which transition between the contractor and the successor Contractor is necessary to assure minimum disruption to vital services and Government activities. During the transition period, the incumbent will be fully responsible for the continuation of services as detailed in the PWS.

The contractor shall submit a “Phase-Out Transition Plan” to ensure the services required under this contract are continued without interruption and maintained at the required level of proficiency.

The contractor shall facilitate the transition of all tasks performed under this contract to the successor (Government and/or contractor) who will continue the support services, including operational knowledge (i.e., on-the-job training).

The transition will encompass the processes, procedures, documentation, and tools currently utilized under this contract.

The Phase-Out Transition Plan to the Government will detail contractor tasks, task dependencies, and milestones during the transition period. The Phase-Out Transition Plan will also include the list and location of contract records to include historical information that may assist the successor contract in a smooth transition, and an inventory of all Government Furnished Property (GFP). The transition shall be handled with minimal disruption to the Government.

Page 8 of 71 Pages

During the contract transition, the incumbent contractor shall coordinate with and provide training to the follow-on contractor, and support the contract transition as directed by the COR.

Deliverables:

PWS

Task#

Deliverable Title Format Due Date Distribution/Copi es

Frequency and Remarks

6.1 PCB

Presentations

Government- Approved Format (GAF)

Last business day of each month..

Draft due 10 business days before the PCB meeting.

COR Monthly.

6.1 Functional and

Physical Configuration Audits

Government Specified/Suppli ed Format (GSF)

Once per PoP for scheduled software releases. Agreed-upon schedule for unscheduled (i.e., emergency) releases

Standard Distribution*

Once per contract year

6.1.1 CMRs Contractor-

Determined and

GAF

Within 10 business days of each subsequent month for the preceding month

COR Monthly

6.1.2 IPRs Contractor-

Determined and

GAF

First due 30 business days after contract award date; Biweekly thereafter.

COR Biweekly after the first deliverable

6.1.3 IMS Microsoft Project Last business day

of each month

COR Monthly

6.1.4 Technology

Report

Contractor- Determined and

GAF

40th business day of every two months

COR No deliverable due first two months from the contract award date.

Deliverable due Bi-monthly (40th business day) thereafter.

6.1.5 Customer

Engagement and Demonstration

Contractor- Determined and

GAF

Due date is dependent upon IMS schedule and as customers engagements occur

COR Approximately four per contract year on quarterly basis

6.1.5 Meeting

Materials

Contractor- Determined and

GAF

One week before the corresponding meeting.

COR As meetings occur.

Approximately six per contract year on bi-monthly basis.

6.1.6 Phase-In

Transition Plan

Contractor- Determined and

GAF

First draft due on the 14th business day after task starts

COR First draft due 14th business day after task

Page 9 of 71 Pages starts. Final version due between 14th and the 22nd business day of task

6.1.7 Phase-Out

Transition Plan

Contractor- Determined and

GAF

Four months prior to end of the PoP

COR First draft due three months prior to end of the PoP. Final version due four months prior to end of the PoP.

* Standard Distribution: One copy of the transmittal letter with the deliverable to the Primary COR. Deliverable and transmittal letter stored with GEMSIS Configuration Management (CM) according to the GEMSIS Configuration Management Plan.

6.2 Task 2 – Engineering Support and Outreach (O&M, FFP).

6.2.1 Subtask 1 – Sprint Planning

The contractor shall collaborate with the GEMSIS PMO and external stakeholders to perform requirements analysis and develop sprint plans that meet JSDR requirements. This includes collaborative software development and support. Sprint plan execution may include collaboratively developing software and TDP materials with other projects, programs and contractors.

Sprint Plans. The contractor shall develop Sprint Plans that implement the JSDR requirements. The contractor shall plan and track sprint releases in the IMS.

• The contractor shall conduct sprint planning and deliver sprint plans per the COR approved IMS delivery schedule.

• Each sprint plan shall include an updated SRS for each sprint. These documents shall identify which requirements are to be satisfied by the current sprint and identify requirements satisfied by previous sprints.

The SRS shall conform to DID DI-IPSC-81433A.

• The sprint plans shall identify requirements implemented and requirements remaining to be implemented.

• The sprint planning shall include requirements analysis for each sprint, and the results shall be documented in the SRSs. The contractor shall ensure the SRS requirements are clear, complete, verifiable (i.e., testable), and unambiguous.

• This task includes requirements analysis and coordination to analyze, refine and validate the CSCI requirements. This effort requires coordination with the current JSDR sustainment contractor.

• The contractor shall identify impacts to the following in all sprint plans: System Architecture, Software, Hardware, Licensing/Cost, Security / IA, System Performance, Interfaces, Interoperability and Backwards Compatibility, Data, Data Migration, Reliability, Availability, and Maintainability (RAM), Training, Training Materials, Software Documentation, System Administration documentation, Help Desk documentation, Business Process, Installation, and Deployment process on all target platforms and networks.

• The contractor shall ensure COTS or GOTS used in the system meets system and IA requirements.

• The contractor shall set up periodic meetings with the Government to coordinate sprint planning and review sprint progress.

The contractor’s established Sprint Plans must be approved by the Government.

Page 10 of 71 Pages

The contractor shall develop software under this contract using an agile-like development methodology modified to comply with the GEMSIS PWS requirements. Sprint planning will be conducted under Task 2 Engineering Support and Outreach, and sprint execution will be conducted under Task 3 Software Maintenance and Enhancement. The contractor shall prepare a SRS and a PDR for each sprint for approval by the GEMSIS Systems Engineer and the COR. The contractor shall provide materials for these and other formal meetings at least one-week before the corresponding meeting. The contractor shall obtain written approval from the COR before adding any software development, software testing or system operations technologies to the JSDR technology baseline.

CRs to be included in sprints will be determined and prioritized through the GEMSIS PCBs and CCBs. The GEMSIS CCB (approximately bi-annual) and PCB (monthly) evaluate and prioritize requirements, and the GEMSIS PMO defines the release contents based largely on the CCB and PCB inputs.

CRs to be included in sprints will be determined and prioritized Sprint Prioritization working groups. The User Representative will provide prioritized requirements. The GEMSIS PMO defines the release contents based largely on the prioritized requirements and Sprint Prioritization working group inputs.

6.2.2 Subtask 2 – Data Analysis

The contractor shall evaluate Government designated data sources and work with Government SMEs to develop and document a data integration strategy and capability to automatically ingest data from originating sources, and/or query and display data from federated data sources. The contractor shall evaluate data formats and compatibility with existing data requirements and standards and establish the methodology to integrate. The contractor shall leverage or develop an interface as well as a process to extract the data from identified external data sources, transform it as needed to map to JSDR, and enable access to it from the JSDR environment, maximizing automation.

The contractor shall create CRs to integrate these changes to the baseline. The contractor shall implement processes that minimize and simplify efforts in administration and maintenance of the ingest function. The system will provide audit access for data connections and/or downloads. The contractor shall configure the system to log data access, including user identification, date and time of access, and the query being performed. The contractor shall develop ICDs for external interfaces, to be delivered with TDPs.

The contractor shall develop a strategy for evaluating and managing data content within the JSDR. This strategy will contain recommendations for data review, data retention, and data governance policies. This will include such assessments as leveraging metadata as necessary to maintain traceability of the data (searchable, source, etc.) as well as potential rule sets for determining best sources of data when disparate sources conflict. The contractor shall document this strategy in a Content Management Data Strategy.

6.2.3 Subtask 3 – Outreach/Demonstration

The contractor shall participate in TEMs with interfacing data provider organizations, service EMS programs, external systems and stakeholders, as required to support JSDR. TEMs will be required approximately one per month, which may require travel, and occur with other Government programs and organizations including (but not limited to): Electronic Warfare Planning and Management Tool (EWPMT), Spectrum Services Framework (SSF), Fusion Analysis Development Effort (FADE) – Multiple Intelligence Spatial Temporal (MIST) (FADE-MIST), Global Combat Support System – Joint (GCSS-J), Integrated Broadcast Service (IBS), E-SPACE, Real Time Spectrum Operations (RTSO), System Planning Engineering and Evaluation Device (SPEED), Global Command and Control System – Joint (GCCS-J), Strategic Knowledge Integration Web (SKIWeb), Joint SATCOM (Satellite Communications) Management and Planning System (JSMPS), Joint Integrated SATCOM Tool (JIST), etc. The contractor shall support quarterly Electromagnetic Spectrum Data Community of Interest (ESDCoI) working group meetings at DISA Headquarters at Ft. Meade, or at Joint Spectrum Center (JSC). The contractor shall provide demonstrations of the JSDR as requested by the Government. The contractor shall document meeting minutes, outcomes and action items. The contractor shall support the Government as required supplying updated information/materials/slides for presentation to external parties and senior leadership.

For scoping purposes, include SME travel to:

Dayton, Ohio (once per year)

San Antonio, Texas (four times per year)

Aberdeen, Maryland (twice per year)

Quantico, Virginia (once per year)

Page 11 of 71 Pages

Dahlgren, Virginia (once per year)

Charlottesville, Virginia (once per year)

Colorado Springs, Colorado (once per year)

Stuttgart, Germany (once per year)

Tampa, Florida (once per year)

Honolulu, Hawaii (once per year)

Omaha, Nebraska (once per year)

6.2.4 Subtask 4 – Architectural Products

The contractor shall develop the following architectural products (and revisions to reflect changes to the system) to depict the JSDR system to include:

• Operational View (OV)-1

• OV-2

• OV-3

OV-6c

• Systems View (SV)-1

• SV-2

• SV-3

• SV-4

• SV-6

• StdV-1

The contractor shall also answer requests for information from other projects working on spectrum related architecture products, such as the PEO Spectrum project for Electromagnetic Spectrum Enterprise Architecture and PEO Spectrum funded efforts by other contractors to develop supporting architectural products.

6.2.5 Subtask 5 – Technical Assessments/Recommendations

The contractor shall make recommendations with respect to enhancing performance, increasing reliability, and extending infrastructure to meet future user demands and increased data processing requirements. The contractor shall provide engineering support to GEMSIS program and make recommendations for enabling interface and/or data exchange mechanisms with external applications and across GEMSIS capabilities. The contractor shall develop recommendations and specifications for cross domain solutions, if required. The contractor shall participate in technical working group meetings and Integrated Product Teams to gather necessary technical data.

The contractor shall evaluate engineering services that could be integrated into the JSDR. The contractor shall recommend industry best practices and design patterns for the GEMSIS program, including recommendations for User Interface/User Experience (UI/UX) standardization, data exchange techniques, and for efficient methods of integrating and/or interoperating with other GEMSIS capabilities, as well as external data sources and systems. The contractor shall also evaluate and test possible alternative hosting or development/test environments (e.g., Amazon Government Services, etc.) and software integration environments (e.g., Joint Test and Interoperability Center Labs (JTIC)). This task will include participating in GEMSIS systems engineering and deployment, operations and sustainment meetings. The contractor will provide recommendations in white papers.

The contractor shall also provide technology reports identifying any new technologies that are proposed to be integrated in the system and used by the contractor for the development, testing and operations of the JSDR system.

The report shall contain the following for each technology: Benefit/Risk, IA impact and risk, Source, Purpose, Version, Software License, End of Support Information, and Proposed Approach for addressing technology obsolescence with related cost information.

Deliverables:

Page 12 of 71 Pages

PWS

Task

Deliverable Title Format Due Date Distribution/ Copies

Frequency and Remarks

6.2.1 Sprint Plan Contractor-

Determined and

GAF

14-business days before the beginning of each Sprint. Government requested changes in five calendar days before each Sprint

Standard Distribution*

The first sprint shall begin no later than

(NLT) 45

calendar days after contract award date.

Approximately eight Sprint Plans with updates per contract year

6.2.1 Sprint Review

Brief

Contractor- Determined Format

(CDF)

First brief due approximately 45-business days after contract award date

COR Biweekly.

Exact schedule based on the

IMS

6.2.1 Sprint

Demonstrations

CDF In accordance with the

COR

approved IMS

COR Exact schedule based on the

IMS.

Approximately eight demonstrations per contract year

6.2.1 Sprint Review

Meeting Minutes

CDF Due within five business days after each Sprint Review meeting

COR As required per each Sprint Review meeting.

6.2.1 SRS GAF 14-business days before

the beginning of each Sprint with updates as part of each Sprint Plan.

COR SRS shall conform to

DID DI-IPSC-

81433A. One SRS document with each Sprint Plan with updates.

Exact due date depends on the IMS schedule

6.2.2 Content

Management Data Strategy

GAF Initial version due in 45-business days after the contract award date.

Standard Distribution*

One document with updates as required per contract year.

Exact due date depends on the

IMS

6.2.2 Database

schema and indexes

Contractor- Determined and

GAF

3 months after contract award date

COR Quarterly

6.2.2 Documentation

of data ingest pipeline services

Contractor- Determined and

GAF

3 months after contract award date

COR Quarterly

Page 13 of 71 Pages

6.2.2 Documentation

of data correlation rulesets

Contractor- Determined and

GAF

3 months after contract award date

COR Quarterly

6.2.2 Documentation

of Process for extending data lake with additional data sources

Contractor- Determined and

GAF

4 months after contract award date

COR Three times per contract year; every four months

6.2.3 Interoperability

Working Group Presentation Materials

Contractor- Determined and

GAF

In accordance with the COR approved IMS

COR As required based on the working group and stakeholders’ inputs

6.2.4 Architectural

Diagrams with updates

Department of Defense Architecture Framework (DoDAF) Compliant

In accordance with the COR approved IMS

COR Approximately 10 diagrams with updates per contract year.

6.2.4 Architecture

Specification with updates

DoDAF Compliant In accordance with the COR approved IMS

COR Bi-annual One architecture specification report with updates

6.2.5 UI Style Guide

and Coding Standards with updates

Contractor- Determined and

GAF

3 months after contract award date

COR Updated versions due approximately on 45-business days gap from each other as required based on the outcomes of TEMs and Integrated Product Team (IPT) meetings

6.2.5 Documentation

of APIs to allow external consumption of information from the data layers

Contractor- Determined and

GAF

4 months after contract award date

COR Three times per contract year; every four months

6.2.5 Documentation

of APIs to allow external use of engineering services

GAF 4 months after contract award date

COR Three times per contract year; every four months

Page 14 of 71 Pages

6.2.5 White Papers to

recommend data exchange techniques, integration of external data sources, alternative hosting or development/test environments, and software integration environments etc.

CDF 2 months after contract award date

COR Six times per contract year;

every 2 months

6.2 Updated

network diagram

Contractor- Determined and

GAF

6 months after contract award date

To address tasking in 6.3 and 6.4 Bi-annual

* Standard Distribution: One copy of the transmittal letter with the deliverable to the Primary COR. Deliverable and transmittal letter stored with GEMSIS CM according to the GEMSIS Configuration Management Plan.

6.3 Task 3 – Software Maintenance and Enhancement (O&M, FFP).

The objective of this task is for the contractor to implement robust Agile DevSecOps processes to manage the maintenance, enhancements, rollout, and operations of the capability. Contractor shall perform sprint execution under 6.3 based on the results of sprint planning and sprint development under 6.2. In addition, further objectives include the following:

• Maintain high-quality software code that follows a consistent style, is easily understood, is well documented, and appropriately tested

• Establish an Agile software development process consistent with industry best-practices

6.3.1 Subtask 1 – Maintenance

The objective of this task is to provide GEMSIS (JSDR and E2ESS) sustainment software releases that do not contain defects. The contractor shall prepare maintenance releases for the JSDR to address CRs COTS upgrades or replacements, integration of additional data sources, interface with external data sources and applications, implementation of necessary user interface features, and support of administrative functions. Software sustainment activities include sustainment for the JSIRO software and analysis widgets which have been integrated into the JSDR baseline. This includes sustainment for the Mobile Service Provider (MSP) work integrated into the JSDR baseline under Task 14. The contractor shall provide at least four scheduled GEMSIS sustainment releases per PoP (two for JSDR and two for E2ESS), and as many unscheduled (i.e., emergency) releases as necessary to address severity level 1 or 2 defects, or critical security issues or IA issues.

The sustainment releases shall include fixes and enhancements that are documented in GEMSIS CRs by users, have been prioritized and recommended by the GEMSIS PCB for implementation, and approved by the GEMSIS CCB.

The number and effort to complete the software changes is based upon available funding from the GEMSIS program. It is estimated that about 20 average-sized change requests can be included in each maintenance release.

The contractor shall report on progress made on implementing the CRs and inform the COR of capacity available to support additional changes. The contractor shall engage the user community and obtain their feedback to ensure existing GEMSIS user interface and workflow requirements are properly captured as part of the new software release.

The contractor shall ensure the performance of each GEMSIS release is acceptable. The contractor shall test the emerging release against the previous release’s performance baseline. If necessary, the contractor shall test the previous release to define the previous release’s performance baseline for comparison purposes. The baselines will include a Government-defined set of performance measures, which may be modified by the Government

Page 15 of 71 Pages periodically to align with software release requirements. The performance baseline report will be provided monthly for six months preceding each scheduled GEMSIS sustainment release.

The contractor level of effort will include support for integration of the modernized E2ESS software with the NTIA’s EL-CID Online capability. This includes integration and maintenance of web services with NTIA, database mapping, data maintenance forms, folder security, alerts and notifications including field help level messages.

For all GEMSIS software covered under this contract, the contractor shall follow existing GEMSIS configuration control board policies and procedures, as defined in the GEMSIS Configuration Management Plan. The contractor shall support the GEMSIS CCB/ PCB and BCB processes. The contractor shall provide inputs to and monitor the CR log in the designated GEMSIS CR tracker, and scope CRs prioritized by the COR and the PCB. The contractor shall provide estimates on time to implement fixes to defects. The contractor shall make changes to JSDR and E2ESS as approved by the GEMSIS CCB within the resources allocated to development. The contractor shall make updates to documentation (e.g., Installation Guide, User Guide) as required to reflect any changes in installation procedures or E2ESS and JSDR operation.

The contractor shall provide a system that minimizes the potential time of data refresh. While the data is being refreshed in the system, users will be able to continue their work without interruption. The contractor shall also provide software maintenance for the Data Maps which map source data to the JSDR, as necessary to accommodate format changes, Information Assurance Vulnerability Management (IAVMs) and required component patches.

The contractor shall perform and document results of regression testing. All maintenance releases will be delivered to the Government Configuration Management (CM) site ready for installation with complete IA compliance, documentation, and Request for Change (RFC) . The contractor shall deliver TDPs or updates to TDP component documents to reflect any changes resulting with the release.

If Government testing or operations uncovers severity level 1 or 2 defects in E2ESS or JSDR release, the software release is considered unacceptable and the contractor shall provide an updated release fixing the defects.

Existing TDP components for JSDR and E2ESS will be provided…