Attachment 1 DRAFT PWS.docx
DOCX document 253 KB Posted
- Solicitation number
- 632469378
- Issued by
-
Defense Information Systems Agency
About this file
This document is a Performance Work Statement (PWS) for the Joint Electromagnetic Battle Management (EMBM-J) Situational Awareness (SA) capability. The PWS describes the requirements for the continued development, deployment, operations, maintenance, testing, training, and enhancements of the current EMBM-J SA software and system architecture using agile methodologies. Key requirements include continuous integration and delivery of EMBM-J SA releases within commercial cloud environments, system administration, maintaining security posture and Authority to Operate, user interface development, automation of data ingest, and enabling interoperability with service EMBM systems and the EMBM-J Decision Support capability. The PWS outlines the scope, objectives, performance requirements, and deliverables across tasks such as Agile Program Management, Engineering Support, Software Development, Environment Infrastructure and Operations, and optional tasks for specialized user requests, helpdesk support, training and demonstration support, migration to DISA/JWCC, and JWICS deployment. This PWS supports a pre-solicitation for the EMBM-J SA capability, which is issued by the Defense Information Systems Agency (DISA) Program Executive Office (PEO) Spectrum.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Sources Sought Notice.docx | DOCX document | |
| Attachment 2 Draft PWS Feedback.xlsx | XLSX spreadsheet |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
PERFORMANCE WORK STATEMENT (PWS)
| Award/Mod Effective |
| Version Date |
| Award |
| TBD |
| Contract Number: |
| TBD |
| Task Order Number: |
| TBD |
| Contractor Name |
| TBD |
| Tracking Number: |
| TBD |
| Follow-on to Previous Contract and Task Order Number: |
| EMS SA: W52P1J18DA045, HC104720F0010 |
1. Contracting Officer’s Representative (COR).
a. Primary COR. See DITCO Additional Text G1 - Points of Contact
b. Alternate COR (ACOR). See DITCO Additional Text G1 - Points of Contact
c. Property Administrator. See DITCO Additional Text G1 - Points of Contact
2. Contract or Task Order Title.
Joint Electromagnetic Battle Management (EMBM-J) Situational Awareness (SA)
3. Background.
United States (US) dominance in air, land, sea, space, and cyberspace relies on accessing the electromagnetic spectrum (EMS) when and where needed. Today, we are challenged by peer and near-peer adversaries. These challenges have highlighted the cross-cutting reliance of the Joint Force on the EMS.
In pursuit of Department of Defense’s (DoD) objective to achieve superiority in the EMS and maintain a joint all-domain advantage, Defense Information Systems Agency (DISA) Program Executive Office (PEO) Spectrum is developing a Joint Electromagnetic Battle Management capability to support the Joint Force Commander (JFC) in all activities related to organizing, understanding, planning, deciding, directing, and monitoring joint EMS operations (JEMSO).
Combatant Command (CCMD) or Joint Task Force (JTF) JEMSO Cells (JEMSOCs) coordinate with Service Component EMS Operations (EMSO) staffs to enable situational understanding of the electromagnetic operational environment (EMOE), and prioritize, integrate, and deconflict Service EMSO plans for their assigned operational areas, across all domains, functions, and technologic standards implementation. In an evolving and growing competitive environment, the traditional, manual, time, and labor-intensive methods of managing the myriad of electromagnetic emitters and apertures on the modern battlefield are no longer adequate.
An EMBM-J SA system operating in command centers will allow commanders to coordinate, synchronize, and integrate EMS operations into the maneuver space across the full range of their military operations. Therefore, the design of this EMBM system must anticipate and account for current and unknown future EMS maneuver behaviors of Spectrum-Dependent Systems (SDSs). Joint Force Commanders will then achieve unity of effort resulting in EMS superiority.
The overarching EMBM-J capability is divided into four general requirement areas:
1) Situational Awareness (SA) – (EMBM-J SA, abbreviated as EMBM-J SA), pertains to the scope of this PWS.
2) Decision Support (DS) – (EMBM-J DS, abbreviated as EMBM-J DS)
3) Command and Control (C2) – (EMBM-J C2, abbreviated as EMBM-J C2)
4) Training Capability / Simulation
Although scope of work pertains to EMBM-J SA, PWS will make multiple references to other capability areas because interoperability between EMBM-J SA, EMBM-J DS, and future EMBM-J C2, and Training/Simulation capabilities is critical to the overall success of the overarching EMBM-J capability. EMBM-J DS is currently being developed on a separate contract.
Key Stakeholders involved in the inception, development, management, and end use of the EMBM-J SA capability are:
· STRATCOM – Operational Sponsor, capability requirements oversight
· Joint Electromagnetic Warfare Center (JEWC) – Operational User Representative, end user engagement synchronization.
· DISA PEO Spectrum – Program Manager, capability acquisition, delivery, deployment, and sustainment
· CCMDs/JFC JEMSOC – Operational Users, intended day-to-day users of the system.
This PWS continues work previously performed under the EMS SA contract W52P1J18DA045/HC104720F0010, for EMBM-J SA capability development and maintenance.
4. Objectives EMBM-J SA overarching objective is to provide automated EMOE evaluation capabilities to the end user in an incremental manner via Minimum Viable Product (MVP) and Minimum Viable Capability Releases (MVCR) while holistically addressing the foundations of the solution architecture, design, data, interfaces, and system security; and leveraging industry's agile best practices through continuous integration / continuous development (CI/CD) for software development and software delivery while meeting the highest standards of cybersecurity readiness in an environment of continuous and unpredictable change.
MVPs are utilized to assess the effectiveness of functionality, with the assumption that requirements and user needs are best understood through hands-on discovery.
It is DISA’s desire that development planning be aligned with the requirement prioritization per the EMBM-J Information Systems (IS) Capability Design Document (CDD) dated 20 October 2020 and that the requirements associated with each MVCR be identified in the product roadmap. The Government recognizes that MVCR definition may evolve within the product roadmap as user needs become better understood. The EMBM-J MVCR-1 Prioritization Spreadsheet serves as a foundation to develop relevant epics, features, user stories, and acceptance criteria with enough detail for configuration and development. The contractor shall work closely with the Government Product Owner to ensure that the Product Backlog, stored in JIRA or other Agile tracking tool, is continually and regularly maintained in alignment with the Agile cadence so that the necessary Release and Sprint Backlog items (epics and user stories) are defined with acceptance criteria and prioritized by the Government Product Owner prior to the start of each release and sprint. The contractor shall prioritize development in accordance with the Program Backlog aligned to Government priorities. Leveraging existing Commercial of the Shelf (COTS), other Government Off-the-Shelf (GOTS), and DoD capabilities will be pursued to the extent possible, instead of developing custom coded software.
EMBM-J SA technical objective is to employ modern technology that ingests data sources and provides data correlation, data presentation and visualization, and engineering services to allow for enhanced situational awareness of the EMOE. The EMOE is defined as the geophysical environment consisting of the background electromagnetic radiated energy along with the friendly, neutral, and adversarial electromagnetic order of battle over the area of influence. The EMOE is congested by friendly and neutral transmitters, contested by adversary emitters, and constrained by other interests within the operating environment. The key capability areas of EMBM-J SA are detailed in Appendix 4.
This effort will leverage existing data feeds/sources that have already been synthesized, correlated, or combined. Additional data sources to be integrated within EMBM-J SA will continue to be prioritized with the Product Owner and Operational Sponsor. The data sources EMBM-J SA currently ingest, and additional candidate data are listed in Appendix 1. EMBM-J SA has already deployed a MVP and working MVCRs to deploy additional capabilities.
5. Scope This effort will obtain contractor support services for 4-5 Agile team(s) to continue development, configuration, training, testing and deployment of EMBM-J SA. These Agile teams shall operate within the existing EMBM-J SA platform, aligned against the current Product Roadmap / Backlog and existing CI/CD pipeline. The solution(s) developed in this task order will utilize Agile delivery and leverage the latest technology offerings. Program Executive Office (PEO) Spectrum is seeking the development, delivery, and deployment of EMBM-J SA, a system that will bring together the data and analytics enabling the user the ability to visualize and understand the Electromagnetic Operating Environment (EMOE), a system that will support Combatant Command (CCMD) and Joint Task Force (JTF) JEMSO Cells (JEMSOCs). Interoperability, reliability, secure connectivity, and data access are paramount EMBM-J SA attributes.
The contractor shall provide qualified personnel with relevant experience, domain knowledge, and other items and non-personal services necessary to perform the EMBM-J SA services, as defined in this PWS, to include necessary system and database administration support for the EMBM-J SA development, test, and production commercial cloud environments.
EMBM-J SA is currently hosted as a web-based application hosted in an Impact Level 6 (IL6) Amazon Web Services (AWS) Commercial Cloud Environment through the National Geospatial-Intelligence Agency (NGA). There is a future requirement to deploy EMBM-J SA to Joint Worldwide Intelligence Communication System (JWICS) under this contract; however, is an optional task due to uncertainty on timing.
Although EMBM-J SA system enhancements will routinely be identified, prioritized, and deployed under the Agile framework, there are material and external efforts that PEO Spectrum may elect to fund and implement in parallel to Base requirements, these are listed as Optional Tasks.
Primary Tasks:
Task 1 - Agile Program Management Task 2 - Engineering Support and Outreach Task 3 - Software Development, Enhancement, and Maintenance Task 4 - Environment Infrastructure and Operations
Optional Tasks:
Task 5 - Extensions to Support Specialized User Requests (Optional Task) Task 6 - Helpdesk Tier II (Optional Task) Task 7 - Support for Live, Virtual, and Constructive (LVC) Training, Exercises, Experiments, and Demonstrations (Optional Task) Task 8 - Migration to Joint Warfighting Cloud Capability (JWCC) (Optional Task) Task 9 - Deployment to the JWICS (Optional Task) Task 10 - GOAT Stand-Alone application and EMBM-J SA Interoperability (Optional Task)
The Government may require surge support during the base or any option period, and surge modifications will be within the scope of the contract and provide increased support for the defined task areas of this PWS. Surge support over the life of the contract will not exceed 50% of the contractor’s total proposed cost/price for the base and all option periods, excluding any six-month extension of services pursuant to FAR 52.217-8.
6. Performance Requirements
6.1 Task 1 – Agile Program Management
Agile Program Management activities will span all contract tasks. This includes managing and overseeing all activities performed by contractor personnel, including subcontractors, to satisfy the requirements of the contract.
6.1.1 Agile Program Management Plan
The contractor shall develop, establish, and perform a comprehensive Agile Program Management Plan (APMP). This plan will describe the organizational resources, processes and procedures associated with how the program will be managed and executed, to include accurate and timely tracking and reporting of cost, schedule, and performance information throughout the life cycle of the program, subcontractor management, and small business participation.
The APMP will define management controls, performance measures, and cost, schedule, and performance metrics aligned to program processes (e.g., agile execution); includes the reporting frequency for each, and the threshold parameters that indicate potential for risk and issues; not all metrics may apply at times and metrics are expected to be adjusted over time given the tools in use and the state of program execution, to include collecting and reporting Government-requested metrics deemed necessary for complete visibility.
The APMP will describe the agile process and procedure(s) to deliver mission capabilities incrementally and rapidly by reducing non-value-added steps and deliverables.
The APMP will describe a streamlined DevSecOps and CI/CD delivery process that works in concert with the established EMBM-J SA DevSecOps pipeline. Currently, EMBM-J SA utilizes the NGA Common Operations Release Environment (CORE) capability to support DevSecOps and CI/CD pipeline for software releases.
The APMP will describe the information / knowledge management and program documentation management process and procedure(s) to be implemented in line with agile execution and EMBM-J DevSecOps delivery.
The APMP will describe the personnel management process and procedure(s) to provide qualified staff with the requisite knowledge, skills, experience, and certifications necessary to perform in the position to which they have been assigned. The plan will describe the contract funds management process and procedure(s), and license management process and procedure(s). Any additional COTS applications procured for the development environment must be justified and Government approved. Respective licenses shall be current and tracked to ensure continuity, and processes shall be established to transfer licenses to the Government upon Government request.
The APMP will include a comprehensive agile-based solution roadmap to include key decisions, software life cycle activities (e.g., agile sprint cycles), test activities and events, integration activities, training activities, task dependencies, risk reduction / mitigation activities, enterprise architecture products, documentation, Government activities necessary to support contractor execution, and any other roadmap topics/items affiliated with the contractor agile execution methodology and CI/CD.
6.1.2 Quality Control Plan
The contractor shall develop a Quality Control Plan (QCP) documenting activities that will be established, resourced, and executed to maintain effective quality control of services and deliverables as performed within this contract. This plan shall also focus on continually improving the flow of value-added and secure functionality to users through the CI/CD pipeline, which shall include the tracking of key metrics. Monitoring and measuring shall be institutionalized in the delivery of this PWS to identify areas for improvement and ensure that operational deployments are meeting goals. The contractor shall address Agile-based requirements outlined in PWS Section 7, which includes, but is not limited to the following:
· Percentage of each high-level capabilities completed – deployed to Production and accepted by users.
· Number of user stories prioritized and approved ready for development.
· Velocity - Amount of work the team completes during a given period.
· User acceptance rate – Rate of developed/configured functionality that is accepted by users.
· Escape Rate – number of defects for a deployment that were identified after the release.
· Recidivism Rate - Percent of work returned to the developer for various reasons within the CI/CD Workflow.
The contractor shall establish additional software development and deployment quality control processes and metrics in support of Task 3. In addition to software quality, the contractor shall propose quality control processes and/or metrics in the performance of Task 6.1 Agile Program Management, Task 6.2 Engineering Support and Outreach and Task 6.4 Environment Infrastructure and Operations. As Optional Tasks are funded, it is anticipated those efforts will align to established QCP procedures.
In addition to typical quality control considerations such as timeliness, accuracy, and completeness, special attention shall be applied to ensure performance and deliverables are also relevant to the background and scope of the PWS. The EMS domain is highly technical, and EMS application to electronic warfare (EW), operational planning, and ultimately EMBM-J SA capabilities will require intentional application of expertise to PWS deliverables.
6.1.3 Contract Management Review (CMR)
The contractor shall conduct the CMRs with the Program Management Office (PMO) monthly and cover all aspects of quality, resource utilization, and funding/invoicing. PEO Spectrum contracting and financial leadership will lead the meeting at least quarterly. The contractor shall track and provide a presentation on all efforts/activities performed across all tasks in this PWS. Within each Period of Performance (PoP), the reporting period starts and ends dates shall be the same as the contractor billing period within the PoP. The review shall address financial status, task costs, variances, and funds remaining for the overall contract and by Contract Line-Item Number (CLIN). The information shall be provided numerically and graphically. Financial line graphs shall use color to delineate planned expenditure, actual expenditures, and CLIN ceiling. Schedule status and risks will also be briefed during the CMR.
The contractor shall identify status of individual mandatory training requirements and completion of DISA-provided NDA. The NDA shall be verified current as of the date in the monthly CMR. CMR briefs shall be sent to the Contracting Officer (KO) and COR via email one business day prior to presentation. The CMR shall include a contract-level risk matrix with probability, consequence, and remediation/mitigation approach information. Additionally, the CMR shall also include a list of all Other Direct Cost purchases and status of Government Furnished Property (GFP).
6.1.4 Weekly Activity Report (WAR)
The contractor shall provide a weekly activity report that consists of accomplishments, concerns to include perceived risks or impediments to progress, upcoming meetings, travel, planned absence for contractor PM and/ or key members of the team. The report should be succinct. The WAR shall be provided by 1200 Monday for the preceding week. Holidays occurring on a Monday shift the delivery accordingly.
6.1.5 Product Roadmap
As an initial activity, the contractor shall receive a Product Roadmap from the Government. The items identified in the roadmap must align to the overall product vision and be organized by IS CDD capabilities and features. The team shall use the roadmap to organize the Backlog, prioritize work, and ensure that the appropriate capabilities are being delivered at the right time. The contractor shall adjust the product roadmap, in consultation with the Government Product Owner, prior to each release/sprint planning event. The team shall, in consultation with the Product Owner and facilitated by the ScrumMaster, allocate backlog items to sprints that align to the roadmap. The Product Roadmap shall include:
1) Time Period (Data, quarter, release, phase, etc.)
2) Goal/Objective/IS CDD area
3) High-level feature description
4) Metrics, and/or Measures of Success (MOS) description for the release
6.1.6 Technology Report and License Management
The contractor shall provide and maintain a Technology Report identifying all technologies embedded in EMBM-J SA and used by the contractor for the software enhancement support, testing, monitoring, deployment, and operations of the system. The report shall contain at a minimum the following for each technology: Source, Purpose, Version utilized, Software License, End of Support Information (i.e., Dates, Options and Costs for extended support), and Proposed Approach for addressing security posture and technology obsolescence with related Non-Developmental Item (NDI) cost information.
The contractor shall provide license management, justification, and coordinate COR approval to purchase, through the use of the material CLIN, for renewals of any additional applications and tools procured, for the development environment, to include documenting, tracking, and maintaining a log of all product licenses, and preparing a schedule to ensure licenses are assigned, unassigned, and renewed as needed. Note licenses for EMBM-J Test and Production environments will be purchased by the Government, exceptions for discovery or special cases will need Government approval.
The contractor shall obtain written approval from the COR before purchasing any software licenses. The contractor shall obtain approval from the COR before adding any software development, enhancement, software testing or system operations technologies to the system technology baseline. The contractor shall retain all the written approvals and submit the approvals with the invoices.
6.1.7 Key Personnel. Key personnel are those people considered essential to successful contractor performance. All key personnel must be on board at task order award.
The contractor shall fill the following Key Personnel positions for the purposes of this contract:
· 6.1.7.1 Business Analyst Lead
With knowledge of EMS/JEMSO mission and processes. Decomposes epics, features, and user stories to low level user stories and acceptance criteria that can be configured and developed in sprints. Maintains product backlog in close coordination with Government Product Owner. Following experience and qualifications are required:
· 5 or more years in an Electromagnetic Spectrum Operations, or equivalent role.
· 2 or more years performing business analysis, requirements analysis, and agile user story/use case analysis.
· 6.1.7.2 Technical Lead
Technical lead provides overarching technical design and implementation guidance to meet EMBM-J requirements in the most efficient manner. This entails rapid and incremental delivery to users, as well as minimizing technical debt through scalable data and application architecture. Following experience and qualifications are required:
· 5 or more years of leading mission system implementations.
· 5 or more years of experience leading teams in delivering in DevSecOps environment.
· 5 years of experience communicating complicated data, architecture, and development topics clearly to decision-making bodies and senior leadership.
· 3 or more years of experiences with modern software development tools such as: GITLAB, Fortify, Atlassian Suite.
· 6.1.7.3 Software Developer Lead
The EMBM-J SA developer lead institutes development quality standards, takes on the most challenging coding assignments, and performs code reviews. Following experience and qualifications are required:
· 5 or more years of experience developing applications using modern coding languages.
· Understanding of latest development and data management techniques.
· Ability to establish development vision for the team.
· 3 or more years of experience leading coding and technical reviews.
· 3 or more years of experience leading developers in DevSecOps environment.
· BS in computer science, information systems or a related technical degree plus and/or equivalent five (5) years’ experience.
· Certified Secure Software Lifecycle Professional (CSSLP) certification is preferred.
· 6.1.7.4 Test Lead
The Test Lead oversees all stages of testing from test script creation, to test execution, and defect resolution. The focus is on automating testing as much as feasible, performing frequent regression testing and supporting all user testing activities. Following experience and qualifications are required :
· 5 or more years of experience applying Agile methodologies and tools on at least one IT related development program, to include defining and testing user story acceptance criteria.
· 5 or more years of experience converting user stories and acceptance criteria into test scripts.
· Strong communication skills and ability to facilitate research and analysis with all team members to include Product Owners, Developers, and Senior Leaders.
· 10 or more years of acquired knowledge in planning, directing, and managing.
interoperability testing (interfaces, data quality, etc.)
· 5 or more years of experience as Test Lead on a data visualization-type implementation is desired.
· Bachelor’s degree in computer engineering, computer science, information systems, information technology, or a related engineering or IT discipline/ or equivalent 5 years’ experience
· 6.1.7.5 Systems Administrator Lead The System Administrator Lead shall be responsible for the management, operation, and enhancement of EMBM-J SA development, test, and operational environments. Following experience and qualifications are required:
· 5 or more years of experience supporting the planning, designing, and implementing of networks, cloud, and lab environments.
· 5 or more years’ experience performing routine system maintenance and troubleshooting, managing the installation of SW and HW upgrades, maintain system performance, and recommending enhancements.
· 5 or more years with AWS cloud infrastructure supporting a Government environment.
· 6.1.7.6 Information System Security Officer (ISSO)
The ISSO shall work directly with the Spectrum PEO Government Information Systems Security Manager (ISSM) and EMBM-J SA Government ISSM on all IA-related matters, including Authorization and Assessment reviews, and Cyber Security testing. ISSO shall perform all security.
engineering, security, and A&A, and continuous monitoring activities for the program. Following experience and qualifications are required:
· Meet DoDI 8140.03 Work Role of a basic level ISSM (722) qualification and compliance requirements (e.g. Security+).
· Experience updating authoritative authorization systems, preference for Xacta experience.
· Experience implementing and overseeing a software code assurance program based on industry-based practices.
· Experience overseeing a cybersecurity program of a similar scope and complexity including vulnerability assessments, IAVA reporting, and IA problem resolution.
The above labor categories are defined as Key Personnel. These skilled, experienced professional and/or technical personnel are essential for the contractor’s successful accomplishment of the work performed under this contract. The contractor agrees that Key Personnel shall not be removed from the contract work or replaced without compliance with the key personnel clause.
6.1.8 Phase-In
Develop and implement a Phase-In Transition Plan that details the activities and resources needed to perform the contract requirements, to include the on-boarding staffing plan (% onboard within x days), key personnel by name and qualifications, a schedule for all Phase-In activities, data / information deemed necessary to be provided by the Government in the forms of knowledge transfer, and Phase-In metrics.
The Phase-In period is projected to be 30 calendar days. The Phase-In period encompasses the people, processes, tools, technologies, and sequenced activities required to maintain system operation, sustainment, and development activities. The contractor shall provide a transition Phase-In Plan to the Government five business days after contract award.
6.1.9 Conduct Program Kick-Off Meeting
The contractor shall conduct the Kick-Off meeting within ten (10) business days of award. The meeting shall:
1) Provide an introduction between the contractor personnel, to include all Key Personnel, and Government personnel who will be involved with the contract.
2) Address technical, management, security issues, and travel authorization and reporting procedures.
3) Discuss the contractor’s overall approach to the effort
4) Provide a schedule of deliverable suspense dates and cadence for all recurring reporting and program reviews requirements.
6.1.10 Meeting Support
The contractor shall support the Government during ad-hoc meetings, briefings, conferences, and agency events. Support includes developing and/or contributing to the creation of briefings and presentation materials. The contractor shall present material at ad-hoc meetings as required.
The contractor shall provide minutes of each Technical Exchange Meeting (TEM), CMR, and meeting. The minutes shall include the date/time of the meeting, list of attendees, points of discussion, decisions made, and action item. Draft minutes shall be provided via email for review, comments, and update by the participants within three business days of the meeting. Government participants will have two business day to submit their updates. Updates shall be incorporated, and final minutes provided via email with seven business days of the meeting. If no comments are received by the participants, the draft minutes shall become final.
6.1.11 Phase-Out
The contractor shall support a Phase-Out period during which transition between the contractor and the successor contractor is necessary to assure minimum disruption to vital services and Government activities. During the transition period, the incumbent will be fully responsible for the continuation of services as detailed in the PWS. The transition period is projected to be 30 days.
The contractor shall facilitate the transition of all tasks performed under this contract to the successor (Government and/or contractor) who will continue the support services, including operational knowledge (i.e., on-the-job training). The transition will encompass the processes, procedures, documentation, and tools currently utilized under this contract.
The contractor shall submit a Phase-Out Transition Plan to ensure the services required under this contract are continued without interruption and maintained at the required level of proficiency.
The Phase-Out Transition Plan shall detail contractor tasks, task dependencies, and milestones during the transition period. The Phase-Out Transition Plan shall include the list and location of technical artifacts, SOPs, etc. to include historical information that may assist the successor contractor in a smooth transition, and an inventory of all Government Furnished Property (GFP). Multiple knowledge transfer meetings shall be accommodated.
Deliverables Task 1
| Task |
| Deliverable Title |
| Format |
| Due Date |
| Distribution |
| Frequency |
| 6.1.1 |
| Agile Program Management Plan (APMP) |
| Contractor |
| Initial 30 calendar days after award, final 60 calendar days after award |
| COR |
| Updates Quarterly |
| 6.1.2 |
| Quality Control Plan (QCP) |
| Contractor |
| Initial 30 calendar days after award, final 60 calendar days after award |
| COR |
| Updates Quarterly |
| 6.1.2 |
| Quality Control Metrics |
| Government |
| First due one month after Award |
| COR |
| Monthly |
| 6.1.3 |
| Contract Management Review (CMR) Brief |
| Contractor |
| First due one month after Award |
| COR |
| Monthly, NLT 10 business days after the end of month |
| 6.1.4 |
| Weekly Activity Report (WAR) |
| Government |
| First due one week after Award, 1200 Mondays |
| COR |
| Weekly |
| 6.1.5 |
| Product Roadmap Updates |
| Contractor |
| First update due 1 month after Award |
| COR |
| Updated before and after each SW release |
| 6.1.6 |
| Technology Report |
| Contractor |
| First due one month after Award |
| COR |
| Updates Quarterly |
| 6.1.8 |
| Phase-In Transition Plan |
| Contractor |
| 5 business days after Award |
| COR |
| Once |
| 6.1.9 |
| Kick-Off Meeting |
| Contractor |
| 10 business days after Award |
| COR |
| Once |
| 6.1.11 |
| Phase-Out Transition Plan |
| Contractor |
| 60 calendar days before end of Contract |
| COR |
| Once |
6.2 Task 2 – Engineering Support and Outreach
Engineering support and outreach activities include more formal support to PEO Spectrum in high-level technical management of EMBM-J SA and managing the EMSO stakeholder community. Activities in this section are required support, and complementary to the Agile Software Development activities detailed in Section 6.3.
6.2.1 Technical Assessments/Recommendations
Outside of EMBM-J user generated feedback, the contractor shall make recommendations with respect to enhancing performance, User Interface/User Experience (UI/UX), increasing reliability, and extending infrastructure to meet future user demands, increasing data processing requirements, and handling of historical data. The contractor shall make recommendations for enabling interface and/or data exchange mechanisms with external applications and across EMBM-J SA capabilities. The contractor shall develop recommendations and specifications for cross domain solutions, if applicable. The contractor shall participate in technical working group meetings and Integrated Product Teams (IPT) to gather necessary technical data.
The contractor shall evaluate engineering services that could be integrated into the EMBM-J SA. The contractor shall also evaluate alternative hosting or development/test environments (e.g., JWCC, etc.), software integration environments (e.g., Joint Test and Interoperability Center (JTIC) Labs), or incorporation of alternate/new enterprise cybersecurity or cloud microservices. This task will include participating in EMBM-J SA systems engineering and deployment, operations, and sustainment meetings. The contractor will provide recommendations in white papers.
The contractor shall update EMBM-J UI Style Guide to ensure common coloring and style standards across system components and provide a baseline to maintain branding of other EMBM-J capabilities. Common style and branding across all EMBM-J capability components is critical to reduce confusion and unneeded complexity for CCMD/JEMSOC users.
6.2.2 Data Management
The contractor shall prepare a Data Management, Quality, and Migration Plan that describes the processes and procedures to manage data, ensure data quality, and perform data migration of data associated with EMBM-J SA functionality and integration with the EMBM-J SA baseline. The contractor shall evaluate Government designated data sources and work with Government Subject Matter Experts (SMEs) to recommend data review, data retention, data governance policies, and how the contractor shall evaluate data formats and compatibility with existing data requirements, and which methodologies to integrate and correlate data, where applicable. This will include such assessments as leveraging metadata as necessary to maintain traceability of the data (searchable, source, etc.) as well as potential rule sets for determining best sources of data when disparate sources conflict.
The contractor shall align metadata with DoD Chief Information Officer (CIO) Chief Digital and Artificial Intelligence Office (CDAO) guidance, and in accordance with Coalition Joint All-Domain Command and Control (CJADC2) reference design documentation. The contractor shall document this strategy in the Data Management, Quality, and Migration Plan.
The contractor shall provide updates to the JEMSO Data Dictionary and Model documentation and integrate all necessary aspects of the model into the EMBM-J data schema and architecture. This activity will include robust documentation within the EMBM-J SA application Wiki, and updates of the schema to align to emerging Application Programming Interface (API) and data feeds.
The contractor shall perform data quality tasks such as data validation, profiling, cleansing, scrubbing, and error handling to ensure data accuracy; data validation must be to complete data sets (start to finish) and not just to mission critical data. The contractor shall perform data conversion and migration activities, in coordination and collaboration with the Government, for any data required from legacy systems. The contractor shall perform analysis and planning to properly execute data migration, including special handling for controlled information. The contractor shall perform data integration activities, such as Extract, Transform, and Load (ETL) to support migration.
The contractor shall conduct data conversion validation exercises (e.g., mock conversions, Rehearsal of Concept (ROC) drills) in coordination and collaboration with the EMBM-J DevSecOps Team and applicable legacy system data providers (i.e., systems in which data is exchanged) to ensure conversion accuracy and data quality.
The contractor shall support web service interfaces with Service and EMS community systems and interoperability with EMS community data standards. The contractor shall integrate engineering and data services available from other external systems as identified in this task, and as prioritized / deployed in accordance with (IAW) PWS 6.3. Coordination with the EMBM-J DS contractor and other EMS systems will be required, as EMBM-J SA Data Lake, and Common Data Layer (CDL) must be available via APIs and services to external EMS systems and applications. Likewise, EMBM-J SA will need an active interface to accept data from EMBM-J DS and other external systems. Anticipated activities may include:
· Revisions of EMBM-J SA data lake interfaces to reflect modifications,
· Support integration with EMBM-J DS to align ontology, data models, and metadata architecture and usage,
· Coordination with evolution of EMBM-J DS ontology and metadata architecture,
· Providing EMBM-J SA system specifications and interface definitions,
· Expanding EMBM-J SA data sources to include EMBM-J DS planning documentation, analytical results, and data,
· Developing the ability to import data from EMBM-J DS to include Joint Restricted Frequency List (JRFL) and Joint Integrated Prioritized Target List (JIPTL).
The contractor shall develop and maintain EMBM-J SA API data and engineering service external-use instructions within a centrally located repository(s) for EMS community access and use.
6.2.3 Customer and Partner Outreach
The contractor shall provide support to TEMs, and external customer engagements at the direction of the Government to support the overarching EMBM-J program, approximately two per month. TEMs are anticipated to be held with EMS data provider organizations, stakeholders, and technical representatives of other programs, including EMBM-J DS, PEO Spectrum’s Global Electromagnetic Spectrum Information Systems (GEMSIS) program, service/component-level EMBM programs, and other EMBM-J contractor staff. Government programs and organizations for TEMs include (but are not limited to): Electronic Warfare Planning and Management Tool (EWPMT), Spectrum Services Framework (SSF), Multi-Intelligence Spatial Temporal (MIST), Global Combat Support System (GCSS-J), Integrated Broadcast System (IBS), Vaquero, Modernized Integrated Database (MIDB)/Machine-Assisted Analytic Rapid-Repository System (MARS), Real Time Spectrum Operations (RTSO), Systems Planning Engineering and Evaluation Device (SPEED), Global Command and Control System (GCCS-J), Joint Electromagnetic Spectrum (EMS) Information Analysis and Fusion (JEMSIAF). The contractor shall prepare an agenda for each meeting, meeting materials, and meeting minutes.
The contractor shall provide ad hoc demonstrations of the EMBM-J SA as requested by the Government. The contractor shall document meeting minutes, outcomes, and action items. The contractor shall support the Government as required supplying updated information, materials, and/or slides for presentation to external parties and senior leadership. The Government does not anticipate more than six of these events outside of routine UVE and/or user software testing events.
Formal customer engagements, primarily in the form of User Validation Events (UVE) are anticipated to be held quarterly with the Operational Sponsor and external mission users. In coordination with EMBM-J PMO, the contractor shall prepare an intentional agenda for each event as well as respective presentations, demonstrations, trainings, and other content. These sessions are normally 3 days and held in-person at Operational Sponsor or PMO locations to foster collaborative dialogue and working relationships across the EMS community. Use of Test and/or Production environments during the forum is critical to keep discussion operationally relevant. The contractor shall create detailed After-Action Reports (AARs) to capture user feedback, decisions made, and key discussion minutes. Respective AARs from these sessions will be shared with the broader EMBM-J stakeholder community, and content will be evaluated and integrated into the product backlog.
6.2.4 Design and Architecture Reviews
The contractor shall support Chief Engineering Panel (CEP)-type reviews which may be required for significant architectural changes or enhancements to EMBM-J SA, primarily in the form of developing architectural artifacts. In the event a design review is required, the contractor shall provide briefing materials at least one (1) week prior to the event. It is the Government’s intention to leverage agile development practices and associated reviews during sprint cycles in lieu of Preliminary Design Review (PDR) and Critical Design Review (CDR)-type formal reviews where applicable for enhancements and corrections of anomalies (bugs); however, EMBM-J is identified Acquisition Category (ACAT) III Acquisition Pathway Program and will be subject to higher-level milestone reviews throughout the EMBM-J SA system’s lifecycle. The Government does not anticipate more than three (3) of these reviews annually.
The contractor shall update and maintain the following architectural products documenting compliance with Net –Ready-Key Performance Parameters (NR-KPP), program-level requirements supporting EMBM-J SA.
· DoDAF AV-1: Overview and Summary Information
· DoDAF OV-1: High-Level Operational Concept Graphic
· DoDAF OV-2: Operational Resource Flow Description
· DoDAF OV-3: Operational Resource Flow Matrix
· DoDAF OV-4: Organizational Relationships Chart
· DoDAF OV-5a: Operational Activity Decomposition Tree
· DoDAF OV-5b: Operational Activity Model
· DoDAF OV-6c: Event-Trace Description
· DoDAF SV-1: Systems Interface Description
· DoDAF SV-2: Systems Resource Flow Description
· DoDAF SV-3: Systems-Systems Matrix
· DoDAF SV-4: Systems Functionality Description
· DoDAF SV-6: Systems Resource Flow Matrix
· DoDAF SV-7: Systems Measures Matrix
· DoDAF SV-8: Systems Evolution Description
· DoDAF StdV-1: Standards Profile The contractor shall answer requests for information from other Government projects working on spectrum related architecture products, and PEO Spectrum funded efforts by other contractors to develop supporting architectural products.
Deliverables Task 2
| Task |
| Deliverable Title |
| Format |
| Due Date |
| Distribution |
| Frequency |
| 6.2.1 |
| Technical Whitepapers |
| Contractor format |
| 15 Business Days from Request |
| COR |
| As requested, no more than 1 per quarter |
| 6.2.1 |
| UI Style Guide Updates |
| Existing Format |
| Initial 90 Days after award |
| COR |
| Updated quarterly |
| 6.2.2 |
| Data Management, Quality, and Migration Plan |
| Contractor Format |
| Initial 30 calendar days after award, final 60 calendar days after award |
| COR |
| Updated quarterly |
| 6.2.2 |
| JEMSO Data Dictionary and Model - Updates |
| Contractor Format / EMBM-J SA Wiki |
| Initial updates 30 calendar days after award |
| COR |
| Updated Monthly |
| 6.2.2 |
| Data Correlation Ruleset Updates |
| Existing Format |
| Initial updates 30 calendar days after award |
| COR |
| For each software release |
| 6.2.2 |
| API Documentation Updates to enable external consumption from the data layers |
| Existing Format |
| Initial updates 30 calendar days after award |
| COR |
| For each software release |
| 6.2.2 |
| API Documentation Updates to allow external use of engineering services |
| Existing Format |
| Initial updates 30 calendar days after award |
| COR |
| For each software release |
| 6.2.3 |
| EMBM-J SA Demonstrations |
| Contractor |
| As scheduled |
| COR |
| No more than six annually |
| 6.2.3 |
| User Validation Event (UVE) content preparation, AAR |
| Contractor |
| 5 Business Days before UVE Event, AAR 5 Business Days after Event |
| COR |
| Quarterly |
| 6.2.4 |
| Enterprise Architecture Artifacts - Updates |
| Government |
| 60 Calendar Days from Award for initial update |
| COR |
| Updates Monthly, or upon software release to production |
6.3 Task 3 – Software Development, Testing, and Deployment
* For the duration of the contract, the Government anticipates a majority of development to address requirements and product backlog will be conducted in the Base Year (40%), and Option Year One (30%), with reduced development requirements in Option Year Two through Option Year Four (10%) per PoP* The Agile team’s main focus will be on capability delivery which consists of EMBM-J SA software development, testing, and deployment. This task includes required change management and cybersecurity governance requirements to enable software releases to the Test and Production environments.
6.3.1 Development Planning and Reporting
Develop and update the EMBM-J Agile Development Plan (ADP) that describes the planned approach, detailed end-to-end processes and procedures, and development framework for:
1) continuous capability delivery.
2) requirements management and traceability.
3) how capability is prioritized, designed, developed, implemented, tested, integrated, and delivered incrementally (e.g., sprints, releases).
4) how defects are managed, tracked, and resolved, to include recurring defects.
5) how cybersecurity compliance is ensured.
6) how technical debt is identified, managed, tracked, reported, and remediated.
7) use of DevSecOps processes and procedures, to include aligning with the EMBM-J SA processes within the Government-provided environments and EMBM-J SA baseline and complying with security policies within the EMBM-J SA production baseline.
8) use of automation and solution orchestration.
9) agile team structure, responsibilities, expertise composition, and synchronization.
10) agile processes and procedures to be implemented, to include alignment and interaction with Government PI Planning.
11) synchronization with the Government; and
12) metrics used to monitor progress aligned with the metrics used by the EMBM-J SA capability baseline.
Report status shall: (1) Provide metrics utilizing the DevSecOps tools within the development environments when available, to include establishing dashboards and reports as described in the ADP. (2) Provide technical debt status. (3) Provide activity-based reports and logs (e.g., test reports) per documented plans. (4) Provide Implementation / Agile Execution.
Provide rapid delivery in small batches, increasing the frequency and pace of releases, by applying CI/CD practices; to include planning and supporting streamlined and efficient adoption of features and/or products across end users. Integrate security into the DevSecOps workflow in a collaborative way by employing a DevSecOps approach that maintains the security policies within the EMBM-J production baseline and delivering functionality with built-in security. Objective of this effort is to maintain short cycles of work, primarily 2-week sprint durations, and operational software releases to end users every two months, or more frequently.
Ensure all configuration and development tasks (e.g., design, sprint planning, sprint reviews) are identified in the Product Roadmap. (1) Collaborate with the Government to agree upon Program Increment (PI) and sprint ceremonies, to include cadence, Definition of Done, and products; it is expected that user stories will be complete during PIs. (2) Collaborate with the Government to prioritize the product backlog and conduct continuous, iterative backlog grooming sessions to gather, elicit, understand, elaborate, and decompose the requirements; the backlog serves as the primary authoritative requirements source for all capabilities and solutions to be delivered. (3) Ensure the backlog is accurately prioritized, populated, tracked, and reported to ensure accurate and useful data to include tracking agile metrics. (4) Ensure the backlog is properly tagged, in coordination with EMBM-J PO, to support higher-level capability traceability efforts. (5) Ensure that design assumptions are understood.
Conduct reviews that, where applicable, demonstrate the work completed, identify design decisions, identify progress against the work planned, report metrics and team velocity, report blockers, address risks, issues, and corrective actions, and provides forecasts, address lessons learned, and identify improvements.
Analyze requirements, identify epics and features, and create user stories for both business functionality and technical requirements. Define testable acceptance criteria, estimate the size of user stories, and design, implement and test each user story. (1) Perform unit testing to validate developed code / functionality and acceptance criteria. (2) Prioritize epics and/or features into sprints / releases. (3) Document epics, user stories, user story features, release trains and other agile artifacts.
Create / update software design and interface documentation to ensure currency and completeness of the solution. (1) Manage, update, and maintain technical artifacts within the development tools. (2) Report, escalate, and resolve blockers, impediments and execute mitigation plans to remove dependencies and enable delivery of user stories. (3) Identify and accurately map data sources for all the data needed to accomplish the business functionality being developed and ensure data coming from the correct source. (4) Provide Government visibility to the architecture, design, and development artifacts within the agile development tool(s).
Manage technical debt. (1) Implement software in a manner that does not add new technical debt to a release and accounts for supportability in the architecture and design, including proactively raising Government awareness of technical debt based on BPR and evolving designs. (2) Identify technical debt throughout development and testing, to include functional and technical impact and develop remediation actions. (3) Perform assessments (e.g., code assessments) to ensure quality implementation and remediate technical debt associated with findings such as obsolete profiles, unused data fields / objects, and non-executable code.
Interface Development: Develop / configure interfaces with other systems to allow the EMBM-J to send and receive data electronically over the Government network. Maintain data integrity and ensure compliance with standards.
6.3.2 Requirements / Capability Management and Traceability
The contractor shall adhere to the requirements’ management and traceability process, procedures, and tools as described in the ADP. The contractor shall prepare and provide Government visibility to capability completeness and traceability via a Requirements / Capability Traceability Matrix (RTM) within the agile development tool(s), or other mechanism. The RTM shall identify, finalize, and track the release sprint to which each functional or technical requirement is assigned, listing all system/component requirements, and detailing how and where they are addressed in the system design.
The contractor shall synchronize requirements’ traceability with the EMBM-J SA Product Owner and JEWC Operational Sponsor. The Requirements / Capability Traceability Matrix shall provide a framework to demonstrate the flow-down and allocation of Systems Requirements to IS CDD decomposition of operational capabilities, and respective operational definition of done to support Government assessments on operational requirement maturity level and readiness to field.
6.3.3 Configuration/Change…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .