JPES PWS TO1 23Jan2020.docx

PERFORMANCE WORK STATEMENT (PWS)

as of 16 January 2020

Contracting Officer’s Representative (COR).

a. Primary COR.

See ADDITIONAL DITCO TERMS & CONDITIONS G1, Points of Contact for COR information.

b. Administrative COR.

See ADDITIONAL DITCO TERMS & CONDITIONS G1, Points of Contact for ACOR information.

c. Property Administrator See ADDITIONAL DITCO TERMS & CONDITIONS G1, Points of Contact for Property Administration information.

Task Order Title.

Global Force Management (GFM) Design and Development Security Operations (DevSecOps) Standup

Background.

The Defense Information Systems Agency (DISA) Joint Planning and Execution Services (JPES) Program Management Office (PMO) and Joint Planning and Execution Community (JPEC) will deliver the next generation services providing force planning, deployment planning and execution (force projection) capabilities to the warfighter. The JPES PMO currently manages the following legacy systems: Joint Operation Planning and Execution System (JOPES), Newsgroups, and Joint Capabilities Requirements Manager (JCRM). The legacy systems architectures are aging and require increasingly expensive sustainment efforts thus the reason for modernization to a net-centric, service-oriented architecture.

JOPES is the joint system used to monitor, plan, and execute mobilization, deployment, employment, and sustainment activities associated with joint operations. For the purposes of this task order, JPES is the modernization effort to replace and sunset JOPES.

Objectives.

The two objectives for this task order are to design JPES to sunset JOPES and standup DevSecOps. Specifically they are as follows:

Preliminary Design Review (PDR) and Critical Design Review (CDR): Design JPES and conduct PDR and CDR. Following a successful CDR and with Government concurrence, Development will commence in Task Order Two (TO 0002).

DevSecOps standup: The contractor DevSecOps pipeline needs to be integrated with and be synchronized with the government pipelines prior to TO 0002. This includes the unclassified pipelines and classified pipelines.

Scope.

The scope of this Task Order includes all of the performance task areas listed below to develop the JPES Design and establish a DevSecOps environment for the JPES program. This Task Order requires the day-to-day management of the schedule and performance of the all supported tasks from the Contractor perspective. This tasks calls for two main efforts of Design and DevSecOps standup. These efforts should be accomplished in parallel to the maximum extent possible and shall have a feedback loop from the DevSecOps activity to inform and affect the Design Activity. This task requires the Contractor to provide three key set of deliverables: PDR, CDR, and an unclassified and classified set of DevSecOps environments that synchronized with full end-to-end functionality. All this shall be done in compliance to the Risk Management Framework (RMF)/cybersecurity requirements and Industry best practices of security.

Performance Task Area 1 – Enterprise Management Performance Task Area 2 – Planning & Analysis Performance Task Area 3 – Design & Architecture Performance Task Area 4 – Development Performance Task Area 5 – Test and Evaluation (T&E) Performance Task Area 6 – Deployment Performance Task Area 8 – Risk Management Framework (RMF)

Performance Requirements.

The Contractor shall architect and design JPES to replace the functionality currently resident in JOPES that includes all the functions performed in the JOPES Editing Tool (JET), Rapid Query Tool (RQT), Time Phased Force Deployment Data (TPFDD) Management Tool (TMT), JOPES Permissions (JPERMS), Reference Data Editing Tool (REF), Web Scheduling and Movement (WebSM), Scheduling & Movement Interface (SMINT), JOPES Monitoring (JMON), JOPES Synchronization Processor (JSP), JOPES Subscriptions (JSUB), JOPES Data Network Services (JDNETS), and United States Transportation Command (USTRANSCOM) Unique Reports.

The Government is in possession of source code and supporting documentation for a previous JPES effort to modernize JOPES. The Government will provide this source code and supporting documentation as optional Government Furnished Information (GFI). The optional GFI developed is a distributed system utilizing modern technologies, implemented using micro services and structured with network, web, Application Programmer Interface (API), and Database layers. For the purposes of this task order, the Contractor shall analyze the optional GFI and determine re-use for the effort going forward.

