HC104719R0010_AMD01_SMCS_N4143_11212019.pdf

N4143

AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT

Except as provided herein, all terms and conditions of the document referenced in Item 9A or 10A, as heretofore changed, remains unchanged and in full force and effect.

15A. NAME AND TITLE OF SIGNER (Type or print)

30-105-04EXCEPTION TO SF 30

APPROVED BY OIRM 11-84

STANDARD FORM 30 (Rev. 10-83) Prescribed by GSA

FAR (48 CFR) 53.243

The purpose of this amendment is to:

a) Update the Request for Proposal (RFP) response date from 02-Dec-2019 02:00 PM to 09-Dec-2019 02:00 PM.

b) Provide an updated Performance Work Statement (PWS)

c) See Summary of Changes for additional details.

1. CONTRACT ID CODE PAGE OF PAGES

S 1 50

16A. NAME AND TITLE OF CONTRACTING OFFICER (Type or print)

16C. DATE SIGNED

BY 21-Nov-2019

16B. UNITED STATES OF AMERICA15C. DATE SIGNED15B. CONTRACTOR/OFFEROR

(Signature of Contracting Officer)(Signature of person authorized to sign)

8. NAME AND ADDRESS OF CONTRACTOR (No., Street , County, State and Zip Code) X HC104719R0010

X 9B. DATED (SEE ITEM 11)

05-Nov-2019

10B. DATED (SEE ITEM 13)

9A. AMENDMENT OF SOLICITATION NO.

11. THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS

X The above numbered solicitation is amended as set forth in Item 14. The hour and date specified for receipt of Offer X is extended, is not extended.

Offer must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended by one of the following methods:

(a) By completing Items 8 and 15, and returning 1 copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted;

or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOUR ACKNOWLEDGMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN

REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified.

12. ACCOUNTING AND APPROPRIATION DATA (If required)

13. THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACTS/ORDERS.

IT MODIFIES THE CONTRACT/ORDER NO. AS DESCRIBED IN ITEM 14.

A. THIS CHANGE ORDER IS ISSUED PURSUANT TO: (Specify authority) THE CHANGES SET FORTH IN ITEM 14 ARE MADE IN THE

CONTRACT ORDER NO. IN ITEM 10A.

B. THE ABOVE NUMBERED CONTRACT/ORDER IS MODIFIED TO REFLECT THE ADMINISTRATIVE CHANGES (such as changes in paying office, appropriation date, etc.) SET FORTH IN ITEM 14, PURSUANT TO THE AUTHORITY OF FAR 43.103(B).

C. THIS SUPPLEMENTAL AGREEMENT IS ENTERED INTO PURSUANT TO AUTHORITY OF:

D. OTHER (Specify type of modification and authority)

E. IMPORTANT: Contractor is not, is required to sign this document and return copies to the issuing office.

14. DESCRIPTION OF AMENDMENT/MODIFICATION (Organized by UCF section headings, including solicitation/contract subject matter where feasible.)

10A. MOD. OF CONTRACT/ORDER NO.

2. AMENDMENT/MODIFICATION NO. 5. PROJECT NO.(If applicable)

6. ISSUED BY

3. EFFECTIVE DATE

21-Nov-2019

CODE

DISA/CONTRACTS-NCR

6914 COOPER AVE

FORT MEADE MD 20755-7090

HC1047 7. ADMINISTERED BY (If other than item 6)

4. REQUISITION/PURCHASE REQ. NO.

CODE

See Item 6

FACILITY CODECODE

EMAIL:TEL:

x 1

HC104719R0010

SECTION SF 30 BLOCK 14 CONTINUATION PAGE

SUMMARY OF CHANGES

SECTION A - SOLICITATION/CONTRACT FORM

The required response date/time has changed from 02-Dec-2019 02:00 PM to 09-Dec-2019 02:00 PM.

The depository location FBO has been deleted.

The number of offeror copies required has decreased by 1 from 1 to 0.

SECTION B - SUPPLIES OR SERVICES AND PRICES

CLIN 0005

The option status has changed from No Status to Option.

CLIN 0007

The CLIN extended description has changed from:

ODCs must be purchased in accordance with the Contractor's approvedPurchasing System, as applicable. ODCs may be purchased from General Service Administration (GSA) Schedules or Enterprise Software Initiative (ESI), if available and authorized by the Contracting Officer. ODCs must be incidental to the work being performed under this contract. The Contractor will provide ODCs on a cost reimbursement basis only. All ODCs must be pre-approved in writing by the COR prior to the Contractor incurring the cost. The Contractor shall be authorized to invoice on a monthly basis and in accordance with FAR Part 31.Refer to the CLIN Summary Tab of the Pricing Template Worksheet for the plug in number.

To:

ODCs must be purchased in accordance with the Contractor's approved Purchasing System, as applicable. ODCs may be purchased from General Service Administration (GSA) Schedules or Enterprise Software Initiative (ESI), if available and authorized by the Contracting Officer. ODCs must be incidental to the work being performed under this contract. The Contractor will provide ODCs on a cost reimbursement basis only. All ODCs must be pre-approved in writing by the COR prior to the Contractor incurring the cost. The Contractor shall be authorized to invoice on a monthly basis and in accordance with FAR Part 31. Refer to the CLIN Summary Tab of the Pricing

