Attachment_1_-_PWS.docx

PERFORMANCE WORK STATEMENT (PWS)

as of 18 September

HC1047-16-D-0008 TO# HC104717F0082

1. Contracting Officer’s Representative (COR).

To Be incorporated into final award clause DARS 52.204-9000, Points of Contact (Aug 2005)

2. Task Order Title.

Advanced Wireless Services- 3 (AWS-3) Early Entry Portal (EEP) Development, Operations, and Maintenance Support

3. Background.

In March 2014, the Federal Communications Commission (FCC), in collaboration with the National Telecommunications and Information Administration (NTIA), developed rules for auction and reallocation of the 1695-1710 MHz and 1755-1780 MHz bands, which at the time, were allocated exclusively for Federal use. On July 18, 2014, the FCC and NTIA issued a joint Public Notice (PN) DA 14-1023, GN Docket #13-185. The PN provided: (i) information for potential bidders in the AWS-3 auction; and (ii) guidance to the ultimate AWS-3 licensees and the affected Federal incumbents regarding coordination between Federal and non-Federal for shared use of the 1695-1710 MHz and 1755-1780 MHz bands. On November 13, 2014, the FCC initiated the AWS-3 Auction (“Auction 97”). Auction 97 provided for new licenses in the 1695-1710 MHz, 1755-1780 MHz, and 2155-2180 MHz bands for AWS-3. Most of the federal systems using the 1755-1780 MHz band will relocate out of the band, but the FCC’s rules provide for indefinite sharing with a limited number of federal systems. The NTIA Commerce Spectrum Management Advisory Committee Working Groups 3, 4, and 5 established protection distances around Federal systems operating in the AWS-3 bands (1695-1710, 1755-1780, and 2155-2180 MHz) to ensure interference-free operation between Department of Defense (DoD) and commercial AWS systems as the AWS systems enter the bands. Initial DoD assessments indicated it would take several years for DoD systems to transition out of the band, and some assets would remain in a sharing arrangement indefinitely. The Services and the Defense Information Systems Agency (DISA) Defense Spectrum Organization (DSO) have developed transition plans for their respective organizations to facilitate increasingly less restrictive sharing arrangements for early entry of commercial AWS systems and permanent sharing between DoD and commercial systems operating in the 1755-1780 MHz band.

The DISA DSO Transition Plan includes six tasks: DISA1: 1755-1780 MHz Early Entry Portal (hereafter referred to as the AWS-3 EEP); DISA2: 1755-1780 MHz Federal Spectrum Management System (FSMS) 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 (SST&D) Program; and DISA6: DoD Spectrum Relocation Management Team (DSRMT). DISA6 covers the DSRMT Government reimbursable billets to be funded through AWS-3 auction proceeds. The DSRMT will oversee DSO activities being conducted under the DISA Transition Plan, including oversight of contracted work.

The AWS-3 EEP is a custom-coded SharePoint .NET web application using the SharePoint data object model. It requires an underlying SharePoint instance and SQL server for storing SharePoint configuration, content, and user/role data. The AWS-3 EEP currently resides within a third-party data center and is accessible via the open internet to authorized users. The Initial Operating Capability (IOC) of the AWS-3 EEP focused primarily on an information exchange mechanism supporting a workflow for processing commercial AWS-3 provider coordination requests (CRs), in accordance with the Joint FCC and NTIA Public Notice on Coordination Procedures in the 1695-1710 MHz and 1755-1780 MHz Bands: July 18, 2014 , with the DoD, Department of Justice (DOJ) and Department of the Interior (DOI). The Full Operating Capability (FOC) of the AWS-3 EEP included automation of the Satellite Operations (SATOPS) Streamlined Coordination process with the DoD, AWS-3 licensee responses to the DoD results letter, and processes associated with AWS-3 licensee’s coordination with DoD after initial results of CR assessments are provided to the AWS-3 licensees (referred to as “Post-60 day Discussions”). The DoD, DOJ, and DOI have analytical capabilities to assess CRs that are manually downloaded from the AWS-3 EEP (there is no machine-to-machine interface between these analytical capabilities and the AWS-3 EEP).

4. Objectives.

The objective of this effort is to provide for continued EEP development, operations and maintenance.

5. Scope.

The Government is in need of transition, deployment, continuing development, operations, maintenance, and enhancement tasks for EEP, as defined in this PWS. The contractor shall provide all corrective maintenance, system user support, software development, system (and software) documentation, system/software operations, and maintenance services required by EEP as outlined in Section 6, titled Performance Requirements.

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

6. Performance Requirements.

