DRAFT WRMS ES PWS unrestricted.docx

Wideband Remote Monitoring Sensor (WRMS) Enhancement and Sustainment

PERFORMANCE WORK STATEMENT (PWS)

Contracting Officer’s Representative (COR)

a. Primary COR. See Point of Contact (POC) in Contract Administration Data

b. Alternate COR. See POC in Contract Administration Data

c. Property Administrator. See POC in Contract Administration Data

Task Order Title Wideband Remote Monitoring Sensor (WRMS) Enhancement and Sustainment

Background WRMS is an integrated subsystem of the Wideband SATCOM Operational Management System (WSOMS) and the Remote Monitoring and Control Equipment (RMCE) sites. WRMS monitors United States Department of War (DoW), Allied, and Government X/Ka-Band Super High Frequency (SHF) satellite communication on the Wideband Global SATCOM (Satellite Communications) (WGS) and Department of War (DoW) Defense Satellite Communications System (DSCS) satellites. WRMS performs satellite monitoring to ensure DoW/DoD communications that take place over these satellites occur as planned and to identify and mitigate interferences. These interferences can typically be contributed to environmental disruptions (sun/rain), unauthorized access, jamming, and operator error. Satellite monitoring not only aids in maintaining planned communications but enables more effective management of satellite resources. WRMS conducts monitoring of WGS in synchronized Spectrum Information Gathering (SIG) and In-Beam monitoring modes, while monitoring of DSCS is done only on an In-beam monitoring mode basis. WRMS is located at the following DoD sites:

Table 1-1: WRMS Requirements Locations

Northwest, Naval Computer and Telecommunications Area Master Station (NCTAMS) Atlantic (LANT), Chesapeake, Virginia (NWR)

Objectives In support of its mission to acquire and install WSOMS state-of-the-art strategic satellite network control and planning systems for use with the WGS and DSCS constellations, Project Office Wideband Control (PO WC) seeks services for the planning, analysis, and development of advanced system concepts based on tactical and strategic user requirements to support existing and new Wideband SATCOM satellite communications resources, technologies, and operational missions.

Scope This requirement is intended to provide a full range of WRMS support services including program management, system engineering, configuration management, technical manuals, training, and quality assurance services supporting the production, deployment, and lifecycle support of the WRMS. During installation, the contractor shall test the integration of new equipment and conduct training at all sites after each installation in addition to providing all spare equipment and parts required to support the initial fielding and depot sparing of the WRMS. The contractor shall ensure that the WRMS meets all applicable cybersecurity requirements in its production and deployment.

The contractor shall integrate COTS with any necessary modifications to deliver a system that meets the WRMS functional and performance requirements. The contractor shall work in conjunction with existing WSOMS subsystem integrators and stakeholders to ensure complete integration of the WRMS with those subsystems in the WSOMS environment. The contractor shall also execute Agile and incorporate the concepts of Continuous Integration, Continuous Development (CI/CD), and continuous deployment in addressing the WRMS technical and contractual requirements in this PWS with the Government as Product Owner. The contractor shall plan and conduct activities to verify the implementation and performance of WRMS components produced under this contract.

The contractor shall supply all personnel, equipment, supplies, facilities, transportation, tools, material, supervision, and other items not provided as part of Government Furnished Property (GFP), necessary to perform the defined requirements. Facilities are only required to house contractor personnel supporting the WRMS program, storage of GFP, and standup of both an unclassified and classified developmental lab environment.

The WRMS Assistant Product Manager, who also serves as a COR, will coordinate participation of the contractor in the integration of the WRMS into the WSOMS and WGS/DSCS community, and mediate all potential impacts to the WRMS or the WRMS on other communities.

At its most basic level, the primary function of WRMS is to aid the user in the identification and resolution of anomalies detected by the system. Anomalies are presented to the user through the comparison of planned vs. actual radio frequency (RF) measurement data. The WRMS Graphical User Interface (GUI) provides a visual comparison of planned satellite data, and real-time RF collected data. The planned data is provided by another Wideband Control subsystem named the Common Network Planning Software (CNPS). Predicted CNPS data is compared against the WGS and DSCS Live Measurement data.

There are three primary components of WRMS that satisfy the satellite monitor requirements of the system. These components are a mixture of hardware, software, and key algorithms developed for analysis. Custom or Commercial off-the-shelf (COTS) hardware products are utilized to collect analog RF signals and digitize them to In-Phase/Quadrature (I/Q) data. Digitized I/Q data will then be processed through use of spectrum characterization software algorithms. Finally, this characterized signal data will be provided to the operator for observation and correlation against predicted plan data.

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