The contractor shall establish a DevSecOps pipeline that can be integrated with and be synchronized with the government pipelines prior to TO 0002. This includes the unclassified pipelines and classified pipelines. A sample DevSecOps Pipeline set is shown below:

Task 1 – Enterprise Management.

Subtask 1 – Integration Management Control Planning.

The contractor shall: Provide the technical and functional activities required for integration of all tasks specified within this PWS. Include agile productivity and management methods such as quality assurance, progress/status reporting and program reviews. Provide the centralized administrative, clerical, documentation and related functions.

Subtask 2 – Task Order Management.

The contractor shall: Update the Contract Management Plan that describes the technical approach, organizational resources and management controls to be employed to meet the cost, performance and schedule requirements as well as risk identification and mitigation throughout contract execution within 30 calendar days after Task Order award. The plan’s organization resources section shall describe the mix of labor categories, labor hours, and skill sets of personnel to program and task orders. Provide a weekly status report monitoring the quality assurance, progress/status reporting and program reviews applied to the contract.

Subtask 5 – Weekly Status Report (WSR).

The Contractor shall prepare and submit a WSR to ensure an understanding of priorities and discuss activities, risks and issues that might require Government action. The report shall include a description of progress, all results, conclusions and recommendations, changes to the contractor’s organization, problem areas, programmatic risks, missed suspense, timeline slips, cost curves that reflect actual expenditures, trips, significant results, commitments, and contract schedule status. The contractor shall meet with the Government pro-gram manager on a weekly basis to review the Schedule and the Program risk and issue log. The WSR shall be delivered to the Government no later than 9:00AM each Monday and a draft shall be available for reference during any designated weekly status meeting with the Government. If Monday is a Federal Holiday, the WSR shall be delivered no later than 9:00AM the next working day. All deliverables shall be delivered in electronic media that is compatible with DISA’s local area network tools.

The WSR shall include:

Previous week’s accomplishments Current week and following week’s goals Issues requiring Government action.

Open action items New risks or changes in existing and risk management/mitigation activities (including any Supply Chain Risks) Biweekly financial report entailing current hours and financial burn rate for the previous 2 week period

Subtask 6 – Configuration Management.

The Contractor shall develop and deliver a Configuration Management Strategy (CMS) for Government approval.

The goal of Configuration Management (CM) is to define and control all components of JPES and maintain accurate configuration control of the planned and current state of the system. Well-executed CM will minimize the number of quality and compliance issues caused by incorrect and/or inaccurate configuration of the system, support better decision making and the authorization of changes, make the planning of releases more efficient and help to address software and system related defects faster. The CMS shall document the CM process to execute the following support activities:

Proper identification and documentation of system elements, interfaces, and interdependencies Timely and thorough vetting and disposition Control and documentation of approved changes to baselines Proper and timely incorporation of verified changes in all affected items and documentation Consistency between the product and its supporting documentation A complete audit trail of design decisions and modifications Use of automated tools to perform functions

The Contractor Management Strategy shall use the DISA Change Management - Process Framework instructions as guidance.

The Contractor shall document in the CMS a mechanism for recording, tracking, and reporting the status of Configuration Items (CIs). The contractor shall document in the CMS the process to maintain an up-to-date technical baseline (code, build scripts, configuration, DevSecOps Pipelines, etc.), which will include assessments, approvals, program documentation, and engineering change proposals and approvals, in accordance with Information Technology Infrastructure Library (ITIL) configuration management standards. The Contractor shall host and support a Change Control Board (CCB) to facilitate the review and approval of proposed engineering changes/processes. The CMS will cover JPES assets across the full lifecycle of the program as well as provide a complete inventory of assets and define who is responsible for their control.

Subtask 7 – Release Management.

The Contractor shall develop and deliver a Release Management Plan (RMP) that will be executed upon Government approval. The RMP shall cover the processes, systems and functions to package, build, test and deploy a re-lease into production. The RMP shall document the processes for the following activities:

Provide Release and Deployment Plans Plan Pilot Releases Coordinate on Logistics and Delivery Planning Provide Release and Build Documentation Provide Standard and Controlled Release Packages Coordinate with the Review and Closure of a Deployment

The Contractor shall maintain a deliverable tracking matrix that includes the following:

Deliverable Type (e.g. Software Package, POA&M, Security Package, Source Code, Infra-structure as Code (IaC), Delivery Automation, Pipelines, Test Automation, Configuration files, Documentation) Package/Content Name Delivery date, days late/early/on-time Status: Open/Complete, Redlines, general comments

Deliverables:

*Standard Distribution: 1 copy of the transmittal letter without the deliverable to the Contracting Officer; 1 copy of the transmittal letter with the deliverable to the Primary COR.

Task 2 – Planning and Analysis.

Subtask 1 – Integrated Master Schedule (IMS).

The Contractor shall develop and maintain an event-driven Integrated Master Schedule (IMS) that demonstrates a plan to sunset JOPES No Later Than (NLT) first quarter Fiscal Year (FY) 2023. The IMS shall be used as a primary planning and performance-monitoring tool. It shall depict and logically sequence all tasks, milestones, and critical path. It shall include appropriate resources (such as individuals or scrum teams) assigned to each task. All tasks shall be incorporated in the IMS, as well as any Government dependencies. The Contractor shall track progress in the IMS with actual percent completion of the tasks (Physical Percent Complete). The IMS shall be importable into Microsoft Project and remain fully functional with all logic, dates and functionality available to the Government.

The schedule shall be baselined at the PDR and CDR and further changes cannot be made without concurrence from the Government. When a Government approved change to the baseline is made, the Contractor shall maintain configuration control of the IMS and maintain the original baseline as well as the new change on the same IMS. Any anticipated changes to the IMS shall be communicated to the Government within three (3) working days following the identification of the change. This notification shall include risks, impacts, probability of occurrence and potential schedule recovery mechanisms if there is a schedule slip. The contractor shall identify and propose a mitigation plan for each risk and issue identified.

The IMS shall include iterative Release Plans in accordance with the Contractor's agile methodology based on a continuous development/delivery model. The IMS shall also include Contractor demonstrations of capabilities that show monthly progress towards accomplishment of the Release Plans. The IMS shall include all sprints, sprint demonstrations, deployments to the first look environment, deployments to the government provided DevSecOps environment, and test and evaluation milestones. The Contractor shall hold PDR and CDR. The dates of the PDR and CDR shall be coordinated with the COR.

Subtask 2 – Software Release Plan.

The Contractor shall develop and maintain a Software Release Plan (SRP). The SRP shall compliment the IMS in describing how each Release will be accomplished. It shall document the planned number of iterations, metrics used to achieve the capability of each iteration (i.e. story points), frequency of the releases and release schedule. The SRP shall describe the plan for the development, test and deployment of successive software releases. The SPR shall describe the agile process, deployments to the first look environment, deployments to the government provided DevSecOps environment, and test and evaluation milestones. The SRP shall be updated to reflect any changes. Any anticipated changes to the SRP shall be communicated within three (3) working days following the identification of the change and submitted along with the changes of the IMS.

Subtask 3 – Meeting Support.

The Contractor shall attend programmatic planning and scheduling meetings, Technical Exchange Meetings (TEM), and conferences. This support shall also include regular technical exchange meetings with JPES external interface partners to ensure interoperability with these partners. The contractor shall prepare meeting agendas and presentation materials, briefings, draft white papers, prepare meeting minutes to include action item lists, track action items, and participate in forums or working groups as the subject matter experts.

Subtask 4 – Requirements Management, Analysis, and Decomposition.

The Contractor shall perform industry-standard Systems Engineering functions for requirements management, analysis, and decomposition. As part of the agile DevSecOps development process, the Contractor shall continuously review, analyze and decompose the requirements throughout the period of performance.

The Contractor shall conduct detailed requirement analysis, decomposing the high level functional, external interface and systems requirements and documenting business rules, workflows, constraints in detailed user stories with acceptance criteria to complete the design and satisfy stakeholder needs. The Contractor shall utilize the Resource Allocation Workshop (RAW) packages, Force Planning & Deployment Planning/Execution Capability Definition Package (CDP), JPES Use Cases as well as other related/updated capability packages (e.g. Capability Description Documents (CDDs), Chairman of the Joint Chiefs of Staff Manuals, legacy user functional documentation, and previous GFI JIRA artifacts etc.) as a basis for requirements decomposition. Specifically, the Contractor shall comply with GFI ID#’s 11, 96, 98-102, 104-105, and 107-109.

The Contractor shall ensure traceability, linkages, and relationships are preserved between the decomposed requirements and optional GFI if applicable. The contractor shall document all requirements and analysis in a Requirements Traceability Matrix (RTM) that shows the connections between high-level requirements, detail requirements, use cases, test cases and acceptance criteria. The Contractor shall maintain the requirements on the government provided tracking system (e.g. JIRA). The Contractor shall monitor the Government System (e.g. JIRA) to receive notification on new bugs and issues.

The Contractor shall conduct an analysis of the JPES GFI provided, identify any gaps in functionality, requirements and documentation and develop a plan to either utilize the GFI or provide their own solution to ensure full compliance with the requirements of this PWS. The Contractor shall update existing deliverables with the work that needs to be accomplished in order to satisfy all requirements.

The Contractor shall provide an architecture and design based on the analysis of the requirements and optional GFI provided.

The Government will provide a product owner(s) (PO) to manage the requirements management, analysis and decomposition process. The Contractor shall meet with the Government PO at a minimum on a weekly basis to provide an update on the sprint’s activities. The Government PO will be available to support design decision making and will be the authoritative source for decisions relative to requirements interpretation and implementation. The Government PO will also be present during all sprint demonstrations, and with the COR, will be the authoritative source for acceptance of user stories, pending successful integration and testing within the Government’s DevSecOps environment.

Subtask 5 – Software Developmental Life Cycle (SDLC) Plan.

The Contractor shall deliver the SDLC plan that was described in their proposal for Government review and approval. The plan shall cover in detail how the Contractor will meet the requirements of this PWS, implement DevSecOps approaches, and manage the lifecycle of the software.

Subtask 6 – Operating in the Government DevSecOps Toolchain.

The Government seeks to apply both Agile and DevSecOps methodologies to the SDLC plan employed to integrate, build, test, deliver, and maintain the modernized JPES with the objective to provide rapid, reliable, and low-risk deliveries. The tools in the toolchain currently include: Sonarqube, GitLab, Kibana, Elasticsearch, Jfrog Artifactory, Jenkins, Fortify, LoadRunner and Selenium.

Agile Methods and Practices – The Contractor shall use industry standards and accepted (i.e., non-homegrown, proprietary) agile software development methods process and practices to provide capabilities. The Contractor shall propose, and adopt upon Government’s approval, an agile development cadence resulting in releases of deployment ready software within two to four weeks. The Contractor shall use Agile Methodology best practices to help guide them in the make-up of their cross functional feature teams.

Development Security Operations (DevSecOps) – The Government will provide the Development, Integration, and Test Environment (DI&TE), User Acceptance Testing (UAT), Pre-production, and Production environments, into which the Contractor will deliver software through automation specific to the unclassified and classified environments. The contractor shall create and maintain their own development environment for software development and pipeline authoring. The Contractor’s environment shall, through automation, synchronize source code, testing scripts, and automated pipeline orchestration scripts with the Government’s DI&TE IAW the Government provided DevSecOps CONOPS. In support of this area, the Contractor shall perform activities including:

Fully leverage DevSecOps methods and repeated practices to automate development, test and deployment Execute pipelines within the Government DevSecOps Toolchain environment as provided in the Development, Integration, and Test environment (DI&TE) Use industry best practices for Continuous Integration/Continuous Delivery (CI/CD) Make use of the Government’s choice of CI/CD software to automate the integration, test and delivery of modernized JPES code. This ensures that the tools are approved for unclassified and classified environments.

Analyze systems requirements, design, build, integrate and test software Modules, and deliver the soft-ware into the Government’s DI&TE environment, making full use of the DevSecOps toolchain via automated CI/CD pipelines Establish formal software development, code control and build processes for major and minor releases and full integration Confirm the software solution can be installed, tested and sustained in the Government’s unclassified and classified environments free of defects Check application(s) source code into the Government’s DI&TE automated code scan tool upon delivery in alignment with DevSecOps best practices to enable production of a security code scan report Perform code complexity and quality analysis using the Government’s DI&TE DevSecOps toolchain

DevSecOps Deliveries – The Contractor shall incrementally deliver their application to the Government through the Development, Integration, and Test Environments (DI&TE). The Contractor’s delivery shall take the form of committing their source code, database schema, documentation, configuration management, and Continuous Integration/Continuous Delivery (CI/CD) automation to automate build, test and deploy their application to the Government’s unclassified and classified environments. The Contractor shall produce test automation to include static analysis, unit test, integration tests, automated functional tests, dynamic analysis and compliance-as-code (compliance to security, and other policy requirements authored in automated tests). The Contractor shall submit to the DI&TE, alongside source code, and under version control, CI/CD automation that successfully executes test, build, scan and deployment activities, as specified by the Government. The Contractor shall submit deployment automation to version control for applications and execute within a DI&TE CI/CD pipeline. The Contractor shall provide lightweight documentation (e.g., markdown) including a synopsis, version description, build guidance, unit testing, installation guidance, contributor enumeration, license and/or ownership declaration with contacts and deployment instructions such as those required to execute deployment automation. The contractor shall be responsible for all code promotion from the Government’s unclassified to classified environments.

Any requirements, which do not function as specified and tested may be considered a defect. Requirements that function as tested but no longer meet the intent of the user’s requirements are not considered defects, but rather a candidate for a Change Requests (CRs). Defect Severity Levels are defined and prioritized as detailed below.

Table 1 - Severity Definitions

A serious compromise of national security, A hazardous condition that may result in fatal or serious injury to personnel or extensive damage or destruction of equipment, or A system halt (abnormal termination) in the production environment that prohibits mission accomplishments.

An additional priority rating may be provided by the operational sponsor and is used to document whether the defect discovered is of High, Medium, or Low priority. The operational sponsor can provide a priority of High to functionality, which is not catastrophic and will not impede system performance; but is a high priority to be fixed. The contractor shall provide the government product owner immediate notification of all defects. The contractor shall participate in government defect- review meetings providing the explanation of defects and a recommended severity, work-around if appropriate, and corrective plan for government approval. Severity 1 and 2 defects result in an unacceptable deliverable.

Deliverables:

*Standard Distribution: 1 copy of the transmittal letter without the deliverable to the Contracting Officer; 1 copy of the transmittal letter with the deliverable to the Primary COR.

Task 3 – Design and Architecture.

The Contractor shall engage in iterative and flexible architecture and design activities throughout the period of performance. The Contractor shall work with the Government to determine an appropriate scope for an initial preliminary architecting and design pass prior to implementing the Release Plan, which will be subject to final approval by the Government. The preliminary architecture and design shall be presented at the PDR along with the IMS and Release Plan and contain sufficient detail to transition into development iterations/sprints upon acceptance by the Government.

JPES shall be designed IAW the Force Planning & Deployment Planning / Execution Capability Definition Package (CDP) and meet or exceed the performance required by the Key Performance Parameters (KPP) as documented in the CDP, the Joint Command and Control (JC2) Capability Development Document (CDD) and the Chairman of the Joint Chiefs of Staff Manual (CJCSM) 3122.05A.

The Contractor shall employ human factors methodologies in the systems engineering process. These methodologies shall address User Interface (UI)/User Experience (UX) design of individual graphical user interfaces, overall desktop layout and associated GUI interactions, and the design of workflows involving user interaction with multiple GUIs as necessary to achieve required user tasks. The Contractor shall document the resulting specific human factors design guidance in a UI/UX development guide.

The Contractor shall design JPES to satisfy the requirements for deployment to a global enterprise with multiple synchronized instances or enclaves. The proposed JPES shall also be compatible with the Joint Command and Control (JC2) Reference Architecture and be display device agnostic. Software capability delivered under this PWS shall be web-enabled that can be equivalently exercised (graphically and functionally) across Windows, Mac, mobile devices, thick and thin clients and shall not require any additional software or plug-ins to be added beyond the standard configuration. The Contractor shall incrementally plan and deliver software that can be operated and fielded on mobile devices via standard commercial frameworks as mobility device usage within the JPEC grows over time—the mobility plan shall be incorporated in the design documents. With each subsequent Task Order of this Contract, the Contractor shall plan on increased interest in mobility devices and therefore, all design and software deliverables shall incorporate this growth. The Contractor shall ensure that the design meets requirements for deployment to virtualized instances and DDIL environments. Design considerations shall be flexible enough to incorporate future technologies with minimal/reasonable rework.