6.1. Task 1. - Task Order Management (FFP)(O&M). The Contractor shall utilize industry best practices for project management and agile product development to ensure on-time and on-budget delivery of quality, customer driven products. Examples of acceptable best practices include the Project Management Institute’s (PMI) Project Management Body of Knowledge (PMBOK® Guide), IT Information Library (ITIL), SEI Capability Maturity Models (software and integration), and the Scaled Agile Framework (SAFe).

6.1.1. Subtask 1.1. - Task Order Management Planning and Reporting. The contractor shall deliver effective task order management that accounts for technical approach, cost, schedule, performance parameters, and management controls employed to meet the requirements throughout task order execution. The contractor shall develop a Task Order Management Plan (TOMP) that addresses relevant aspects of managing the task order, such as:

· Product Oriented Work Breakdown Structure (WBS), aligned to the scope and deliverables of the TO

· Integrated Master Schedule structured by the Government approved WBS and logically connected with predecessor and successor relationships

· Cost

· Staffing

· Stakeholder Communications

· Risk and Opportunity Management. Approach, Assessment, Mitigation, Integration and Reporting for management and technical risks

· Action Item Tracking

· Task Order Requirements

· Technical Management

· Product Requirements

· Product Design and Development

· Product Development and Testing

· Product Deployment, Engagement and Training

· Product Operations, Support and Maintenance

· Quality Assurance/Quality Control, Configuration Management, Performance Management, Technical Risk Management The Contractor shall deliver a Monthly Status Report on task order progress that includes recent activities, future activities, the status and progress of costs, schedule and technical performance, risks and issues. The Contractor shall summarize risks and issues in the monthly report. Those that require immediate government attention shall be, at a minimum, discussed during the monthly status meeting or brought to the COR’s attention, as needed.

Deliverable(s):

a) Initial Task Order Management Plan (TOMP) and Updates (addresses management of the following: requirements, schedule, cost, quality control, staffing, communications, risk, and procurement)

b) Monthly Status Report that addresses

· Planned vs Actual Financial Reports

· Invoices and invoice status

· Schedule status

· Attached Integrated and Baselined MS Project.mpp file and Updates

6.1.2. Subtask 1.2. – Task Order Status Meetings and Reports. The contractor shall prepare and conduct a kick off meeting within forty-five (45) days of contract award to establish a common understanding of task order requirements, schedule details and expectations. This kick-off meeting shall fully address the software development process, at a minimum: the implementation of agile development, the requirements approval process, the release roadmap, the use and pace of sprints (including completion criteria), the definition of a minimum shippable increment, and the product backlog review process. The contractor shall present the integrated master schedule and, after Government approval, establish the schedule baseline. The contractor shall prepare kick-off meeting materials and kick-off meeting minutes.

The contractor shall prepare and conduct Monthly Management Status Reviews. At Monthly Management Status Reviews, the Contractor shall prepare and discuss with the Government the status of technical activities, the EEP product backlog, risks, task order financial status of planned versus actuals costs (monthly and cumulative) by Task and by WBS for Cost-Plus Tasks. The Contractor shall also discuss schedule status, issues, get well plans, and any task order related topics (e.g. procurement, security, invoices) that require Government attention. The Monthly Management Status Review will coincide with the submission of the monthly status report. The contractor shall furnish materials to support these discussions, and the contractor shall provide minutes following every Monthly Management Status Review meeting.

The Contractor shall contribute to and/or host a maximum of 6 ad hoc customer and/or external stakeholder meetings per year as directed by the Contracting Officer’s Representative (COR). These meetings will primarily be of a technical nature, such as a deep dive, where EEP experts will provide EEP-centric perspectives and/or helping other stakeholders resolve issues. The contractor shall furnish materials to support these discussions, and the contractor shall provide minutes following any ad hoc meeting.

The contractor shall participate in bi-weekly EEP Working Group meetings, led by a third party. During these meetings, the contractor shall provide EEP development perspectives and support analyses and discussions when relevant topics are discussed. Potential EEP features that are discussed during EEP Working Groups shall be added to the product backlog for DSO consideration. Each meeting is expected to last no more than two hours, and the contractor may support these meetings via virtual means; e.g., by video or teleconference.

For all meetings and reviews, the contractor shall provide facilities capable of hosting meetings and providing demonstrations, when necessary. These facilities shall be within forty (40) linear miles of the DSO Annapolis facility. The contractor shall provide logistical support for these meetings, to include scheduling rooms, enabling remote access to meetings, coordinating dates, inviting participants, developing and distributing agendas, maintaining action item lists, recording and distributing minutes, conducting post meeting follow-up actions, etc. Remote access may include setting up Defense Collaboration Services, teleconference phone bridges, WiFi/guest network access, web conferencing, etc.

Deliverable(s):

a) Kick-off Meeting Materials and Minutes

b) Monthly Management Status Review Agenda, Materials and Minutes