Performance Requirements: The contractor shall perform the tasks under this PWS to satisfy the following WRMS capabilities and requirements:

a. Spectrum Monitoring - Expand spectrum monitoring capabilities to capture, process, and characterize WGS-11+ (WGS variants, and DSCS) signals at the same fidelity as detailed in the current WRMS PS. Requirements for both SIG and In-beam mode monitoring will be required for the entire satellite signal payload for WGS-11+, as with previous applicable satellites.

b. WGS-11+ - An ability to modify WRMS hardware/software to ensure dissemination activities and all operational requirements are met in support of WGS-11+ requirements. The modification activities will be developed under this contract.

c. WRMS Interface - The WRMS subsystem to subsystem interface shall be updated to retrieve all required WGS-11+ predicted information and SIG plan information. Coordination to determine the predicted information schema is required with the planning and integration subsystems. Additionally, the newly developed system is required to be backwards compatible with its WRMS predecessor system. Newly developed micro-services software which utilize a Cloud Foundry supported language shall be deployable to the legacy hardware via the WRMS Hardware Agnostic Interface (HAI). An ability to provide Interface Control Document (ICD) to share data and do program planning with other external programs and the larger SATCOM community of interest.

d. WRMS Client- The WRMS Client (or Graphic User Interface (GUI)) must accommodate WGS-11+ satellites by properly representing the signal payload visually to the operator. Visually representing includes, but is not limited to, a high-level dashboard, charted spectrum, alarm indicators, SIG processing cycle, performance measurements, and predicted measurements representation.

e. Automation - An ability to develop and expand the WRMS data to minimize the amount of manual decision making involved in determining the best possible resources available for establishing communication.

f. Security - An ability to maintain system security in alignment with the Authorization to Operate (ATO) through continuous Information Assurance Vulnerability Management and Security Technical Implementation Guide updates. This will be ongoing to protect system vulnerabilities through the Risk Management Framework processes.

g. Development Operations (DevOps) and Software Release - Software releases will be successfully completed through a rigorous release management process. Release management activity includes various validation and acceptance testing activities such as Initial Developmental Test (iDT), Developmental Test (DT), Initial Operational Test (iOT) and Operational Testing (OT). The contractor shall revise and update, as required by modifications to the WRMS and support software, test and training documentation and all media required for WRMS development, test, and operation. In turn, contractors may be expected to utilize CI/CD, Agile Methodologies, system demos, test automation, and deployment automation practices to accelerate solution delivery. This will be ongoing to support WRMS software release and for integration with other WSOMS subsystems.

h. Software Problem Change Request (SPCR) Resolution - An ability to resolve product defects and issues and provide enhancements to the system. SPCR resolution work will be ongoing to resolve software issues reported by the customer during each WRMS software release. All software problems such as Software Problem Reports (SPRs), Test Problem Reports (TPRs) will require this process.

i. Integrated Product Support (IPS) - An ability to provide documentation, planning, managing, and implementing IPS for each software release. An Installation Engineering Procedure (IEP) explains how the software operates and how to use it and includes support documentation for the Software Requirements Specification (SRS), Test Plan/Reports, Electronic Technical Manuals (ETM), and Training Manuals (TM). This will be ongoing to keep the WRMS documents library up to date.

Task 1 - Program Management

The objective of the Program Management task area is to establish the project management framework to ensure an effective development and delivery of capability through the implementation of a balanced approach with respect to cost, schedule, performance, and risk using an integrated, disciplined, and consistent process. In support of this area, the contractor shall perform activities including, but not limited to:

a. Project Integration

b. Project Scope Management

c. Project Time Management

d. Project Cost Management

e. Project Quality Management

f. Project Human Resource Management

g. Project Communication Management

h. Project Risk Management

i. Project Procurement Management

j. Project Stakeholder Management

The contractor, in conformance with this PWS, shall provide the Government with clear and continuous insight into the program schedule, technical performance, and risk in accordance with (IAW) requirements specified herein. The contractor shall immediately report to the COR any incident having the potential to impact schedule and/or costs along with planned corrective action. The contractor shall follow and perform all requirements and tasks IAW the WRMS PWS and required deliverables throughout the life of this contract. The contractor shall apply all other program management disciplines that are required to manage and direct the WRMS effort to successfully fulfill requirements and complete tasks described herein.

Agile Development

The contractor shall utilize Agile methodologies and practices to iteratively achieve all system engineering, system software updates, cybersecurity requirements, supportability analyses, production documentation, training, installation, and logistics support as defined herein. The contractor’s Agile implementation and practices shall include the following:

General Guidance

a. Work shall be executed using Scrum, Kanban, or a combination of both. Scrum based activities and practices will be structured consistent with the current version of “The Scrum Guide” (https://www.scrum.org/resources/scrum-guide) and approved by the Government.

b. Work executed with a Scrum methodology shall conform to a sustainable, time-boxed Sprint cadence between 2 and 4 weeks in duration that is consistent and synchronous across Agile teams. The Government has the right to specify the Sprint duration and timing to align activities with other WC programs and enable the implementation of Scaled Agile Framework (SAFe) (https://www.scaledagileframework.com) across product lines.

Agile Team Roles

a. Traditional Agile Team, Scrum Master, and Product Owner roles will be used for work being completed by Agile Scrum methodology.

b. The Government will appoint and provide a Product Owner to provide guidance, vet and prioritize program and Sprint Backlogs, provide feedback, approve work, and perform other Agile Product Owner functions.

c. The contractor shall provide cross-functional Agile teams to complete the work. Agile teams should be trained in Agile and SAFe methodologies (https://www.scaledagileframework.com) and possess all the skills needed to complete the scope of work. Teams will be expected to estimate and plan work using agile estimation methodology and Agile Lifecycle Management tools such as Atlassian Jira in the Government hosted collaboration environment.

d. The contractor shall provide a Scrum Master for each agile team who is experienced in Agile Fundamentals. The Scrum Master will be responsible for coordinating and conducting the agile process with and by the contractor’s agile teams.

e. A Scrum Team shall consist of six people or full-time equivalents for the 3-month enhancement) and 6-month enhancement contract line items (CLIN)s. The Government requires one (1) Scrum Team for a 3-month enhancement CLIN and two (2) Scrum Teams for a 6-month enhancement CLIN.

Agile Ceremonies and Activities

The following traditional Agile ceremonies shall be conducted by the contractor during each Sprint including, but not limited to:

a. Sprint Planning - A Sprint Planning session shall be conducted by each Agile Team at the beginning of each Sprint. Sprint Planning shall be executed to review and prioritize the Product Backlog with the Product Owner and identify User Stories which are to be added into the Sprint Backlog. Each Agile Team shall establish, document, and/or refine the Acceptance Criteria, Definition of Done, and other requirements for each User Story such as estimating the overall effort to complete the User Story. The Agile Team may use tools and metrics to calculate velocity or capacity when creating the Sprint Backlog. This will be to identify and document the level of resources available to complete each User Story and associated tasks with the team. The Agile Team shall also identify, document, and communicate outside resource dependencies, risks, and potential risk mitigations for each assigned task to the contractor’s Scrum Master, Project Management, and/or Product Owner.

b. Daily Standup - A Daily Stand-Up shall be conducted by each Agile Team, wherein, each member of the team discusses their progress and any potential blockers which impedes their current work activities. Additionally, dependency impacts, or risks associated with assigned User Stories, Epics, or Tasks shall be noted. Any changes in the expected status of all User Stories, Tasks, dependencies, or risks shall be documented and communicated by the Scrum Master to the contractor Project Manager and/or Product Owner.

c. Product Backlog Refinement - On a regular basis, the Agile Team, with input from the Product Owner, will conduct a review of the Product Backlog to re-assess priority of User Stories, develop/refine user stories in the product backlog, assign/refine estimates to User Stories, create/refine Sprint Roadmaps and further refine User Story details as needed.

d. Sprint Review - A Sprint Review shall be conducted by each Agile Team on the final day of each Sprint. This review shall be conducted to demonstrate and review all User Stories in the Sprint Backlog and determine which have been completed and satisfy the established Definition of Done and Acceptance Criteria. Any remaining functional task dependencies, risks, and associated mitigations shall be documented and discussed. The Sprint Review shall be attended by all stakeholders involved in the Sprint.

e. Sprint Retrospective – At the conclusion of the Sprint, each Agile Team will conduct a Sprint Retrospective to identify what went well, what could be improved, and resulting actions may be added into the next Sprint Backlog, or the Product Backlog, with agreement from the team and approval of the Product Owner.

Agile Artifacts and Practices

The following Agile Artifacts and Practices shall be conducted by the contractor including, but not limited to:

a. The contractor shall work with the Product Owner to develop, plan, maintain, and refine the product and Sprint Backlogs. The product backlog represents the portfolio of user stories needed to complete the scope of work, applicable deliverables, documentation, applicable testing / verification activity and other deliverables specified in this contract. Product and Sprint Backlogs are maintained by the contractor with inputs from the Product Owner.

b. The contractor shall also categorize and organize work in the backlog as Epics and releases/versions in the approved Agile Lifecycle management tool, where applicable.

c. The contractor shall maintain Sprint Roadmaps that illustrate major milestones, Epic completion, and which Epics are planned to be worked in which Sprints. Atlassian Jira version and Epic reports will be used and provided to the Government on demand to track progress against the Sprint Roadmap.

d. The contractor shall track progress using Sprint Burn-Down charts. With government approval, cumulative flow diagrams may be substituted for Sprint Burn-Down charts.

e. The contractor shall complete definition of ready standards that identify the criteria, such as all work must have defined acceptance criteria that must be satisfied for user stories and backlog items to be ready for work and included in a Sprint.

f. The Government intends to implement SAFe at the program level long term. The contractor shall demonstrate competence in SAFe methodology particularly Agile Product Delivery, Team and Technical Agility, Lean Agile Leadership competencies in their response. The contractor may be expected to participate in SAFe methodology, SAFe Planning Interval planning, SAFe Inspect and Adapt, SAFe System Demo activities.

g. Scrum of Scrums – A Scrum of Scrums meeting shall be held regularly to ensure coordination, integration, and cross-team dependencies of work items across the Agile Teams, other project teams, and stakeholder groups including the contractor Project Manager and the COR. The purpose of this meeting is to make sure each Agile Team can meet their Sprint goals and that the overall project goal is being met.

Tools

The contractor shall manage work in an approved Agile Lifecycle Management tool. The contractor shall be required to utilize the Government hosted and owned instance of Atlassian applications in the Government hosted collaboration environment to plan, manage, and track work. Atlassian Jira is a tool primarily used for bug tracking, issue tracking, and project management. The licenses required for this tool are funded by the Government and it stores government-related information, resulting in mandatory government access.

DevOps and Development Security Operations (DevSecOps)

The contractor shall implement installation and test automation using DevOps methodology, so that work can be built, tested, maintained, and deployed in an automated process. The contractor shall build, implement, and maintain a CI/CD pipeline that enables rapid transition of new features through design, coding, development testing, staging, formal acceptance testing and field deployment. The contractor shall demonstrate DevOps, automated build / unit testing, CI/CD, test automation, and installation automation capabilities with examples of how these capabilities have been applied on other projects to accelerate the release management process. The contractor shall demonstrate how it will use DevSecOps practices such as Test-Driven Development, Behavior Driven Development, code quality and coding standards, CI/CD to build and maintain high system / release quality, and Cyber Security.

The contractor shall participate and complete an Agile DevOps assessment that evaluates its DevOps maturity and ability to develop, build, test end-to-end, stage, deploy and verify new functionality on demand.

The contractor shall implement an automated build process with automated unit tests. The contractor shall establish a target unit testing coverage baseline with the Government and is expected to maintain unit testing code coverage greater than that target baseline.

Task Execution Plan

The contractor shall provide a IAW DI-MGMT-80004A Data Item Description (DID) and shall include methodology for managing this effort, and metrics by which the work performance can be measured.

Progress, Status, and Management Report (PSMR)

The contractor shall prepare and submit a PSMR IAW DI-MGMT-80227 DID. The PSMR shall report costs including GFP update and inspection report, equipment obsolescence, inform of existing or potential problems, and provide insight into progress of the work and status of the program and the assigned tasks. The contractor shall include any Continuous Process Improvement (CPI) recommendations in the PSMR focusing on specific business processes that may be improved. The contractor shall track performance, cost outcomes, savings achieved, and how savings are applied for all CPI’s initiatives that are implemented. The contractor shall continue to report CPI’s updates until they are closed.

Risk Management Status Report (RMSR)

The contractor shall produce and maintain a program RMSR to list all risks identified for the contract’s planned performance measurement, including program cost, schedule, and performance. The documented information shall include an analysis of the relative level of probability and potential severity of impact, as well as one or more proposed mitigations for each identified risk. The RMSR shall be continuously updated, including information from the Agile Teams. The current RMSR shall be furnished by the contractor to the Government with the monthly PSMR. The most recent RMSR shall be a review item at each Program Management Review (PMR).

Integrated Master Schedule (IMS)

The contractor shall generate and regularly maintain a reliable IMS that defines when work activities will occur, how long they will take, and how they are related to one another. The IMS not only provides a road map for systematic project execution,but also provides the Government the means to gauge progress, identify, and address potential problems and promote accountability. The IMS shall include a Gantt chart indicating expected start and completion dates, and personnel resources for all critical requirements IAW DI-MGMT-81650 DID. The IMS shall be directly traceable to the effort described in the task order. After award of the task order, any proposed changes to the schedule must be accompanied by rationale. The COR shall approve all changes events and activities that are on the critical path of the IMS. When changes to the IMS have been approved, the IMS shall be updated. The contractor shall show progress of requirements relative to the original schedule when making changes to the IMS.

Meetings

The contractor may combine the conduct of meetings and reviews covering both management and technical progress as identified below when practical and mutually agreed upon by the contractor and the Government. The contractor shall coordinate date, location, agenda, briefing materials, and meeting minute requirements with the COR.

Briefing Materials

The contractor shall prepare and submit briefing materials IAW DI-MGMT-81605 DID. The contractor shall provide a read-ahead package that shall contain a complete copy of the briefing to be conducted, and any supplementary materials pertinent to the briefing prior to the start of the meeting. Briefing materials shall be prepared and submitted.

Meeting Minutes

The contractor shall record minutes of the meetings and provide those minutes to the Government IAW DI-ADMN-81250B DID. The meeting minutes shall include key decisions, outcomes, and action items with due dates.

Program Management Review (PMR) Meetings

The contractor shall schedule and conduct contract wide PMR meetings as coordinated with the COR on a quarterly basis. At these meetings, the COR will appraise the contractor of how the Government views the contractor's performance and the contractor will appraise the Government of problems, if any, being experienced. During these meetings, the contractor shall present necessary data to enable a joint review of assigned tasks, schedules, and resource expenditures. Appropriate action shall be taken to resolve outstanding issues.

Technical Interchange Meetings (TIMs)

The contractor shall support periodic teleconferences and TIMs with the COR, as required, to allow for the cross flow of information between the contractor and other designated government personnel addressing specific technical and program areas. The contractor and the Government may propose any meetings and subjects that are deemed necessary and address an approach to the conduct of all such meetings (agendas, schedules, locations for meetings, committees needed, and organizational assignments to committees; and administrative details such as action item reporting and/or meeting minutes).

a. The contractor shall report the status, analyses, recommendations with rationale, and other subsystems issues related to the specific topic(s) under discussion and the mitigation of issues/risks associated with the resolution of problems in the subject areas.

b. Meetings will be scheduled prior to a release being defined to ensure Government requirements are contained in the that version.

Configuration Management (CM)

The contractor shall establish and control hardware and software configuration baselines, through its own internal configuration management processes prior to acceptance of the Product Baseline (PBL) by the Government. The configuration identification for the PBL shall be established by data specified in the WRMS Technical Data Package (TDP).

Configuration Control

The contractor shall prepare and submit Configuration Control Documents (CCDs) IAW DI-MISC-80711A DID to the Government for approval when the contractor determines that a change to the Government functional baseline (FBL) or the Government approved PBL is necessary. The Government controlled baselines are the FBL as documented in the WRMS system specification and the approved TDP with product specifications.

The contractor shall not implement changes without the receipt of a formal approval from the Government. Such approval may modify the requested change(s). The only authorized CCDs shall consist of:

a. Engineering Change Proposals IAW DI-CMAN-80639C DID

b. Value Engineering Change Proposals IAW (DI-CMAN-80639C DID

c. Request for Variance IAW DI-CMAN-80640D DID

d. Engineering Release Record IAW DI-CMAN-80463C DID

e. Specification Change Notice IAW DI-CMAN-80643C DID

f. Notice of Revision IAW DI-CMAN-80642C DID

Configuration Audit

The contractor shall prepare and deliver the Configuration Audit Plan IAW DI-SESS-81646B DID as requested by the APM/COR. The contractor shall conduct the audit IAW the Configuration Audit Plan after the acceptance by the Government of all verification testing results. The contractor shall produce and deliver a Configuration Audit Summary Report (CASR) on all of the Configuration Items that are to be delivered to the Government or individual Configuration Audit reports for each configuration item to be delivered. The contractor shall deliver the CASR IAW DI-CMAN-81022C DID. At a minimum, the CASR’s content shall include:

a. Type of Audit: (Functional, or Physical): Specification of Audit Type.

b. Release or Version Number: Unique numeric of project hardware or software release.

c. Date of Audit: Date of execution of audit.

d. Duration of Audit: Actual time elapsed during audit.

e. Audit Coordinator: Full name of audit coordinator.

f. Outstanding Issues/Discrepancies: Actual text description of issues or discrepancies which require future or further effort.

g. List Configuration Items in Error: Provide by text and/or numbers, the identity of all configuration items observed in error with a textual explanation of why and what the error is.

h. Recommendations/Action Items: Who's responsible and required completion date: List recommendations or action items with responsible person’s full name and when the actions are due?

i. Submitted By: Name and title of person completing this report.

Configuration Management Reporting

The contractor shall report configuration management activities in the PSMR for this effort, information describing proposed changes to identified internal hardware and software configuration baselines and identify when and how those changes were implemented or otherwise dispositioned. The contractor shall maintain a record of any changes made to individual quantitative requirements from the values stated in the System Specification that occur as internal baselines are developed, and revisions are made to those baselines. The contractor shall cross-reference those changes to specific activities and events in which the need for such changes was discovered and the change approved. This data shall be discussed during TIMs and delivered as part of the approved PBL.

Central Data Repository

The contractor shall provide a central electronic repository for all technical and management data that are either required deliverables or are by-products of the Agile processes and related activities, such as working draft documents, configuration, tracking, and quality assurance. This data shall include, but not be limited to, design information, hardware and software test procedures and results, engineering and logistics documentation, and any databases used or generated during this contract. The most current version of any document or data shall be made available at the end of each Sprint. This version plus its historical predecessors shall be made accessible to authorized government representatives. The contractor shall index and control versions of all documents in the central repository.

a. All classified data shall be paper hardcopy stored and safeguarded IAW the DoD 5220.22M, “National Industrial Security Program Operating Manual” and the security classification guides applicable to this contract.

b. Within 30 days of the contract award, the contractor shall provide authorized government representatives remote access to the documents in the central repository. The remote access capability shall be implemented using the internet and shall be available 24 hours per day/7 days per week. The remote access capability shall allow authorized government representatives to view and download documents via a web browser.

c. The Central Data Repository shall include a capability for government representatives to provide comments on items posted in the repository.

d. The contractor’s format for technical data and computer software must be acceptable to the Government. If data is recorded with a specialized tool such that it can only be accessed by that tool, the contractor shall provide the Government with the applicable procedures and identify the software and licenses required to effect remote access to the tool.

e. All data in the Central Data Repository shall be transferred to the Government at the completion of the contract.

Data Management

The contractor shall provide all technical and management data that are either required deliverables or are by-products of the production and related activities, such as configuration management, requirements tracking, and quality assurance documents IAW the instructions in the PWS. Data shall include, but not be limited to, production information, hardware and software test procedures and results, engineering and logistics documentation, and any databases used or generated during this task order.

a. All deliverables such as briefings, graphics, project schedules, spreadsheets, reports, and documents shall be provided using Adobe Portable Document Format (PDF) and Microsoft Office software file formats (i.e., PowerPoint, Visio, Access, Project, Excel, and Word). Other formats such as Extensible Markup Language (XML) and Hyper Text Markup Language (HTML) may be used only as approved by the COR. Upon delivery, all documents become government property and shall bear no proprietary markings.

b. Contractor format for the content of all deliverables is acceptable unless otherwise stated in this PWS.

c. All paper hardcopy stored classified data shall be stored and transmitted IAW the DoD 5220.22-M, “National Industrial Security Program Operating Manual”, and the security classification guides applicable to this contract.

Upon determination at Sprint Planning, the Government can elect the applicable deliverables related to Sprint efforts. Delivery dates and standards shall be as established in the deliverable with applicable DID. However, the contractor shall track these timelines to communicate a potential waiver of any deliverables based on Sprint activities. The COR shall perform final inspection and acceptance of deliverables and waivers. Some deliveries may need to be accelerated based on urgency of the tasks. It is acceptable to execute a Delta Change for documentation work products where possible.

Deliverables

The following deliverables are applicable for this task:

Revision to be delivered NLT 10 calendar days after receipt of government comments if required.

Once per order

Revision to be delivered NLT 10 calendar days after receipt of government comments if required.

Monthly

Revision to be delivered NLT 10 calendar days after receipt of government comments if required.

Monthly

Final to be delivered NLT 10 calendar days after receipt of government comments.

Deliver when baselines are changed.

Final to be delivered NLT 10 calendar days after receipt of government comments.

Deliver when an audit plan has been changed.

Revision to be delivered NLT 10 calendar days after receipt of government comments if required.

Deliver when an audit was performed.

*Standard Distribution: One copy of the transmittal letter with the deliverable to Contracting Officer (KO), Contract Specialist, and COR.

Task 2 – Systems Engineering

The objective of the System Engineering task area is to establish the technical framework for delivering WRMS materiel capabilities to the Warfighter. It brings together component subsystems and ensure that those subsystems function as a whole. System elements (including software items, hardware items, manual operations, and other systems, as necessary) are integrated to produce a complete system that will satisfy the system. In support of this area, the contractor shall perform systems engineering activities for all legacy, current, and future WRMS activities including, but not limited to:

a. Technical Planning & Assessment

b. Decision Analysis

c. Requirements Analysis Management

d. Technical Data Management

e. Interface Management

f. Design Analysis Engineering

g. Systems Architecture

h. System Integration Strategy and Planning

i. Systems Deployment and Lifecycle Engineering

j. Information Technology Service Management

k. Engineering Assessment

l. Modeling and Simulation

m. Cloud Engineering

n. Satellite Communications Engineering

Requirements Engineering

The contractor shall perform the following requirements activities:

a. Establish and maintain a Requirements Traceability Matrix (RTM)

b. Define a capability that links the needs of the users to the system to be designed and developed

c. Define a system that meets users’ mission requirements within specified cost and schedule constraints

d. Analyze user requirements and translate user needs into basic functions

e. Develop a quantifiable set of performance requirements

f. Define each function that the system is required to perform

g. Define implementation constraints (stakeholder requirements or solution limitations)

h. Translate performance requirements into specific system technical design requirements and functions

System Specification

The contractor shall maintain and update the System Specification document which describes the operational, and performance requirements for the WRMS derived from the WRMS Concept of Operations (CONOPS) and WSOMS Capability Production Document (CPD), and any changes required by the contents of any hardware/software release. The contractor shall document and provide revised changes to the System Specification IAW DI-SESS-8134A DID.

Software Requirements Specification (SRS)

The contractor shall maintain and update the SRS document which describes what the system will do and how it is expected to perform and contains all implemented requirements and new requirements that have not yet implemented including any changes/additions caused by any hardware/software upgrades. The contractor shall prepare and submit the SRS IAW DI-IPSC-81433A DID.

Design Engineering

The contractor shall perform design activities to analyze and refine requirements using various methodologies throughout the lifecycle of the system. Focus areas within the Design Engineering includes engineering assessment, pilots and initiatives, modeling and simulation, and systems analysis and investigation.

Focused Critical Design Review (FCDR)

The contractor shall conduct FCDR for any changes made to the WRMS baseline that require a detailed design. For speed and agility, the FCDR is the combined Preliminary Design Review (PDR) and Critical Design Review (CDR). Before each Sprint Planning Session, all Agile Epics/Stories expected to be implemented in the upcoming three Sprints shall be analyzed for complexity, including new requirements and any modifications to the System Specification and SRS documents. Following the analysis, the contractor shall conduct the FCDR to explain the intended approach to the Epic/Story to ensure that it can proceed into development, demonstration, and testing, is able to meet stated performance requirements within the applicable cost, schedule, and risk constraints. The purpose of the FCDR is to:

a. Provide the Government with the means to ascertain the contractor’s understanding of the requirements

b. Verify the contractor’s ability to address the specific requirements

c. Verify that the desired product has been designed

d. Ensure that any lifecycle support issues are addressed

e. Ensure that such support will be available for the expected useful life of the end item.

The FCDR briefing packages and meeting minutes shall be the formal record of the approved design implementation plan from the review. The FCDRs will be held, as required, within the agile process. The approval of the design review will include the following:

a. FCDR within the Agile process

b. All implementation issues resolved

c. All allocated requirements are traceable to test procedure documents

d. Impact to the technical documents

e. All stakeholders agree on content and appropriate design implementation

f. All stakeholders agree on the degree to which risks have been successfully managed and any outstanding risk management issues resolved.

In order to manage the requirements, sustain the system, and enable software releases to be executed, the contractor shall review and prioritize the Product Backlog with the Product Owner and identify User Stories to be added into the Sprint Backlog. The contractor shall establish, document, and/or refine the Acceptance Criteria, Definition of Done, and other requirements for each User Story including an estimate of overall effort to complete the User Story.

Configuration Control Board (CCB)

The contractor shall complete the WRMS CCB package for each hardware/software/Information Assurance Vulnerability Management (IAVM) release which will document any new system features or SPCRs to be resolved, impacts to the interface, interoperability, security, logistics, and subsystem dependencies, or affected. The contractor shall create SPCRs to describe the required hardware and software of WRMS and any requested changes to a particular subsystem or software version. The CCB package will be submitted to the WSOMS CCB’s community for approval. The approval of this CCB package is required prior to any testing event at the Tania Perciacannte Wideband Integration Center (TPWIC) and Software Materiel Release. For the IAVM, the contractor shall upgrade, test, implement, and complete a quarterly cybersecurity release that addresses existing and new threats to the system security posture within the 3-month or 90-calendar days.

The Government may, at its discretion, require the contractor to support CCB activities in the Government hosted collaboration environment. The licenses required for this tool are funded by the Government and it stores government-related information, resulting in mandatory government access.

Release Notes

The contractor shall create a Release Notes for each hardware/software/IAVM release to submit as part of the WRMS CCB approval process. The Release Notes document the recent changes, feature enhancements, or bug fixes in each release. The WRMS Release Notes shall be prepared and submitted IAW DI-MISC-80711A DID.

Interface Management

The contractor shall assess the impact of the originally defined capabilities and interfaces, performance parameter thresholds and objectives, and the overall system when defining and modifying interfaces. The contractor shall perform interface activities including, but not limited to:

a. Document the system's internal and external interfaces and their requirement specifications

b. Define and establish interface specifications

c. Assess compliance of interfaces among configuration items composing systems or systems-of-systems

d. Monitor the viability and integrity of interfaces within a system

e. Manage the interface management plan

f. Ensure interfaces are consistent with the program’s configuration management plan

Interface Control Document (ICD)

The contractor shall hold regular meetings with the WRMS, WSOMS subsystems and other SATCOM communities to discuss the internal and external interfaces. The contractor shall review all proposed change requests, as well as all change requests approved for implementation, and advise the Government of any possible impacts to the WRMS program.

The contractor shall maintain and update the ICD which captures all interface requirements of the WRMS sub-system with all with external WSOMS sub-systems and users IAW DI-MISC-80711A DID.

Network Engineering

The contractor shall design WRMS to be connected and communicated to the WSOMSNet and be managed in the network and exchange data in a secure and resilient network to enhance mission effectiveness. The WRMS system shall continuously provide interoperable, secure, and operationally effective information exchanges to enable a network-centric (net-centric) military capability. The specific capabilities of the WRMS to support net-centricity are delineated in the WRMS System Specification. WRMS hardware shall allow ease of upgrade, scalability, and interchangeability with similar and improved equipment. Human Factors Engineering (HFE) considerations shall be used in the configuration, system integration, positioning of equipment, operation, setup, and maintenance.

The contractor shall maintain and update the Domain Controller and Networking Prerequisites document which provides the required steps and procedures necessary to configure the domain controllers and other networking devices as required for the WRMS subsystem. The contractor shall ensure the configurations documented to match the WSOMSNet and Remote Monitoring and Control Element (RMCE) networks. Any difference in configurations between the Wideband Satellite Operations Center (WSOC) and the contractor’s lab should be noted. Furthermore, the contractor shall submit SPCRs to the WSOMSNet or RMCE subsystem to document any domain controllers or network changes as required supporting a release. The contractor shall create and submit the Domain Controller and Networking Prerequisites document IAW DI-MISC-80711A DID.

Bare Metal Build (BMB)

The contractor shall deliver the BMB which includes detailed, step by step instructions for how to build each WRMS platform. It shall include all hardware, software and settings required for installation, not including the WRMS software itself. All required cybersecurity requirements shall be included in this installation as applicable. The BMB is applicable for an initial system and may require updates with new hardware and software. The WRMS BMB shall be prepared and submitted IAW DI-MISC-80711A DID.

System Backup & Recovery Procedures (SBRP)

The contractor shall deliver the SBRP which includes detailed, step by step instructions and procedures to provide data protection and security. Any loss of data due to file corruption, virus, or human error can severely affect the system or system of systems. The contractor shall provide, for the SBRP, keystroke level instructions detailing how to perform backups of the virtual environment that include, but are not limited to, the following: the operating systems and the subsystem operating systems (Windows and Linux based environments). The contractor shall provide any other backup and recovery procedures needed to restore the entire WRMS environment in the event of a hardware or software failure including all stored operational data. The contractor shall provide a set of instructions for the backup and recovery of the database operating system (Enterprise Database PostgreSQL) and micro-services. The WRMS SBRP shall be prepared and submitted IAW DI-IPSC-81443A DID.

System Administrator Manual (SAM)

The contractor shall deliver the SAM which includes specific tasks and insights into managing the WRMS in its operational environment including startup, shutdown, backup and recovery procedures, procedures to install system security updates (i.e., IAVM/security patches, Security Technical Implementation Guidelines (STIGs) updates), and diagnostic procedures necessary for establishing and maintaining a WRMS in full mission readiness.