JPES PWS TO2 Development 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) Development

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 and exercises. Newsgroups is an application used for collaboration on JOPES activities, maintenance, and downtime. JCRM is the joint system used to identify force requirements in support of the GFM allocation process.

For the purposes of this TO, JPES is the modernization effort to replace and sunset JOPES.

Objectives.

The objective of this Task Order (TO) is JPES Development. TO 0002 is a follow on to TO 0001 and is dependent on the TO 0001 deliverables. For this TO, the Contractor shall develop JPES based on JPES design that was agreed upon with the government as part of the TO 0001 deliverables. Any deviations from the agreed upon design shall be approved in writing by the government. The vendor shall utilize and update the unclassified and classified set of Development Security Operations (DevSecOps) pipelines that were updated, integrated or created as part of TO 0001.

Scope.

TO 0002 is for JPES development and includes all of the performance task areas listed below. This task requires the day-to-day management of the schedule and performance of the all supported tasks from the Contractor perspective. These tasks call for Agile Development and DevSecOps execution.

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 7 – Sustainment Performance Task Area 8 – Risk Management Framework (RMF)

Performance Requirements.

The Contractor shall develop JPES to replace the functionality currently resident in JOPES which 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.

This TO shall utilize the previously created and integrated unclassified and classified DevSecOps pipelines for all phases of the Software Development Lifecycle (SDLC) process.

Task 1 – Enterprise Management.

Subtask 1 – Integration Management Control Planning.

The contractor shall: Provide the technical and functional activities as 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 re-sources and management controls to be employed to meet the cost, performance and schedule requirements as well as risk identification and mitigation throughout contract execution. 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 3 – Contract Work Breakdown Structure.

The Contractor shall maintain a Contract Work Breakdown Structure (CWBS) and corresponding CWBS Dictionary. The CWBS shall be the structure for communication for this contract and be the common link that unifies the planning, scheduling, cost estimating, budgeting, contracting and performance reporting. The CWBS shall provide clear traceability of work products. The CWBS shall be no less than three (3) levels and its baseline shall be established at an Integrated Baseline Review (IBR) conducted within 30 calendar days after contract award. Upon significant deviation from the baseline or at Government request, a follow-on IBR will be held to update the baseline. The Contractor shall update the CWBS and include any changes to the contract or scope and provide the updates to the Government.

Earned Value Management.

The Contractor shall establish, maintain and use an Earned Value Management System (EVMS) for each Cost Reimbursable CLIN in compliance with the EVMS clauses invoked by this contract. The EVMS shall be linked to and supported by the Contractor’s management processes and systems to include the integrated master schedule, con-tract work breakdown structure, change management, material management, procurement, cost estimating and accounting. The correlation and integration of these systems and processes shall provide for early indication of cost and schedule problems and their relation to technical achievement. The Contractor shall develop, maintain, implement and provide the EVMS Plan.

The Contractor shall provide the following Cost Performance Reports (CPR):

CPR Format 1 - Work Breakdown Structure Oriented Report.

CPR Format 3 - Baseline Report.

CPR Format 5 - Problem Analysis Report / Variance Narrative.

The Contractor shall host the Government’s Integrated Baseline Review within 30 calendar days after task order award and annually thereafter. The date of the IBR shall be mutually agreed to by both the Government and the Contractor. The objective of the IBR is for the Contractor to demonstrate and for the Government to determine, the adequacy of the Contractor’s Performance Measurement Baseline (PMB) for meeting contract requirements. Upon significant deviation from the baseline or at Government request, a follow-on IBR will be held to update the baseline.

The Contractor shall prepare EVM documentation for and participate in the Monthly Performance Reviews (MPR’s). In the MPR’s, the following quantitative metrics will be discussed in order to gauge the progress of development: story points planned; story points completed; bugs created; bugs completed; bugs and stories added to the backlog; and bug points and story points totals on the backlog. The MPR will be used to monitor the Contractor’s ability to meet the performance requirements specified in the PWS. The Contractor shall prepare and provide the EV Metrics Calculation Sheet (template provided as GFI) on a monthly basis and provide as a read-ahead no fewer than three days prior to the scheduled MPR

At the MPR, the Contractor shall present the status of contract performance to the Government in accordance with the EVM deliverables. The MPR shall cover all work performed by the prime and any sub-Contractors for each Period of Performance. The Contractor shall ensure that the data is accurate and corresponds to the month in which expenditures were incurred.

Subtask 5 – Weekly Status Report (WSR).