c) Ad Hoc Meeting Agenda, Materials and Minutes

6.1.3. Subtask 1.3. - Project Data and Information Support. The Contractor shall provide, as requested by the COR, relevant working project data and information created in the process of performing work during the period of performance. Such artifacts are considered key for historical purposes, knowledge management, collaboration, and information sharing purposes. Materials created or in existence as a result of task order activities will not cause undue burden on the Contractor to provide or upload to a portal or SharePoint as directed by the COR. These may include (but exclude non-transferable commercial licenses):

· Artifacts and data generated during the software development and update process (e.g., build instructions, software development tool compiler settings and configuration settings, test scripts, and test harnesses). These are working products created by the contractor to perform software development that are outside of the formal deliverables specified in other tasks of this task order.

· Working products created in the execution of the tasks under this task order, at a minimum: information, documents, data, manuals, license information, standard operating procedures, and software.

· Email correspondence

· Presentations, spreadsheets, research, papers created in the process of performing a task or producing a deliverable During the closeout process and within sixty (60) calendar days prior to the final day the period of performance, the Contractor shall produce a draft list of TO closeout items that shall be turned over/transferred to the Government. The list shall include, but not be limited to, the following: all required incumbent equipment inventory (GFE only); TO deliverables; and all required software (e.g., the TDP, a virtual machine of the production EEP, EEP production database snapshot, configuration settings, portal case information including status, data, etc.). The Contractor shall review the draft list with the Government and provide an update, if needed.

The Contractor shall deliver TO closeout items to the Government on a date agreed upon by both parties within 30 calendar days of the final day of performance.

Deliverables shall be provided in their native formats using a delivery mechanism agreed to by the COR.

Deliverable(s):

a) Project Data and Information

b) TO Closeout Items List (Draft and Final)

c) Delivery of TO Closeout Items

6.1.4. Subtask 1.4. – Handling of Non-Public Information. In performance of this contract, the contractor and its employees may have access to DoD information and Contract Sensitive/Proprietary information of the AWS-3 Licensee companies. The contractor agrees to:

A. Use and protect such information from unauthorized disclosure in accordance with (IAW) DoD Instruction 8582.01, Security of Unclassified DoD Information on Non-DoD Information Systems.

B. Use and disclose such information only for the purpose of performing this contract and to not use or disclose such information for any personal or other commercial purpose.

C. Comply with other current Federal and DoD information protection and reporting requirements for specified categories of information (e.g., medical, proprietary, critical program information (CPI), personally identifiable information (PII), or export controlled information).

D. Obtain permission of the Government Requiring Activity before disclosing/discussing such information with a third party.

E. Return and/or electronically purge, upon Government request, any DoD or AWS-3 Licensee company information no longer required for contractor performance.

F. Advise the Contracting Officer and/or Contracting Officer’s Representatives of any unauthorized release of such information.

All contractor staff and staff with access to information submitted by AWS-3 Licensees shall execute an AWS-3 non-disclosure agreement (NDA) within five (5) days of award and/or prior to accessing such information. The Government will provide an NDA template as Government Furnished Equipment/Information (GFE/I).

Deliverables:

a) AWS-3 NDAs

6.2. Task 2. – EEP Transition and Deployment.

6.2.1. Subtask 2.1. – Initial EEP Transition and Deployment (BASE PERIOD OF PERFORMANCE ONLY)(FFP)(RDT&E). The contractor shall transition the EEP from a privately hosted, legacy environment to an approved privately hosted environment located at the contractor’s facility. The contractor shall coordinate all transition/deployment activities with the DSO and the legacy environment owner throughout the transition of the EEP. The contractor shall ensure successful operational status following deployment to the new environment.

The contractor shall provide all infrastructure, hardware and any other product or service required to successfully transition the EEP.

The contractor shall develop an EEP Transition and Deployment Plan (ETDP) for migrating the existing EEP infrastructure from the current environment to a privately hosted environment provided by the contractor. The contractor shall provide a first draft of the ETDP fifteen (15) business days after contract award. Upon receipt of any DSO feedback, the contractor shall have ten (10) business days to provide an updated plan based on comments provided by the Government. The contractor shall conduct a formal review of the ETDP and associated test plans as part of the contract kick-off meeting, in accordance with Subtask 1.2.

The ETDP shall include the following:

A. A schedule of transition and deployment activities, milestones, and timelines, including identification of the critical path.

B. Identification of dependencies for transition and deployment, including dependencies on the DSO and incumbent vendor.

C. Identification of transition and deployment risks and opportunities, with appropriate mitigation and handling plans.

D. Identification of the responsible organization and a clear delineation of responsibilities for each activity required for successful transition and deployment including:

a. Physical transfer of EEP and associated artifacts.

b. Security control responsibilities.

E. Transition and deployment cost estimates, cost breakdowns, and cost information.

F. EEP deployment plan, including the complete processes for:

a. Hardware procurement.

b. Software Deployment.

c. Maintaining security boundaries, including a virtual private cloud or required logical network zones, as appropriate.

G. Checklist of activities, associated artifacts, and identification of organizations responsible for each activity to execute transition and deployment.

H. Full details of the privately hosted environment.

I. Identification of EEP artifacts that require updating as a result of the transition and deployment.

J. Overarching test strategy and associated test plan(s) for the EEP Deployment, including an operational checkout that verifies full EEP functionality.

K. Specific items to be addressed during the Operational Readiness Review (ORR).

L. A transition-in plan that includes strategies for the migration of support and addresses:

a. Implementation of supervisory and program functions.

b. The process for transitioning predecessor employees, if any.

c. The process for submitting new applications for personnel clearances, etc.

The contractor shall execute a smooth and orderly transition with the predecessor contractor to assure minimum disruption to vital contractor services and Government activities.

The contractor shall deploy and make operational the most current version of EEP, provided as Government Furnished Software (GFS). The contractor shall make required modifications to the EEP to enable deployment to the contractor’s approved privately hosted environment, in accordance with the ETDP. The contractor shall utilize contractor-supplied networking solutions and infrastructure. The provided infrastructure shall protect For Official Use Only (FOUO) information and the AWS-3 Licensees’ competition sensitive data from potential compromise.

The contractor shall begin the deployment of the EEP on a Friday, no earlier than 5pm (Eastern Time), and the specific date will be approved by DSO. This shall include a full domain transfer of 1755eep.com. The system shall be fully tested and ORR completed NLT 4PM (Eastern Time), on the sixth following business day (i.e., second Monday), and the system shall not be taken offline for more than five (5) business days. The system shall be operational, including any transfers of domain name ownership, by the start of the seventh business day (i.e., second Tuesday NLT 9am Eastern Time). Operational status, with full EEP functionality, must be declared within sixty (60) days of contract award.

The contractor shall perform deployment testing of the EEP to ensure a high-quality product is deployed with full functionality. The contractor shall document test plans within the ETDP. The contractor shall integrate the use of the current EEP Operations and Maintenance vendor into the test plan as a test observer and subject matter expert (SME) consultant during testing. Additionally, the contractor shall include Government staff and other staff, as requested by the COR, as test participants. The DSO will provide the services of the current EEP Operations and Maintenance (O&M) contractor at no cost. The contractor’s plan shall include a hotwash session with all the participants at the end of the test event.

The contractor shall test the initial deployment in accordance with the approved test plan. The contractor shall record all defects found during testing in the PB in accordance with Subtask 3.1. The contractor shall develop a deployment test report for DSO review and approval. The test report shall document hotwash discussions, test results, lessons learned, action items, and an action plan.

The contractor shall conduct an ORR for the EEP deployment and present the results prior to making EEP operational. The contractor shall prepare ORR materials and deliver ORR minutes no later than two (2) business days after the ORR. During the ORR, the contractor shall demonstrate that full EEP functionality has been preserved and deployed, and the contractor shall ensure that existing EEP accounts have been successfully ported. The DSRMT will approve or deny operational status based on testing results and the ORR. To obtain DSRMT approval, the contractor shall take required corrective actions identified during the ORR. Within one (1) business day of declaring operational status and completing the deployment, the contractor shall provide an EEP Deployment Memo declaring a successfully completed deployment. The contractor shall update any artifacts identified in the ETDP within thirty (30) days of successful deployment.

Deliverable(s):

a) EEP Transition and Deployment Plan, including Transition and Deployment Test Plan and Transition-in Plan

b) EEP Deployment ORR Checklist and Materials

c) EEP Deployment ORR Minutes

d) EEP Deployment Test Report

e) EEP Deployment Memo

6.2.2. Subtask 2.2. - Transition-Out of Contract and Continuity of Services (OPTIONAL CLIN)(FFP)(RDT&E). Upon the exercise of this option, the Contractor shall affect an orderly and efficient transition to a succeeding vendor. A draft Transition-Out Plan is due ninety (90) calendar days prior to contract end date, with final version due sixty (60) calendar days prior to contract end date. The Contractor shall provide a list with the total number and names of employees performing on the Contract, outlining any applicable suitability and certifications expiration dates in preparation of a new solicitation for follow-on services, upon request by the Contracting Officer.

The Contractor shall disclose personnel records, sufficient to allow the succeeding Contractor to conduct interviews for possible employment/transition (only if the Contractor is not awarded the successor Contract). These records shall be provided to the successor at least sixty (60) days prior to date of Contract expiration. If any incumbent employees desire to transition and are selected by the successor, the current Contractor should cooperate by granting release of those employees on a mutually agreed upon date.