CLIN 1007

ODCs must be purchased in accordance with the Contractor's approvedPurchasing System, as applicable. ODCs may be purchased from General Service Administration (GSA) Schedules or Enterprise Software Initiative (ESI), if available and authorized by the Contracting Officer. ODCs must be incidental to the work being performed under this contract. The Contractor will provide ODCs on a cost reimbursement basis only. All ODCs must be pre-approved in writing by the COR prior to the Contractor incurring the cost. The Contractor shall be authorized to invoice on a monthly basis and in accordance with FAR Part 31.Refer to the CLIN Summary Tab of the Pricing

ODCs must be purchased in accordance with the Contractor's approved Purchasing System, as applicable. ODCs may be purchased from General Service Administration (GSA) Schedules or Enterprise Software Initiative (ESI), if available and authorized by the Contracting Officer. ODCs must be incidental to the work being performed under this contract. The Contractor will provide ODCs on a cost reimbursement basis only. All ODCs must be pre-approved in writing by the COR prior to the Contractor incurring the cost. The Contractor shall be authorized to invoice on a monthly basis and in accordance with FAR Part 31. Refer to the CLIN Summary Tab of the Pricing

CLIN 2007

ODCs must be purchased in accordance with the Contractor's approvedPurchasing System, as applicable. ODCs may be purchased from General Service Administration (GSA) Schedules or Enterprise Software Initiative (ESI), if available and authorized by the Contracting Officer. ODCs must be incidental to the work being performed under this contract. The Contractor will provide ODCs on a cost reimbursement basis only. All ODCs must be pre-approved in writing by the COR prior to the Contractor incurring the cost. The Contractor shall be authorized to invoice on a monthly basis and in accordance with FAR Part 31.Refer to the CLIN Summary Tab of the Pricing

ODCs must be purchased in accordance with the Contractor's approved Purchasing System, as applicable. ODCs may be purchased from General Service Administration (GSA) Schedules or Enterprise Software Initiative (ESI), if available and authorized by the Contracting Officer. ODCs must be incidental to the work being performed under this contract. The Contractor will provide ODCs on a cost reimbursement basis only. All ODCs must be pre-approved in writing by the COR prior to the Contractor incurring the cost. The Contractor shall be authorized to invoice on a monthly basis and in accordance with FAR Part 31. Refer to the CLIN Summary Tab of the Pricing

CLIN 3007

ODCs must be purchased in accordance with the Contractor's approvedPurchasing System, as applicable. ODCs may be purchased from General Service Administration (GSA) Schedules or Enterprise Software Initiative (ESI), if available and authorized by the Contracting Officer. ODCs must be incidental to the work being performed under this contract. The Contractor will provide ODCs on a cost reimbursement basis only. All ODCs must be pre-approved in writing by the COR prior to the Contractor incurring the cost. The Contractor shall be authorized to invoice on a monthly basis and in accordance with FAR Part 31.Refer to the CLIN Summary Tab of the Pricing

ODCs must be purchased in accordance with the Contractor's approved Purchasing System, as applicable. ODCs may be purchased from General Service Administration (GSA) Schedules or Enterprise Software Initiative (ESI), if available and authorized by the Contracting Officer. ODCs must be incidental to the work being performed under this contract. The Contractor will provide ODCs on a cost reimbursement basis only. All ODCs must be pre-approved in writing by the COR prior to the Contractor incurring the cost. The Contractor shall be authorized to invoice on a monthly basis and in accordance with FAR Part 31. Refer to the CLIN Summary Tab of the Pricing

CLIN 4007

ODCs must be purchased in accordance with the Contractor's approvedPurchasing System, as applicable. ODCs may be purchased from General Service Administration (GSA) Schedules or Enterprise Software Initiative (ESI), if available and authorized by the Contracting Officer. ODCs must be incidental to the work being performed under this contract. The Contractor will provide ODCs on a cost reimbursement basis only. All ODCs must be pre-approved in writing by the COR prior to the Contractor incurring the cost. The Contractor shall be authorized to invoice on a monthly basis and in accordance with FAR Part 31.Refer to the CLIN Summary Tab of the Pricing

ODCs must be purchased in accordance with the Contractor's approved Purchasing System, as applicable. ODCs may be purchased from General Service Administration (GSA) Schedules or Enterprise Software Initiative (ESI), if available and authorized by the Contracting Officer. ODCs must be incidental to the work being performed under this contract. The Contractor will provide ODCs on a cost reimbursement basis only. All ODCs must be pre-approved in writing by the COR prior to the Contractor incurring the cost. The Contractor shall be authorized to invoice on a monthly basis and in accordance with FAR Part 31. Refer to the CLIN Summary Tab of the Pricing

SECTION C - DESCRIPTIONS AND SPECIFICATIONS

The following have been added by full text:

PWS_AMD01_QA_11212019

PERFORMANCE WORK STATEMENT (PWS)

as of 25 September 21 November 2019

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

Not applicable. This is a new development effort.

1. Contracting Officer’s Representative (COR). Identified in Local Clause G1 – Points of Contact

2. Contract Title. Advanced Wireless Services-3 (AWS-3) 2025-2110 Megahertz (MHz) Spectrum Management/Coordination System (SMCS)

3. Background. This effort is required to support the spectrum management and coordination of the 2025-2110 MHz band as a result of the third Advanced Wireless Services (AWS-3) auction. In March 2014, the Federal Communications Commission (FCC), in collaboration with the National Telecommunications and Information Administration (NTIA), developed rules for the auction and reallocation of the 1695-1710 MHz and 1755-1780 MHz radio frequency bands, which at that time were allocated exclusively for Federal use. Between November 2014 and January 2015, the FCC conducted the third Advanced Wireless Services (AWS) auction (“Auction 97”) to establish new AWS licenses in the 1695-1710 MHz, 1755-1780 MHz, and 2155-2180 MHz bands. For reference, AWS-3 Transition information can be found at the following website: https://www.ntia.doc.gov/category/aws-3-transition.

The Defense Spectrum Organization (DSO) is responsible for providing common Department of Defense (DoD) services including the overarching capabilities and analyses required to implement the DoD’s Transition Plans. The Defense Information Systems Agency (DISA) - DSO Transition Plan includes six tasks:

• DISA1: 1755-1780 MHz Early Entry Portal

• DISA2: 1755-1780 MHz Federal Spectrum Management System Portal

• DISA3: 1780-1850 MHz Compression and Optimization Tool

• DISA4: 2025-2110 MHz Spectrum Management/Coordination System

• DISA5: 1755-1780 MHz Spectrum Sharing Test & Demonstration Program

• DISA6: DoD Spectrum Relocation Management Team (DSRMT)

The DSRMT oversees DSO activities being conducted under the DISA Transition Plan, including oversight of contracted work.

Under the DISA4 activities, and as part of the AWS-3 transition, selected DoD system operations are targeted to gain access to the 2025-2110 MHz band and operate on a co-primary status on a non-interference basis with incumbent Television Broadcast Auxiliary Service (BAS), the Cable Television Relay Service (CARS), and the Local Television Transmission Service (LTTS) operations. The SMCS will be used to facilitate spectrum sharing between the incumbent licensees’ operations, and the transitioning DoD system operations.

This effort will be a new start; however, the DSO has been conducting DISA4 planning with various stakeholders, to include the BAS and the office of the DoD Chief Information Officer. DSO has conducted multiple transition planning exercises and has enlisted contractor support for these planning activities under the T4140 – “2025- 2110MHz Coordination and Collaboration Support” contract.

4. Objectives: The primary objective of the SMCS Development Task Order (TO), is to provide an integrated system-of-systems that automates an end-to-end workflow for coordinating spectrum access between DoD system operations and incumbent Television BAS, CARS, and LTTS operations (hereafter referred to as Electronic News Gathering (ENG) operations).

The contractora shall apply an advanced working knowledge of spectrum engineering, spectrum requirements, data management, and business process workflow development to manage SMCS development, deployment, operations, maintenance, and continual enhancement services. The contractor shall manage the software development lifecycle, delivery and deployment of the initial SMCS capability, and continually enhance the SMCS. It is envisioned that the spectrum sharing of the 2025-2110 MHz will include a wide range of sharing scenarios, including cases where DoD access has been pre-coordinated with the ENG community, and cases where active coordination between DoD and the ENG community will be required. SMCS shall be able to facilitate these various sharing scenarios. The contractor shall implement industry standard agile development methodologies to develop and deliver the initial operational release of the SMCS, continuing to develop and deliver additional features and automation.

5. Scope. This requirement will provide an integrated system-of-systems that automates an end-to-end workflow for coordinating spectrum access between DoD system operations and ENG operations as defined in this PWS and applicable DoD guidelines. This requirement 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. It is the expectation of this requirement that the contractor shall continuously evolve this requirement in parallel with evolving and emerging technologies.

The contractor shall develop, deliver, operate, and sustain a web-accessible SMCS that will automate and facilitate the coordination process for the sharing of the 2025-2110 MHz band between DoD and ENG operations based on requirements over time. The SMCS shall include:

• A database of DoD and ENG operational and technical characteristics and coordination history.

• Automation of end-to-end business process coordination workflow and data exchange between authorized DoD and ENG stakeholders, including a tracking system of the coordination efforts.

• Analytical tools to determine interference-free (coexistence) operations between the DoD and the ENG operations in the 2025-2110 MHz band.

SMCS will evolve over the period of performance (PoP) to address the following DoD systems, in order of priority:

• Tactical Radio Relay (TRR)

• Small Unmanned Aerial Systems (SUAS)

• High Resolution Video (HRV)

• Tactical Targeting Network Technology (TTNT)

In accordance with Defense Federal Acquisition Regulation Supplement (DFARS) Subpart 227.72, the Government will retain Unlimited Rights for all SMCS software, hardware and SMCS deliverables developed under this effort.

As a result, the Government may use, modify, release, reproduce, display or disclose any such software or deliverables created under this effort.

The Government may require surge support during the base or any option period, and surge modifications will be considered to be within the scope of the contract and will provide increased support for the defined task areas of this PWS. Surge support over the life of the contract will not exceed 10% 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. Details regarding the levels and types of support required will be further defined in subsequent modifications.