The Contractor shall ensure all sub-architectures and designs are compliant with the JC2 Reference Architecture and Joint Information Environment (JIE) implementation plan. The Contractor may propose deviations or deferrals of selected JC2 architecture specifications and requirements where technical feasibility and/or cost considerations warrant. The Government will review those recommendations and either approve or disapprove prior to the Contractor implementing.

Subtask 1 – Design Reviews and Design Documentation.

The Contractor shall conduct Preliminary and Critical Design Reviews that shall provide preliminary and critical designs that meet JPES requirements to sunset JOPES in accordance with the IMS providing the Government with insight into JPES design details. All design requirements shall be documented, as appropriate, in the design review materials (e.g. Information Assurance, JC2 Reference Architecture mapping/compliance, JIE compliance, support for DDIL users, strategy to address mobile devices, etc.)

The Contractor shall develop and update as required the relevant Department of Defense Architectural Framework (DoDAF) views in the construction of their architecture and design documents for Government review and acceptance. These views shall be integrated into the design documentation listed below. The Contractor shall develop a draft and final Information Support Plans (ISP) for Government review and acceptance. The format and content of ISP are defined in Department of Defense Instruction (DODI) 8330.01 CH-1, Interoperability of Information Technology (IT), including National Security Systems (NSS).

The Contractor shall develop, update and deliver the following documentation to support PDR and CDR:

Design Review Briefing Materials Interface Design Description (IDD) Web Services Description Document Software Design Description (SDD) Test Procedures and Test Plan Software Assurance Case Compliance Mapping to JC2 Reference Architecture and JIE DoDAF views (see Table 2 – DoDAF Views below) ISP [Architecture products required to support ISP are documented in the JITC Interoperability Process Guide (IPG)] Requirements Traceability Matrix (RTM)

The Contractor shall work with the Government to tailor the details of design deliverables to fit the agile DevSecOps methodology and avoid redundant or unnecessary documentation.

Table 2 - DoDAF Views

(Global Information Grid) GTG-F System.

*Standard Distribution: 1 copy of the transmittal letter without the deliverable to the Contracting Officer; 1 copy of the transmittal letter with the deliverable to the Primary COR.

Task 4 – Development.

The contractor shall develop and test all orchestration, test and build scripts to get from check-in of code to deployment and executing all DevSecOps best practices in between utilizing automation.

Subtask – Software Development Processes and Management.

Software Delivery – The Contractor shall implement agile development to deliver software within an incremental, fast-paced software development schedule and cadence proposed by the Contractor and approved by the Government to reduce the risk of failure. Further, the Contractor shall continually deliver these updates on a regular schedule of development sprints. The solution design shall include the ability to automatically test and deploy the system so that the Government may prioritize and focus efforts towards high value features put into production representative easily.

Software Development Methodology – To coordinate the efforts of the Government and Contract teams, the Con-tractor shall utilize the agile lifecycle management tools that the Government provides to facilitate efficient and effective coordination between development scrums and the Government Product Owners, Product Managers, Solution Managers and other Government participants. Within this tool, the Contractor shall trace systems requirements to one or more modules that consist of components that are self-contained elements with well-defined, open and published interfaces implemented using open standards.

Location – The Contractor shall identify a specific methodology to facilitate scrum meetings (daily, planning and retrospectives) at the DISA headquarters complex in Fort Meade, MD, and other similar components of the agile methodology.

Open Architecture – The Contractor shall develop and maintain an architecture that incorporates appropriate considerations for configurability, portability, maintainability, technology insertion, vendor independence, reusability, scalability, interoperability, upgradeability, and long-term supportability. Furthermore, the Contractor shall implement external information exchange requirements in a standard and open manner as part of this effort. These actions shall include planning that identifies the Contractor’s specific approach to ensuring system and interface data is well defined, available to all programs, and uses a standards-based tool for definition within the context of DoD and Service upgrade programs. The Contractor shall further ensure that its projects, at the architectural and operational level, continue to maximize the use of an open architecture as well as adoption of other standards and requirements, tailored to meet its specific Service and Joint requirements.