During the closeout process and within sixty (60) days of final day of performance, the Contractor shall turn over all required incumbent equipment inventory, deliverables, training certificates, deployment test plans, deployment test reports, deployment test scripts, suitability information and security records to the successor. The contractor shall transfer all EEP hardware, software, and technical data to the successor contractor, participate in that successor contractor's initial deployment testing, and provide subject matter expertise to enable a successor contractor's successful transition. A failure to do so shall result in 25% withholding of final payment until completed.

Deliverable(s):

a) Transition-Out Plan

6.2.3. Subtask 2.3. – Transition Support to NTIA-Defined Infrastructure – (OPTIONAL CLIN)(CPFF)(RDT&E). When this option is exercised, the contractor shall support a smooth and orderly transition of the EEP to an infrastructure defined by the National Telecommunications and Information Administration (NTIA) Frequency Authorization Management Program (FAMP). This could include support a transition away from the contractor’s environment to a commercial cloud provider. The transition support will assure minimum disruption to vital services and Government activities. The contractor shall coordinate with the Government and other stakeholders to provide an NTIA Transition and Deployment Support Plan. This plan shall highlight all actions, activities, risks, and dependencies associated with supporting the migration to an NTIA-defined infrastructure The contractor shall execute to the NTIA Transition and Deployment Support Plan within a timeline that is defined by the DSO and update any EEP artifacts, as required. The contractor shall support deployment and transition testing to ensure a high-quality, error free migration in accordance with the approved NTIA Transition and Deployment Support Plan. The contractor shall interface with NTIA, third-party vendors, such as Cloud Brokers, and other stakeholders in order to maintain situational awareness and effectively support the complete transition process. In any instance where the contractor is interfacing with NTIA, the COR shall be involved in all communications.

The contractor shall help ensure the migrated EEP is synched, and the contractor shall help troubleshoot, as necessary, throughout the transition and deployment process.

Deliverable(s):

a) NTIA Transition and Deployment Support Plan

6.3. Task 3 – EEP Software Development (CPFF)(RDT&E). The contractor shall develop and deliver new releases of EEP, based on approved requirements and features. The contractor shall develop and deliver one major release and one minor release per year (aligned with the task order’s period-of-performance) for the base year and the first option year. For second and third option years, the contractor shall plan on two minor releases.

Major releases shall consist of significant changes in functionality, including adding or changing business process workflows or data models. Minor releases shall focus on user interface/appearance alterations and background changes (i.e. code refactoring) that do not impact workflows or data models. For minor releases, processes and procedures may be abridged with DSO approval and tailored to meet specific needs of the release. For each release, the contractor shall lead all activities from initial requirements analysis through deployment, and the contractor shall coordinate with the DSO throughout the development and deployment process. Releases are considered complete when capability has been delivered in accordance with requirements.

The contractor shall use agile methodologies to the greatest extent possible, enabling the Government to rapidly prioritize and reprioritize software requirements and features. The contractor shall use agile software development best practices and integrate agile methodologies into software releases. The contractor shall manage agile development processes, requiring minimal input and direction from the DSO. The contractor shall plan software development requirements well in advance, maintaining a robust and populated PB, in accordance with Subtask 3.1. The contractor shall implement Atlassian Jira or an equivalent tool to manage the agile development and deficiency tracking processes.

All development will comply with the provisions of Section 18 in addition to any other provisions given in this PWS.

The contractor shall conduct reviews for each release. The contractor shall conduct requirements reviews, either by agile increment or by capability, assuring DSO acceptance of pre-build requirements. The contractor shall also lead Test Readiness Reviews (TRRs), test events, Operational Readiness Reviews (ORRs), and deployments for each release. All software deliveries shall be reflected in the WBS baselines and project schedules.

The contractor shall manage and document the EEP architectural baseline. The contractor shall define the system architecture but consult with the DSO on any changes. Any hardware architecture changes must be specifically approved by the DSO. The architecture, including hardware, software, and network protocols, shall optimize system performance and reduce system costs to the greatest extent possible.

The contractor shall procure software licenses that are required to develop and maintain EEP. Any license purchase shall be approved by the DSO.

6.3.1. Subtask 3.1. – Develop and Manage EEP Requirements. The contractor shall lead requirements development for new EEP capabilities and functionalities. The contractor shall ensure that EEP can perform its documented functions, and the contractor shall lead activities to enhance the software’s functionality or user experience.

The contractor shall create, update, maintain, and provide version-control for software development artifacts throughout the software development lifecycle. The contractor shall provide the following software development artifacts:

A. Software Design Document (SDD) – The SDD shall describe software architecture, database schemas, class and interface abstractions, design patterns, APIs, and any other relevant design considerations. The SDD shall include detailed graphical representations of logic and custom code that is used to implement the EEP workflows. An initial version will be provided as GFI; however, the contractor shall update and modify this GFI to meet the needs of this effort no more than thirty (30) days following the successful EEP initial deployment.

B. Software Development Plan (SDP) – The SDP shall document the full software development process, to include requirements analysis, coding, testing, deployment, documentation, and problem analysis. 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 PB, and the defect identification and resolution processes. The SDP shall address all aspects of EEP software maintenance and operations, in accordance with Task 4. A draft SDP shall be provided with the contractor’s proposal. The COR has ten (10) business days after contract award to provide an acceptance or feedback of the draft submitted as part of the proposal. If no written acceptance is received within the ten (10) business days, then the contractor can consider the plan accepted. The contractor shall deliver a revised SDP, accounting for the COR’s feedback, no more than twenty (20) business days after contract award. Upon receipt of additional feedback to the revised SDP, the contractor has five (5) business days to provide the COR an update.

C. System Requirements Specification (SyRS) – The SyRS shall specify the approved requiremsnts for the EEP System, including software, and document the technical requirements that have been derived from user requirements. The SyRs shall specifiy the approved requirements for EEP and document the following: configuration items, capability requirements, interface requirements, adaptation requirements, security and privacy requirements, computer resource requirements, software quality factors, and design constraints. The SyRS shall include verification methods for verifying each requirement. An initial version will be provided as GFI; however, the contractor shall update and modify this GFI to meet the needs of this effort as part of the first software release. The contractor shall maintain requirements that are docu-mented within the GFI version, and the contractor shall ensure that EEP meets the System Requirements Specifica-tion. The initial SyRS is due with first software delivery and the final version is due five (5) business days after receipt of Government comments. Updates are required for each software release.

D. Product Backlog (PB) – The PB will inform requirements activities and document EEP features, defects, and enhancements. The PB will include, but not be limited to, a prioritized list of everything that could be included as EEP capabilities, features, and/or enhancements. Updates to the PB will be made in conjunction with DSO priorities. The PB shall also define software requirements that have been approved for development by the DSO and describe functional requirements, non-functional requirements, and use cases for those approved requirements. The PB shall estimate levels-of-effort associated with each entry, utilizing industry best practices. The PB shall also track defects within EEP. The contractor shall include labels and keywords to describe backlog entries (e.g., defect, enhancement, or new feature), enabling the Government to query, sort, and filter the PB. A PB will be provided as GFI, and the contractor shall ensure that features within the GFI version are included in the initial PB delivery on this effort. First backlog delivery is due at the kick-off meeting for approval. Comments must be addressed and a new version delivered five (5) business days after Kick-Off meeting. Populated backlog is due twenty-four (24) hours prior to each backlog review. The first backlog review will be at the Kick-off meeting, and monthly, thereafter.

E. Requirements Traceability Matrix (RTM) – The RTM will successfully demonstrate associations between work products, requirements, and test/verification events. An initial version will be provided as GFI; however, the contractor shall update and modify this GFI to meet the needs of this effort no more than thirty (30) days following the successful EEP initial deployment. Final due five (5) business days after receipt of Government comments. Updates due with each software release.

F. Configuration Management Plan (CMP) – The CMP will include, but not be limited to, 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). The CMP shall also address maintenance processes and establish configuration management methodologies that ensure correct products are released in each deployment. Initial version is due thirty (30) calendar days after contract award. Updates are required with each major release. For the second and third option years, the contractor shall review the CMP along with the final minor release of the option period.

G. Government Furnished Equipment/Information (GFE/I) List – The GFE/I List will keep an updated list of any equipment, information, or item that the Government must provide for the contractor to successfully execute the PWS. All GFE/I requests must be coordinated with the DSO. Initial version is due with first major software release and on 2nd Monday of every month, thereafter. Additionally, updates are due with each software release.

H. EEP System Architecture -- The EEP System Architecture will include, but not be limited to, a full depiction of the deployed EEP architecture, including software, hardware, interfaces and dependencies. Additionally, the architecture should document characteristics that have implications beyond the software itself (e.g., hardware implications/changes, network protocols and exchanges, or software licenses). Additionally, the systems architecture shall include diagrams that show the flow of how decisions at the architecture level affect software design, including code comments. Architecture changes shall be approved by the Government, optimize system performance and reduce procurement and maintenance costs to the greatest extent possible. An initial version will be provided as GFI; however, the contractor shall update and modify this GFI to meet the needs of this effort no more than thirty (30) days following the successful EEP initial deployment. Updates due with each software release.