The Contractor shall prepare and submit Weekly Status Reports (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 program manager on a weekly basis to review the Schedule and the Program risk and issue log. The WSR shall be delivered 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 goal of Configuration Management (CM) is to define and control all components of the JPES system and maintain accurate configuration control on the historical, 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 Contractor shall implement the Configuration Management Strategy (CMS) approved in TO 0001. Any changes to the CMS shall be submitted to the Government for approval.

The Contractor shall provide configuration and release management that apply engineering and analytical disciplines to identify, document, and verify the functional, performance, and physical characteristics of systems and associated interface systems, to control changes and nonconformance, and to track actual configurations of systems and platforms. Using the DISA Change Management - Process Framework instructions as guidance, the Contractor shall provide support that includes all activities related to CM and RM planning including: baseline management, configuration identification, configuration audits, formal reviews, engineering changes, and configuration management records and reports; and the use of automated tools to perform these functions.

The Contractor shall implement a mechanism for recording, tracking, and reporting the status of Configuration Items (CIs). The Contractor shall provide software deliveries in accordance with the requirements of this PWS and adhere to the Contractor developed and government approved CMS.

The contractor shall maintain an up-to-date technical baseline (code, build scripts, configuration, etc.), which will include assessments, approvals, program documentation, and engineering change proposals and approvals, in accordance with ITIL configuration management standards. The contractor will host and support a Change Control Board (CCB) to facilitate the review and approval of proposed engineering changes/processes. The contractor will ensure the CCB action and decisions are documented and maintained.

Configuration Management activities shall include:

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

The Contractor shall perform activities including:

Configuration Management Strategy Configuration Identification Configuration Change Management Configuration Status Accounting Configuration Verification and Audit

Subtask 7 – Release Management.

The Contractor shall maintain the Release Management Plan (RMP) approved in Task Order 0001. Any updates to the RMP shall be submitted to the Government for approval. The Contractor shall perform activities including:

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 update and maintain the event-driven Integrated Master Schedule (IMS) developed in TO 0001 in accordance with (IAW) the CWBS structure and this PWS. The IMS shall be used as a primary planning and performance-monitoring tool. The IMS shall be integrated with and used for EVMS metrics, analysis, calculations, and reporting. It shall depict and logically sequence all tasks, critical milestones, and clearly delineate the 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 through the last required delivery or end of the contract performance period, whichever is later. 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 IBR 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 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 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 Design Reviews [equivalent to a Preliminary Design Review (PDR)/Critical Design Review (CDR)] for each Release. The date of the Design Review shall be coordinated with the COR based on the specific Release contents but should be conducted early enough in the Release cycle to allow for changes, if necessary.

Subtask 2 – Software Release Plan.

The Contractor shall maintain the 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 inter-face 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 com-ply 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 update the agreed upon design from TO 0001 if government approves changes to it based on the analysis of the requirements and finding during the agile development/DevSecOps process.

The Government will provide a product owner(s) (PO) to manage the requirements management, analysis and de-composition 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 update as requested the SDLC plan that was delivered in Task Order 0001. The plan shall cover in detail how the Contractor will meet the requirements of this PWS, 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 de-liveries. The tools in the current Government DevSecOps toolchain, the Development, Integration and Test Environment (DI&TE) currently include: SonarCube, 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 implement the Government approved agile development cadence for development. Changes to the cadence shall be submitted to the Government for approval.

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) and described in the DevSecOps CONOPS 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 deployment of 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 which 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. Any updates to the approved Design and Architecture shall be submitted to the Government for approval.

JPES shall be developed by the contractor 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. Any updates to the UI/UX development guide shall be submitted to the Government for approval.

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 end-user 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 in-corporate 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.

Any updates to the documentation provided at CDR in Task Order 0001 shall be submitted to the Government for approval.

Deliverables:

(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 JPES IAW with the Design approved by the Government. The Contractor shall maintain a prototype environment ("First Look Site") for JPES that permits a limited number of stakeholders access via the internet to review and interact with the JPES software during the development process and allow the contractor to demonstrate capability as required. This is part of the DevSecOps pipeline.

In support of this area, the Contractor shall develop software that shall meet requirements as described earlier in section 6.2.4, Requirements Management, Analysis and Decomposition. Within the period of performance of this contract, the modernized JPES will realize a process improvement, and deliver capability at the sprint level, rather than waiting to consolidate into a release along with continuous deployment.

The contractor shall develop JPES functional software as well as all build, test, and orchestration 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, 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.

Wireframe and Mockup – The creation of wireframes and mockups is essential in ensuring analysis of functional requirements meets operational community needs. The Contractor shall create wireframes and mockups to provide the concept of how a functional requirement will be met. Wireframes and mockups will be coordinated with the product owner.

Open Architecture – The Contractor shall 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 de-fined, 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 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 which 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 PDR/CDR/Delivery, 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 un-limited 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.

Deliverables:

Estimate monthly

Continuously in DevSecOps toolchain, estimate updates no more than daily and no less than weekly

*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, collected, and analyzed 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 toolchain 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 sup-port 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.

Subtask 1 – Test Environment and Strategy.

The Contractor shall implement and maintain the 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.

It is anticipated that multiple test events will occur in support of Government testing. The Contractor shall provide on-site technical expertise during each test event held at the Government facility in Hanover, MD. The Contractor shall provide a trip report within 5 business days of the completion of each test event.

Test Plans – The Contractor shall maintain and implement Test Plans. The Contractor shall update the 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).

Test Artifacts – At the completion of each sprint the Contractor shall deliver the appropriate test case(s), test script(s), test tool(s) and test results to provide the completion status of each user story in the requirements tracking tool as documented in the requirements section of this document. When new test requirements are initially implemented in the tool chain, the Contractor shall conduct a Test Readiness Review (TRR) prior to the initial test event (e.g. Port approval, ACL modifications, data source connectivity, etc.). Upon approval by the Government, the contractor shall implement the TRR process. Government testing of each sprint shall serve as a milestone review for the Government and Contractor team. The Government will provide a tailored TRR checklist with entrance and exit criteria to the Contractor to prepare for the milestone.

Test Process Improvement – The Contractor shall evaluate new and…