The initial operational release of SMCS will support the business process for coordinating DoD Tactical Radio Relay (TRR) operations with the ENG community, represented by the Society of Broadcast Engineers (SBE). The business process will likely evolve as DoD and the ENG community adapt to lessons learned while coordinating shared spectrum use.

A database of ENG and DoD operations (to include operational and technical characteristics of ENG and DoD systems), and business process transactions shall also be required for the initial operational release with data update capabilities provided to selected business process participants. The database shall also hold archival data and data at rest. The database shall support display/archive/export results and reports as defined by the requirements.

Beyond the initial version, additional Electromagnetic Compatibility (EMC) analysis capabilities shall be incorporated into SMCS to include, but not limited to Point-to-Point and composite path loss, and contours using available COTS and GOTS capabilities industry standard models. The data analysis requirements shall become more robust as they evolve to support more complex spectrum sharing when ground based and airborne DoD capabilities with larger bandwidth requirements transition their operations to the 2025-2110 MHz band. DoD systems currently plan to transition operations into the 2025-2110 MHz band which include TRR, Small Unmanned Aerial Systems (SUAS), High Resolution Video (HRV), and Tactical Targeting Network Technology (TTNT).

These analysis tools will need to be integrated with the database and automated workflow.

The Government anticipates future SMCS requirements to be driven by currently unknown user needs, and by the integration of advanced analytical algorithms and enhancements from other sources. An example could be the outcome of Spectrum Access Research and Development Program (SARDP) projects, that may provide improved reallocation and transition analysis techniques, to include DoD system enhancements. The contractor’s agile development methodology shall enable the Government to prioritize future SMCS enhancements.

6. Performance Requirements

6.1 Task 1 – Program Management (FFP) (Operations & Maintenance (O&M)): Program Management encompasses those activities necessary to effectively manage the SMCS development, operations, and sustainment effort.

The contractor shall provide a team of personnel with the capabilities to develop and maintain SMCS, and possess experience and working knowledge of spectrum engineering and requirements, including at a minimum: EMC Coexistence Algorithms, Electromagnetic Interference (EMI) interactions, EMI between and related to spectrum-dependent systems, Electromagnetic Propagation, Electromagnetic Environmental Effects, and DoD and SBE spectrum management concepts and principals to include frequency allocation and assignment/licensing.

6.1.1 Subtask 1.1 – Program Management Planning and Reporting: The contractor shall manage the technical, cost, schedule, performance, and risk parameters to meet requirements.

The contractor shall deliver a Program Management Plan (PMP) that addresses the following topics: cost and invoice management; staff management, to include key personnel management; stakeholder (including DoD and SBE stakeholders) communication and management; risk, issue and opportunity (RIO) management; action item tracking; and technical management of SMCS development, operations, and sustainment.

For understanding and planning purposes, the contractor’s list of Key Personnel shall include those personnel necessary to accomplish requirements and are capable of leading program activities. At a minimum, Key Personnel shall include a Program Manager (PM) and a Technical Lead (TL). Key Personnel shall be documented in the Program Management Plan, and the contractor shall notify the COR and Contracting Officer (KO) of any Key Personnel changes within three (3) business days. All changes in Key Personnel shall be approved by the COR.

Because this is an agile development effort and fluid in nature, the Government reserves the right to designate additional personnel as “key” throughout the life of the contract.

The PM shall be the single management interface to the Government, shall manage and coordinate the development of SMCS and apply an operational understanding of DoD spectrum management business processes, frequency assignment, and user equipment information to the development effort. The PM shall also serve as an interface with other vendors and stakeholders on programmatic matters.

The TL shall be the technical interface to the Government, to include other vendors and stakeholders for technical matters. Additionally, the TL shall be the subject matter expert for studies, shall manage the contractor’s expertise in spectrum operations (from planning through to execution), to include applying the concepts and principles of:

current and emerging DoD and National Association of Broadcasters / Society of Broadcast Engineers (NAB/SBE) spectrum management business processes; spectrum deconfliction engineering analysis; frequency assignments; and emerging spectrum technologies (e.g., spectrum-dependent systems and related management systems). The TL shall manage business process improvement practices to reengineer spectrum management and interference analysis methodologies/principles and business process modernization projects.

The contractor shall deliver a Monthly Activity and Status Report (MASR) that includes a summary of: recent accomplishments, status of ongoing technical activities, and future activities for all tasks/subtasks in the contract/ task order; the status and progress of costs (planned vs actual), invoicing, and financial status; complete Government Furnished Information/Government Furnished Equipment/Government Furnished Software/Government Furnished (GFI/GFE/GFS/GFx) artifacts GFI/GFE/GFS/GFx inventory; schedule status; technical performance; actions;

metrics; and risks. The contractor shall describe Agile development progress and status in each MASR. The contractor shall evaluate and present open RIOs in the MASR. For reporting purposes, metrics shall include:

Number of user stories selected for a time-boxed development increment (e.g., a development sprint), consistent with the contractor’s agile approach

Number of user stories completed during a time-boxed development increment, consistent with the contractor’s agile approach