Modular Open Systems Approach (MOSA) – The Contractor shall describe its rationale for the modularization choices made to generate the design, including choices related to the definition of required framework APIs as well as the approach for their usage in achieving modularity requirements. The Contractor’s design approach shall produce a system that consists of hierarchical collections of software and hardware configuration items (components). These components shall be of a size that supports competitive acquisition as well as reuse. The Contractor’s design approach shall emphasize the selection of components that are available commercially or within the DoD, to avoid the need to redevelop products that already exist and that can be reused. The Contractor’s rationale shall explicitly address any tradeoffs performed, particularly those that compromise the modular and open nature of the system. Finally, the Contractor shall specify use MOSA to:

Enable the system to adapt to evolving requirements and threats Accelerate transition from science and technology into technology and deployment Facilitate systems reconfiguration and integration Reduce the development cycle time and total life cycle cost Maintain continued access to cutting edge technologies and products from multiple suppliers Mitigate the risks associated with:

Technology obsolescence, Being locked into proprietary or vendor-unique technology, and Reliance on a single source of supply over the life of the system Ensure software is built and packaged in a manner so that individual components that may not be applicable or releasable to networks other than SIPRNET (e.g. NIPR, JWICS, coalition networks) and FMS partners can be removed from the baseline Integrate capabilities provided by third-party developers Deliver a capability that can be tailored as necessary to support releasability requirements

Modular, Open Design – The Contractor shall develop an architecture that is layered and modular and uses standards-based COTS/Non-Developmental Item (NDI) hardware, operating systems, and middleware that all utilize either non-proprietary or non-vendor-unique key module or component interfaces. The modernized JPES System shall provide the basis for the modular architecture by providing an API-based structure that will be the basis for both capability development performed under this PWS as well as integration of capabilities provided by third-party developers. The Contractor’s design approach shall be applied to all subsystems and components. As part of its Open System Management Plan, the Contractor shall, at a minimum, describe how the proposed system architecture meets these goals, including the steps taken to use nonproprietary or non-vendor unique COTS or reusable NDI components wherever practicable and providing rationale for any deviation from Modular Open Design.

Module Coupling – The Contractor’s design approach shall result in modules that have minimal dependencies on other modules (loose coupling), as evidenced by simple, well-defined interfaces and by the absence of implicit data sharing. The purpose is to ensure that any changes to one module will not necessitate extensive changes to other modules, and hence facilitate module replacement and system enhancement. The approach used to determine the level of coupling and the design trade-off approach shall be described.

Inter-component Dependencies – The Contractor’s design approach shall result in a layered system design, maximizing software independence from the hardware, thereby facilitating technology refresh. The design shall be optimized at the lowest component level to minimize inter-component dependencies. The layered design shall also isolate the application software layers from the infrastructure software (such as the operating system) to enhance portability and to facilitate technology refresh. The design shall be able to survive a change to the computing infrastructure with minimal or no changes required to the application logic. The interfaces between the layers shall be built to open standards or the technical data describing the interface shall be available to the Government with unlimited rights and without proprietary markings unless otherwise approved by the Government. The system architecture shall minimize inter-component dependencies to allow components to be decoupled and reused, where appropriate, across various DoD or Service programs and platforms.

*Standard Distribution: 1 copy of the transmittal letter without the deliverable to the Contracting Officer; 1 copy of the transmittal letter with the deliverable to the Primary COR.

Task – Test and Evaluation (T&E).

The modernized JPES program conducts Developmental Test and Evaluation (DT&E) and supports Operational Test (OT) events.

The key objective of Test and Evaluation (T&E) is to find problems early in the development cycle in order to eliminate and/or preclude problems being discovered during operational testing or in the field. Further, the PMO has implemented a DevSecOps toolchain to support continuous automated testing of modernization capabilities as they are developed. The Developmental test events will be used to verify and validate Operational Test requirements that would otherwise require a separate Programmatic Operational Test activity. This section identifies the engineering activities that have been defined and continue to be refined to support rapid development of capability to the warfighter incorporating automated testing, CI/CD into the Government environment. Contractor shall provide technical expertise to multiple government acceptance test events. Test events shall be executed using CI/CD DevSecOps principles and processes. Performance metrics shall be defined by the contractor approved by the Government, collected by the contractor, and analyzed by the contractor during T&E. The Contractor shall provide input to the overall program and JITC T&E Report (e.g., test results and metrics).