I. Master Test Plan (MTP) – The MTP will include details and processes for all test events required for EEP development, operations and maintenance. The MTP shall include the details of how Information Assurance activities are integrated into the testing process and into the test environment. Initial version is due thirty (30) calendar days after contract award. Final version is due five (5) days after receipt of Government comments. Updates are required with each major release. For the second and third option years, the contractor shall review the MTP along with the final minor release of the option period.

J. System Metrics Document (SMD) – The SMD shall include details of the performance footprint (e.g., memory, or CPU use) including tested values for typical use and maximum use. Draft is due thirty (30) calendar days after contract award; Final version is due five (5) business days after receipt of Government comments. Updates are required for each software release.

Throughout the period-of-performance, the contractor shall populate the PB with architecture and design features that result from meetings and discussions with the DSO and with EEP stakeholders, in accordance with Task 1. Any feature that is added to the PB shall include an estimated level-of-effort associated with completing the feature, utilizing industry best practices for estimation. As DSO works with the EEP user community, new EEP feature requirements are expected to emerge. The contractor shall evaluate such emerging requirements and identify any required architectural and software changes (with associated cost and schedule estimates). The contractor shall make recommendations to the DSO regarding options to address emerging requirements and implement the changes to EEP upon direction from DSO. The following new requirements may be added to EEP and shall be considered within the initial product backlog:

· Universal Browser Compatibility – The contractor shall determine the necessary EPP modifications and ensure EEP supports use from the following identified browsers: Microsoft Internet Explorer, Google Chrome, and Mozilla Firefox. Successful completion will ensure compatibility with the latest major release version of each browser, as well as backward compatibility to the previous major release of the browsers.

· 508 Compliance – The contractor shall evaluate EEP for compliance with Section 508 of the Rehabilitation Act of 1973, as amended in 1998 (29 U.S.C. §794(d)) and modify EEP, to achieve full compliance. 508 compliance will conform to the requirements identified in Section 15 of this PWS.

· Satellite Coordination Agreement Documents – The contractor shall modify EEP to remind users to attach required documents, as described in the Public Notice, to Satellite Coordination Agreements and SATOPS Deployment Plans. The contractor shall ensure that EEP allows additional files to be attached to Satellite Coordination Agreement and Deployment Plan cases within EEP.

· For each initial SATOPS CA submission, licensees are required to upload a signed coordination agreement in .pdf format, using the template provided in the Joint Public Notice. Additional supporting documentation may also be uploaded, and the contractor shall ensure that EEP can support the upload of any additional documentation.

· Licensees can upload Deployment Plans that include technical characteristics for the base stations and associated mobile units relevant to the operation with the protection zone. These Deployment Plans contain the same content and format as the coordination request and follow a similar workflow. Deployment Plans should be associated with the appropriate Coordination Agreement, by license. The contractor shall ensure that EEP supports uploading additional supporting documentation to Deployment Plans.

To manage requirements, the contractor shall lead PB reviews with the DSO, enabling the DSO to approve features on the PB. Backlog reviews shall occur monthly, and backlog review materials shall be provided at least twenty-four (24) hours prior to any review.

For all new features approved from the PB, the contractor shall perform requirements analysis and determine the proper methodology to ensure successful implementation. Approved requirements will be documented as such in the PB. The contractor shall also identify any required Government Furnished Equipment and Information (GFE/I) needed. The contractor shall maintain the GFE/I list and present any new GFE/I dependencies to the DSO.

The contractor shall perform formal requirements reviews for each new functionality that is approved from the PB. Requirements reviews shall give the DSO the ability to approve the further development of features. Requirement reviews shall include discussions of the following feature characteristics: functional requirements, performance requirements, proposed design changes, proposed architecture changes, estimated levels-of-effort, required work products and documents, dependencies, prototypes (when possible), sample user interfaces (when possible), and any other information needed to make an informed decision. Requirements reviews may be executed concurrently with other meetings, such as backlog reviews and customer status meetings, when appropriate. The contractor shall produce requirements review materials prior to any review and meeting minutes following any review.

Deliverable(s):

a) Software Design Document

b) Software Development Plan

c) System Requirements Specification

d) Product Backlog

e) Requirements Traceability Matrix

f) Configuration Management Plan

g) Government Furnished Equipment/Information (GFE/I) List

h) EEP System Architecture

i) Master Test Plan

j) System Metrics Document

k) Requirement Review Materials

l) Requirement Review Minutes

6.3.2. Subtask 3.2. – Test and Deploy EEP Releases. The contractor shall ensure the delivery of a high-quality product that meets all operational and performance requirements. All testing and verification activities must be traceable to the defined requirements listed in the SyRS, PB, RTM, and approved requirements review materials. Testing shall address performance (including metrics), quality, and security, and the contractor shall provide test event materials for all test events. The contractor’s master test plan shall include an appropriate testing philosophy and infrastructure that ensures the operational system can continue functioning during test activities, to the greatest extent possible. The test environment for each test event shall be appropriate to accomplish test objectives and minimize operational disruptions.