Number of bugs discovered after a release Definition of work elements consistent with the contractor’s agile approach (e.g., story points or work hours)

a. Total work elements committed to a time-boxed development increment, consistent with the contractor’s agile approach

b. Total work elements completed in a time-boxed development increment, consistent with the contractor’s agile approach

c. Planned cost per work element for all work under cost-reimbursement CLINs

d. Actual cost per work element for all work under cost-reimbursement CLINs

The contractor shall provide monthly invoices, including detailed billing reports for all associated tasks and work completed each month. Monthly invoices shall mirror the contract POP dates based on award date and shall be submitted within thirty (30) days of the period (month) end. A FINAL INVOICE, capturing all outstanding expenses related to the correlating period of performance (POP), will be submitted within ninety (90) days of the completion of the POP (base year, option period, etc.) without exception. At a minimum, these reports shall include the number of labor hours charged per task and a list of any cost reimbursable purchases completed. Invoices shall be submitted to the Contracting Officer’s Representative (COR) for review and concurrence at least five (5) business days prior to submission into the required, automated system (currently: Procurement Integrated Enterprise Environment (PIEE), Wide Area Workflow (WAWF)).

The contractor shall manage RIOs for the program. The contractor shall evaluate and include open RIOs and any closed RIOs during the reporting period in the MASR. Those RIOs that require immediate Government attention shall be brought to the COR’s attention as soon as they are identified.

The contractor shall conduct a Kickoff Meeting within thirty (30) days of PoP start. This meeting shall fully address the technical requirements, the contractor’s plan and schedule for execution, management processes, agile development approach, and plan for the first shippable increment of the SMCS. The contractor shall present the integrated master schedule, and, after Government approval, establish the final schedule and performance baselines.

The contractor shall prepare and deliver Kickoff Meeting Materials and Kickoff Meeting Minutes in accordance with the delivery table for these CDRLs.

The contractor shall host Bi-weekly Status Reviews with the COR and DSO stakeholders. At each Bi-weekly Status Review, the contractor shall deliver a status presentation, and shall host (by providing meeting spaces and leading the discussions) and conduct a collaborative exchange among stakeholders. The Bi-weekly Status Review shall cover relevant topics, to include at a minimum: Agile backlog review, SMCS Development status, status updates of all technical activities, RIOs, future activities, technical issues, financial status, schedule status, actions, metrics, and any other topics of interest. These meetings will primarily be of a technical and programmatic nature, and shall be used to provide updates to and elicit requirements from stakeholders. The contractor shall use these opportunities to populate the SMCS product backlog. The contractor shall prepare and deliver Status Review Materials prior to each meeting and Status Meeting Minutes at the conclusion of each meeting.

For all in-person meetings and reviews, the contractor shall provide facilities capable of hosting meetings, and providing demonstrations, including software demonstrations (as appropriate). These facilities shall be within thirty

(30) linear miles of the DSO Annapolis facility. The contractor shall provide logistical coordination for meetings, to include at a minimum: scheduling rooms, enabling remote access to meetings, coordinating dates, inviting participants, developing and distributing agendas, maintaining action item lists, recording and distributing meeting minutes, conducting post meeting follow-up actions, etc. Remote access may include setting up Defense Collaboration Services, teleconference phone bridges, Wi-Fi/guest network access, web conferencing, etc.

6.1.2 Subtask 1.2: General Technical Support and Meetings: The contractor shall contribute to and/or host on average six (6) customer, technical and/or external stakeholder meetings per month, as directed by the COR. These meetings will primarily be of either a technical nature or programmatic update. Additionally, the contractor shall hold technical meetings in support of their proposed agile methodology. Meetings shall ensure that the stakeholder community, holistically, understands and contributes to key SMCS considerations, to include at a minimum: the current state of SMCS, required updates/changes to SMCS, timing of future releases, requests for information to/from stakeholders, and upcoming training events. The following table describes potential (but not all) meetings:

Potential Engagement Location Anticipated Number of Annual Occurrences

Meeting at the National Association of Broadcasters (NAB) Headquarters

Washington D.C. 12

Presentations to DSO Staff regarding technical and programmatic topics

Joint Spectrum Center, Annapolis

MD

Stakeholder Meetings DISA Headquarters, Ft. Meade MD 6

Participation in Technical discussions and/or process definition Table-Tops

McLean, VA 6

NAB Conference Las Vegas, NV 1

Periodic status meetings Joint Spectrum Center, Annapolis

MD

Technical and programmatic discussions with the office of the DoD Chief Information Officer

Crystal City, VA 2

Site visit for information gathering, training, or other purposes

TBD 3

Other technical and/or user group meeting As defined by PWS 33

Technical meetings will include problem-solving discussions, where the contractor’s SMCS and process experts will provide perspectives, elicit requirements and/or help stakeholders resolve issues. Programmatic review meetings will include informing external stakeholders and senior leaders of SMCS capabilities and status. During any technical support engagement, the contractor shall provide SMCS perspectives, deliver update information, and lead problem solving discussions. Support shall include the following types of engagement, at a minimum:

Integration, process, and technical discussions with ENG community representatives Verbal and written updates to DoD Chief Information Officer (CIO), DISA, and other senior leader representatives Integration and requirements planning with user groups Planning, Integration and technical problem resolution with SARDP representatives (leading to future capability integrations in SMCS) Updates, process, and technical discussions with the military services.

Meetings shall include technical exchanges with stakeholder user groups to evolve the SMCS business process, evolve the SMCS software requirements, and describe planned functionality for current and future SMCS releases.

Engagements with external stakeholders (to include user groups) shall be coordinated with and approved by the COR, to include all materials presented to external stakeholders prior to presentation. For each meeting, the contractor shall prepare and deliver Stakeholder Meeting Materials and Stakeholder Meeting Minutes.

6.1.3 Subtask 1.3: Project Data and Information: The contractor shall manage and retain a repository of all Project Data and Information. The contractor shall provide, as requested by the COR, relevant working Project Data and Information products created in the process of performing work during the period-of-performance. Such artifacts include at a minimum: documents, briefings communications, software scripts, software components, and software development artifacts that are produced in association with this effort. These artifacts are considered key for historical purposes, knowledge management, collaboration, and information sharing. Deliverables shall be provided in their native formats using a delivery mechanism agreed to by the COR.

6.1.4 Subtask 1.4: Equipment Management: The contractor shall maintain a GFI/GFE/GFS/GFx List and deliver it on a monthly basis. The GFI/GFE/GFS/GFx List shall document any equipment, information, or item that the Government provides to successfully execute the requirements of this effort. Each GFI/GFE/GFS/GFx request shall be coordinated with the COR.

CDRL

PWS

Task

Deliverable Title

Format Due Date Distribution/ Copies

Frequency and Remarks

A001 6.1.1 Program Management Plan

DI-MGMT-80347,

including additional content required by

PWS 6.1.1

MS-Word and/or Adobe PDF

Draft due five (5) days prior to Kickoff.

Final due five (5) business days after receipt of DSO comments

Standard Distribution*

One (1) Time

A002 6.1.1 Monthly Activity and Status Report

Government-provided format.

MS-Word and/or Adobe PDF, MS- Excel, MS-Project

NLT 15th calendar day of each month

Standard Distribution*

Monthly

PWS

Task

Deliverable Title

Format Due Date Distribution/ Copies

Frequency and Remarks

A003 6.1.1 Monthly Invoices

Contractor proposed, and COR approved format (PDF or MS- Word) and in WAWF

NLT 15th calendar day of each month

Standard Distribution*

Monthly

A004 6.1.1 Monthly Financial Tracking Summary

Government-provided format

NLT 15th calendar day of each month

Standard Distribution*

Monthly

A005 6.1.1 6.1.2 6.2.2

Meeting Minutes

Contractor proposed, and COR approved format

Kickoff Meeting: Kickoff meeting must be held within thirty (30) days of PoP start. Minutes due two (2) business days following meeting.

Status Meetings: Due two (2) business days following meeting Stakeholder Meetings:

Due two (2) business days following meeting

Standard Distribution*

Kickoff Meeting:

Once Status Meetings:

Once in every two-week period throughout the contract PoP Stakeholder Meetings: As requested by the

COR

ORR: For each release

A006 6.1.1 6.1.2 6.2.2

Meeting Materials

Contractor proposed, and COR approved format in accordance with requirements in the PWS

Kickoff Meeting: Kickoff meeting must be held within 30 days of PoP start; materials due two business days prior to meeting.

Status Meetings, Stakeholder Meetings, and ORRs: Agenda and materials due two business days prior to meeting

Standard

Kickoff Meeting:

Once Status Meetings:

One time in every two-week period throughout the contract period of performance Stakeholder Meetings: As requested by the

COR

ORR: For each release

A007 6.1.3 Project Data and Information

Contractor proposed, and COR approved format

Coordinated between COR and contractor at time of requirement

Standard Distribution*

As required by the

COR

A008 6.1.4 GFI/GFE/GF

S/GFx List

Contractor proposed, and COR approved format

NLT 15th calendar day of each month

Standard Distribution*

Monthly

* Standard Distribution: One (1) copy of the transmittal letter without the deliverable to the Contracting Officer (KO); One (1) copy of the transmittal letter with the deliverable to the Primary COR; One (1) copy of the deliverable to the Alternate COR; and One (1) copy posted to a site designated by the Government. The copy of the deliverable sent to the Primary and Alternate COR may be in electronic format if requested by the Government.

6.2 Task 2 – SMCS Development (CPFF) (RDT&E): The contractor shall develop, deploy, and continually enhance SMCS using industry standard agile development methodologies to:

Develop and deploy an initial operational release of SMCS that meets the specified requirements in the SMCS Initial Software Requirements Specification

Provide a construct for Government prioritization of continual SMCS enhancement

Capture user-generated requirements for continual SMCS enhancement Maintain a web-based SMCS system environment Continually deploy enhanced SMCS capabilities to meet evolving requirements Rapidly fix any bugs and rapidly deploy any requisite emergency releases Provide the appropriate level of information assurance and security, based on role-based access controls.

Integrate continuous security practices, including integrating vulnerability analyses