The Government tests and operates in multiple enclaves/environments (NIPRNet, SIPRNet, etc.). The details on integrating with this toolchain are provided as GFI in the DevSecOps CONOPS. The test tools currently in use in the government tool chain are Selenium, SoapUI, and JMeter, Additional tools will be instantiated as required by test authorities, and the Contractor shall provide recommendations and support deployment of tools required to meet all testing requirements. The Government currently manages an unclassified toolchain and anticipates achieving a SIPRNet toolchain prior to contract award and initially fielding to a SIPRNet environment with the potential to support multiple classified environment(s) within the period of performance of this contract. The test tools on the SIPRNet toolchain will also include: Fortify, LoadRunner and Unified Functional Test. The goal of this Task Order (TO 0001) is to test the integration, sync & execution of the complete toolchains. Test results that provide evaluation of functional capabilities will be utilized only to the extent to ensure proper operation of and completeness of the test execution.

Subtask 1 – Test Environment and Strategy.

The Contractor shall design and maintain a DevSecOps Test Strategy supporting the DevSecOps processes delivered in the Development task above and specified in the DevSecOps CONOPS. The strategy shall maximize automation to realize CI/CD using the toolchain, within the DI&TE. It is anticipated that the program will have at least 3, but no more than 5 test environments. With a goal of continuous deployment, the Contractor shall include automated test cases/scripts to validate all functionality (regression test) with the delivery of each sprint.

Test Plans – The Contractor shall generate Test Plans. The Contractor DevSecOps Test Strategy and Test Plans shall align with the Integrated Master Schedule (IMS) identifying the automation strategy and required time to facilitate little to no defect discovery during Government testing. Tests shall include functional, performance (load, stress, volume, and response time), regression, user acceptance, security, penetration, failover, continuity of operations (COOP), and interoperability testing. The Contractor shall provide a DevSecOps Test Strategy document that details testing from unit testing to deployment, in alignment with the Government’s DevSecOps CONOPS and JPES Test and Evaluation Master Plan (TEMP). Upon Government approval, the Contractor shall implement the processes as documented in the strategy.

Test Process Improvement – The Contractor shall evaluate new and existing tools and services to support automating tests and present their findings to the Government to include but not be limited to tool requirements, operations, cost estimate and impacts to the Program’s DevSecOps process. Upon Government approval, the Government will implement the new test tools and changes to the DevSecOps process in the Government toolchain and the contractor shall update the automation scripts to generate the government pipeline.

Defect Tracking – The Contractor shall develop a systematic approach and metrics for tracking defect rates, trends, resolution times and release cycles, and document and implement fixes as prioritized by the Government.

Deliverables:

*Standard Distribution: 1 copy of the transmittal letter without the deliverable to the Contracting Officer; 1 copy of the transmittal letter with the deliverable to the Primary COR.

Task 6 – Deployment The Contractor shall develop orchestration scripts to deploy JPES. Deployment assistance shall include technical support and subject matter expertise to the Government while the Government deploys JPES to an operational hosting provider such as a DISA EcoSystems, DISA milCloud environment, a forward operational hosting facility, etc. The Deployment Support Report shall document what went well, what issues were encountered, how they were resolved, recommendations for future deployments, and the amount and type of support provided.

Subtask 1 – Software Delivery.

While code is constantly being checked in, built, tested and deployed into the government provided Development, Integration and Testing Environments (DI&TE) (SIPR/NIPR), official deliveries may be required on as needed basis. Versioning and Infrastructure as Code (IaC) will be utilized to freeze code builds for acceptance testing.

In accordance with the Release Plans, for each official software delivery to the Government, the Contractor shall support the Government with installation of the software. All official software deliveries shall include a completed Official Delivery Checklist (provided as GFI), as the contractor is constantly synchronizing code into the government environment constantly, no separate software deliveries are required.