The contractor shall develop test plans for each release. Test plans shall cover all automated regression testing, software testing, acceptance testing, and operational deployment testing activities. The contractor’s plan shall include a hotwash session with all test participants at the end of testing. The hotwash will be used to identify what was learned, what needs fixing or improving, what actions should be taken with respect to the release, and what should be repeated/included as part of future test events.

The contractor shall prepare a Test Readiness Review (TRR) Checklist and conduct a formal TRR with the DSO for each release. The TRR shall demonstrate that the contractor has completed all required predecessor activities and is ready to begin testing. The TRR shall provide an overview of each release’s test activities, and an approved TRR will authorize the contractor to conduct the release’s formal test events. The contractor shall furnish materials and minutes for each TRR.

The contractor shall maximize the use of automated regression testing throughout the period-of-performance. Automated regression tests and test harnesses will be provided as GFE; however, the contractor shall update, modify, and create automated regression tests, as necessary, to satisfy testing requirements, in accordance with the Master Test Plan. All automated regression test supporting materials, including test scripts, harnesses, and documentation, shall be provided when regression tests are updated by the contractor.

The contractor shall conduct a Government Acceptance Test (GAT) event for each EEP release in accordance with the MTP. The GAT shall validate that each EEP 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 Government, or its delegate, 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.

For each release, the contractor shall provide a consolidated Test Report. The contractor shall record all defects found during testing in the PB, in accordance with Subtask 3.1. The test report shall also document any discussions, lessons learned, action items, and action plans generated from testing and the hotwash.

The contractor shall conduct an Operational Readiness Review (ORR) with the Government. The contractor shall present test results and evidence that the EEP release is ready for deployment. Additionally, the contractor shall demonstrate that EEP accounts, connectivity, and full capabilities have been successfully maintained as a part of each ORR. The DSRMT will approve or deny each deployment based on testing results and the ORR. To obtain DSRMT approval, the contractor shall take required corrective actions identified during the ORR. The contractor shall provide materials and minutes for each ORR.

The contractor shall coordinate deployment timeframes with the Government to minimize disruptions to ongoing workflow. The contractor shall make new EEP capabilities operational within five (5) calendar days of a successful ORR and in accordance with the integrated project schedule. For deploying ad hoc releases, the contractor shall work with the DSO to establish timelines, and the contractor shall deploy any ad hoc releases within the agreed upon schedule. During deployment of any release, the contractor shall ensure continuity of EEP 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 EEP 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 EEP Operational Capabilities Memo declaring a successful release deployment.

Deliverable(s):

a) Release Test Plans

b) TRR Checklist and Materials

c) TRR Minutes

d) Automated Regression Test Materials

e) Test Materials

f) Test Report

g) ORR Checklist and Materials

h) ORR Minutes

i) EEP Operational Capabilities Memo

6.3.3. Subtask 3.3. – Develop and Document EEP Releases. The contractor shall develop EEP capabilities to meet the functional and performance requirements specified in the SyRS and PB and approved through the process defined in Subtask 3.1. In addition to deploying each release, the contractor shall deliver each release as Installable Software for both Virtual Machine Import and Sharepoint Migration.

The contractor shall ensure that the source code is appropriately commented. The contractor shall use a language-appropriate tool for automatically generating human-readable documentation (e.g., HTML, or PDF) from these comments and deliver the resulting outputs. The contractor shall use a language-appropriate tool for automatically generating documentation from these comments for inclusion in a Technical Data Package (TDP) for each release. Comments should be provided in the TDP separately from the source code itself. The contractor shall maintain software code documentation by utilizing an automated tool for generating human readable documentation (e.g., Doxygen, or Oracle Javadoc).

With each software release, the contractor shall deliver updated user documentation, including Training Slides and Training Materials, that reflect the new capabilities, interfaces, and/or changes within the release. The contractor shall update and maintain the EEP User Guide and online help files that are used by EEP Users. The User Guide shall consist of a compilation of the online help files.

The contractor shall host a training event for each major release, providing guidance on new capabilities, interfaces and/or changes within the release. For the second and third option years, the contractor shall host a training event for the final minor release of the option period. This training shall occur in a virtual environment (e.g., video or teleconference) that is provided and hosted by the contractor.

Coincident with the delivery of each EEP release, the contractor shall provide an updated PB and RTM to effectively track requirements/features that have been met, indicate those that are outstanding, and document any emergent requirements/features that have been approved for inclusion in a future release.