The contractor’s agile development methodology shall maximize the number of work elements (e.g., story points or work hours) that can be committed to and completed in a time-boxed development increment (e.g., sprint or release).

Furthermore, the Agile development approach shall maximize the number of enhancements, including but not limited to those identified in the SMCS Future Objectives List, that will be developed throughout the period of performance.

The contractor shall use open interface standards and apply modular, open systems architecture principles to SMCS development:

The contractor shall employ modular designs that are cohesive, encapsulated, self-contained, and highly binned. The contractor shall use broad modular definitions to enable commonality and reuse, and each module shall not constrain other modules.

The contractor shall develop and maintain an architecture that incorporates reconfigurability, portability, maintainability, technology insertion, vendor independence, reusability, scalability, interoperability, upgradability, and long-term supportability.

The architecture shall be layered, modular, and shall maximize the use of standards-based commercial off-the-shelf (COTS) components that all utilize either non-proprietary or non-vendor-unique interfaces, to include non-proprietary data formats.

The design approach shall result in a layered system design, maximizing software independence from any hardware.

The architectural approach shall ensure the rapid and affordable insertion and refreshment of technology through modular design, the use of open standards and open interfaces.

The contractor shall implement and report on interface metrics, in an Interface Metrics Report to include at a minimum:

a. Number of interfaces between major modules

b. Number of message types per interface

c. Message sizes on each interface

d. Number of message interchanges for use cases

SMCS shall be compliant with the Government’s SMCS Reference Architecture. The contractor shall use this GFI to guide the development of the initial operational release of SMCS. The initial operational release must support the operational construct defined by the SMCS Operational Requirements Document (ORD), and meet the software requirements of the SMCS Initial Software Requirements Specification (SRS). The SMCS Reference Architecture, ORD, and Initial SRS will be provided to the contractor as GFI. The initial SMCS operational release shall enable effective coordination between stakeholders and utilize a commercial web services framework.

Future operational releases of SMCS shall contain User-Based Coordination, Coexistence Analysis, and Database functionality. The contractor shall use the SMCS Future Objectives List (provided as GFI) to help form candidate requirements in future SMCS releases, and develop an SMCS development roadmap. Due to the transition timeline of systems entering the target band, the Government anticipates demand for SMCS development to decrease over the life of the SMCS effort. At a minimum, the contractor shall deliver operational releases, in accordance with the table below; however, the contractor is encouraged to deliver operational capability as frequently as possible in accordance with the proposed agile development methodology.

Base Year Option Year 1 Option Year 2 Option Year 3 Option Year 4 The contractor shall deliver at least two

(2) operational

The contractor shall deliver at least three

(3) operational

The contractor shall deliver at least two

(2) operational

The contractor shall deliver at least two

(2) operational

The contractor shall deliver at least one

(1) operational releases, including the initial operational capability releases releases releases release

The contractor shall provide a Software Development Plan (SDP) for the SMCS project that documents the comprehensive agile software development process, to include requirements analysis, coding, testing, deployment, documentation, problem analysis, and problem resolution. Additionally, the SDP shall address the software architecture, the requirements traceability processes, the process for managing and delivering emergency bug fixes (to include testing, validation, and deployment), the incorporation of agile methodologies, the maintenance of the Product Backlog (PB), and the defect identification and resolution processes.

The contractor shall provide a Configuration Management Plan (CMP) for the SMCS project. The CMP shall include, at a minimum, the identification and baseline of configuration items (CI) and the description of processes for controlling CIs (including configuration change control, configuration status accounting, configuration reviews, process overviews, and required evaluations). This CMP shall also address how software changes and additions are documented within the code to include relevant information, to include requirement source and/or reason for change.

The contractor shall provide a Master Test Plan (MTP) for the SMCS project. The MTP shall include details and processes for all test events required to ensure a high-quality SMCS product is developed, operated, and maintained.

This includes, but is not limited to, any automated regression testing, software testing, acceptance testing, and deployment testing that is required. The MTP shall also include the details of how Information Assurance activities are integrated into the testing process and into the test environment.

The contractor shall implement cybersecurity and information assurance practices within the SMCS development process, SMCS architecture, and software that protects SMCS information. The contractor shall ensure robust cybersecurity within SMCS releases, and ensure SMCS confidentiality, integrity, availability, authenticity, secure access control, survivability, and non-repudiation of information. The contractor shall integrate continuous security practices, including integrating vulnerability analyses. The contractor shall implement Role Based Access and Control within the SMCS architecture. The contractor shall document, update, and maintain an SMCS System Security Plan (SSP) that addresses how confidentiality, integrity, availability, authenticity, secure access control, survivability, and non-repudiation of information will be assured within SMCS and any associated activities.

Additionally, the contractor shall include security requirements, security architecture diagrams, threat models, and security architecture test cases, as appropriate within the SSP.

6.2.1 Subtask 2.1 – SMCS Requirements: The contractor shall lead requirements development and decomposition for SMCS capabilities and functionality. The contractor shall ensure that SMCS can perform its required functionality, as defined by Government Furnished requirements documents and by any other document that defines requirements created by the contractor in the course of contract execution. The contractor shall use the SMCS Initial Software Requirements Specification (provided as GFI) to determine the functionality required of the first deployable increment of SMCS.

The contractor shall maintain and deliver a Product Backlog (PB). The PB shall inform requirements activities and document SMCS features, defects, and enhancements. The PB shall include, but not be limited to, a prioritized list of everything that could be included as capabilities, features, and/or enhancements. Updates to the PB shall be made in conjunction with the Government’s priorities, as directed by the COR.

The contractor shall enhance the SMCS software throughout the PoP to meet the Government’s operational objectives. The contractor shall plan for continuous software development throughout the PoP, to meet these evolving needs. The Government anticipates the evolution of SMCS to include the requirements identified in the SMCS Future Objectives List (provided as GFI); these SMCS Future Objectives may be refined through the agile development process. Additional SMCS requirements are expected to emerge throughout the period of performance from stakeholders and the Government, to include the productization and integration of Government-furnished and contractor-acquired software, algorithms, and enhancements.

For all emerging requirements beyond the first deployable increment of SMCS, the contractor shall identify and execute all required architectural, software, and SMCS documentation changes (with associated cost and schedule estimates). The contractor shall make recommendations to the COR regarding available options to address emerging requirements. Additionally, the contractor shall populate the PB with features that result from documentation, meetings, and discussions with stakeholders. Any feature that is added to the PB shall include an estimated level-of-effort (LOE) associated with completing the feature, utilizing industry best practices for estimation. The contractor shall implement the changes to SMCS upon direction from the COR.

The first backlog delivery is due at the Kick-off Meeting for approval. To manage requirements, the contractor shall lead PB reviews (monthly, at a minimum) with the Government (including the COR), enabling the COR to approve features on the PB. To approve candidate features from the PB, the contractor shall lead discussions of the following feature characteristics: requirements, proposed design and architecture changes, estimated LOEs, dependencies, prototypes (when possible), sample user interfaces (when possible), and any other information needed to make an informed decision. The first backlog review will be held during the Kickoff Meeting, and at least monthly, thereafter.

6.2.2. Subtask 2.2 – Test and Deploy SMCS Releases. The contractor shall conduct testing to ensure the delivery of a high-quality product that meets all operational and performance requirements. Testing shall address performance (including metrics), quality, and security, and the contractor shall provide materials for all test events and follow the guidelines of the MTP.

The contractor shall develop Release Test Plans that are consistent with the testing approach defined in the MTP and Software Development Plan. Test plans shall cover all automated regression testing, software testing, acceptance testing, and operational deployment testing activities. The contractor shall maximize the use of automated regression testing throughout the PoP. The contractor shall create, update, and modify automated regression tests to satisfy testing requirements. All automated regression test supporting materials, including test scripts, harnesses, and documentation, shall be provided when regression tests are updated by the contractor. Test plans shall include test cases, scripts, data, and all information necessary to implement the automated and manual test cases.

The contractor shall conduct a Government Acceptance Test (GAT) event for each operational release, in accordance with the MTP. The GAT shall: validate that each SMCS release meets specified requirements, demonstrate that the software is suitable for deployment, and include a demonstration of a successful version build using the documented installation process. GAT participants shall include Government staff and other Government contractor staff, as requested by the COR. The COR will be responsible for approving the GAT. If a product defect is suspected or identified during the GAT, the contractor shall conduct appropriate defect analyses and resolution prior to release.

At the end of testing, the contractor shall conduct a hot wash session with all test participants to identify lessons learned, what needs fixing or improvement, what actions should be taken with respect to the release, and what should be repeated/included as part of future test events.

For each release, the contractor shall provide a consolidated Test Report that documents any discussions, lessons learned, action items, and action plans generated from testing and the hot wash session.

Prior to transitioning any release into operations, the contractor shall conduct an Operational Readiness Review (ORR) with the Government. The contractor shall present test results and evidence that the SMCS release is ready for deployment. Additionally, the contractor shall demonstrate that SMCS accounts, connectivity, and full capabilities have been successfully maintained (from previous SMCS operational releases) as a part of each ORR.

The COR will approve or deny each deployment based on testing results, and the ORR. To obtain COR approval, the contractor shall take required corrective actions identified during the ORR. The contractor shall provide ORR materials and ORR minutes in accordance with the delivery table for these CDRLs. For each software release, consistent with the proposed agile approach, the contractor shall provide the Government with a clear demonstration that the software meets architectural requirements and that the software code maintains high quality standards.

After approval from the COR, the contractor shall deploy SMCS releases. The contractor shall coordinate deployment timeframes with the COR to minimize disruptions to ongoing workflow. The contractor shall make new SMCS capabilities operational within five (5) business days of a successful ORR, and in accordance with the integrated project schedule. For deploying ad-hoc or emergency releases, the contractor shall work with the COR to establish timelines, and the contractor shall deploy any ad-hoc or emergency releases within the agreed upon schedule. During deployment of any release, the contractor shall ensure continuity of SMCS operations, including the ability to recover from any failures during deployment, and the ability to restore capabilities to the previous operational state. The contractor shall verify that each release has been correctly configured, successfully deployed, and is fully operational. Within one (1) business day of declaring successful operational status and completing the deployment, the contractor shall provide an SMCS Operational Capabilities Memo declaring a successful release deployment.