JPES PWS Base 23Jan2020.docx

DOCX document 3 MB Posted

Attached to
Global Force Management (GFM) Draft Performance Work Statement Questions & Answers Federal contract opportunity
Solicitation number
621913301
Issued by
Defense Information Systems Agency

About this file

This notice provides three draft performance work statements for industry review related to the Global Force Management effort. The Defense Information Systems Agency intends to issue a solicitation during the second quarter of Fiscal Year 2020 for an Indefinite Delivery Indefinite Quantity single award contract with a ceiling of $45,000,000. The requirement will be solicited under North American Industry Classification System code 541512 for Computer Systems Design Services. Industry is requested to submit any questions or comments on the draft performance work statements by February 7, 2020 to help improve the final solicitation documents. Responses should reference the notice number "621913301" and "GFM" and be submitted to the provided email address. No telephonic inquiries will be accepted.

View the file

Other files for this federal contract opportunity

Other files attached to Global Force Management (GFM) Draft Performance Work Statement Questions & Answers, newest first.
File Type Posted
Draft PWS Questions 11 March 2020.xlsx XLSX spreadsheet
JPES PWS TO1 23Jan2020.docx DOCX document
JPES PWS TO2 Development 23Jan2020.docx DOCX document

On GovTribe

Work with this file on GovTribe

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

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.

Contract Title.

Global Force Management (GFM)

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.

JPES is the modernization effort for JOPES and later incorporating functionality from JCRM as well as integrating with GFM – Data Initiative efforts.

Objectives.

DISA designs, develops, fields, and sustains various C2 platforms for the Department of Defense (DoD). The goal of this effort is to modernize the aging legacy systems architecture of JOPES, Newsgroups, and JCRM to a netcentric, service-oriented architecture and deliver next generation services providing force planning, deployment planning and execution (force projection) capabilities to the warfighter. There are four main efforts for modernization:

· Replace and sunset the JOPES system with a modernized system called JPES

· Design, develop, integrate, and deploy Newsgroups capability in JPES

· Modernize JCRM and integrate in JPES

· Design, develop, integrate and deploy new GFM capabilities

The functionality within JPES must be expandable and adaptable to support future phase requirements for incorporating GFM functionality.

Scope.

The scope of this contract includes the performance task areas listed below to develop and implement a solution that meets the objectives of this PWS, achieves interoperability certification and information assurance accreditation, along with the support required to sustain a fielded solution. All hardware and hosting for the fielded solution will be provided by the Government via MilCloud or other Government furnished environment if agency direction dictates. The Government will also provide the hosting environment for operation in a Denied, Disconnected, Intermittent and Limited Bandwidth (DDIL) operational scenario. The Contractor will have access to a Secret Internet Protocol Router Network (SIPRNet) test and integration environment.

Section 5, Scope and Section 6, Performance Requirements of this PWS convey the span of requirements the Contractor shall provide under this contract. However, specific details of task assignments and deliverables will be provided within individual Task Orders. An individual Task Order may relate to a single performance task area or involve functions from multiple performance task areas listed below.

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 integrated GFM functionality. GFM functionality includes JPES, JCRM, and other GFM systems. The complete JPES capability shall replace the full functionality currently resident in JOPES IT system. This functionality shall include all of the functions of 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), United States Transportation Command (USTRANSCOM) Unique Reports, and JOPES Newsgroups. Secondarily, this functionality shall include enhancements to current JOPES IT functionality in order to maintain software currency with the evolution of the force planning, deployment planning, and execution operational processes. Thirdly, this functionality shall be expandable and adaptable to support future phased requirements for incorporating functionality from the JCRM, integration with GFM - Data Initiative data and application and new GFM capabilities.

The Government is in possession of source code and supporting documentation that will be provided to the Contractor as Optional Government Furnished Information (GFI). The 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.

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 – Contract Management Plan.

The contractor shall maintain a Contract Management Plan describing 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. 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.

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.

Subtask 4 – 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, contract 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 thirty (30) calendar days after the contract 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 (i.e.12 months for the base year). 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 Contractor shall also provide a Quantitative Review Chart (QRC) or charts of their weekly development velocity. The Contractor shall determine the quantitative development capacity per iteration/sprint of each Release utilizing a metric (such as Story Points) and documented in the QRC showing progress towards completion. Metrics should align with other artifacts such as the Software Release Plan and be used consistently and transparently to provide accurate assessment of progress and plan. This chart shall measure progress in quantitative measure completed.

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 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 Con-tractor 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 Configuration Management Strategy (CMS). Additionally, the Contractor shall document and implement a CMS for updates to any and all fielded JPES components. The Contractor’s CMS shall include provisions for recording, tracking, and reporting the status of Configuration Items (CIs) in order to ensure stability and predictability as updates are developed, tested, and delivered to the Government.

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 shall 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:

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 CMS will cover JPES assets across the full lifecycle as well as provide a complete inventory of assets and define who is responsible for their control. 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 produce and deliver a Release Management Plan (RMP) that will be executed upon Government approval. The RMP will cover the processes, systems and functions to package, build, test and deploy a re-lease into production. 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

Subtask 8 – User Assistance and Familiarization Training.

The Contractor shall provide and include user assistance training (e.g. Frequently Asked Questions, release notes and pdf-based User’s Manual) viewable through the web and downloadable for printing, and context sensitive help in JPES design with the goal that these sections can be modified/updated without a software redelivery of the entire baseline when changes are needed. The Contractor shall deliver the user assistance training with each Release, but allow for updates/changes as testers and/or operational users begin to use the system and start asking questions.

The Contractor shall perform classified and unclassified familiarization training to personnel in support of Test and Evaluation (T&E) activities. The primary purpose of this familiarization training is to familiarize personnel with JPES and to ensure personnel can execute the applicable test cases.

As JPES is developed the Contractor shall maintain a JPES First Look Site to familiarize both the user community and the training community with emerging JPES capabilities. The Contractor shall provide regular and routine up-dates to a draft JPES user’s guide during the development process. As JPES matures and is operationally deployed, the Contractor shall provide classified and unclassified familiarization training and address questions regarding JPES’s functionality and capabilities. In particular, the Joint Staff Support Center (JSSC), as the Tier 1 & 2 Help Desk, requires familiarization training in order to support operation of the system, operational monitoring and maintenance of the system.

Additionally, the DoD school houses (e.g. Joint Deployment Training Center) may get Government tasking to develop hands-on training classes of JPES. The Contractor shall support familiarization training to a maximum of 5 key trainers who will then develop JPES core curriculum.

Subtask 9 – Demonstrations, Conference and Exercises Support The Contractor shall perform classified and unclassified demonstrations of JPES to the Government on a per sprint basis showing progress towards achievement of the Release Management Plan. This shall include preparing briefing slides, drafting demonstration scripts, and conducting the demonstrations as the subject matter expert of JPES. Demonstrations shall be tailored to the intended demonstration audience. Additional demonstration support may be required at the JPEC Actions Group (JAG) hosted by the Joint Staff at Norfolk, Virginia, minimally three times annually, or virtually at other times or during the bi-weekly JPES development Integrated Product Team (IPT) meetings hosted by the Joint Staff and DISA JPES PMO. With each demonstration, the Contractor shall provide the Government with a script to allow Government personnel to try out the functionality on the Contractor’s maintained First Look Site. Feedback from the users shall be collected by the Contractor. The Government will provide guidance on prioritization of the user feedback. The Contractor shall document Lessons Learned.

The Contractor shall provide briefing slides, familiarization training, system maintenance, software troubleshooting and support, and JPES subject matter expertise to military exercises. The Contractor shall provide both classified and unclassified functional / familiarization training that is specifically tailored to the intended exercise audience. Currently, Contractor provided briefing slides, familiarization training and JPES subject matter expertise is anticipated for the Chairman's Joint Exercise Program. This may include travel to the following Combatant Command headquarters and locations:

United States Africa Command (USAFRICOM) - Stuttgart, Germany United States Central Command (USCENTCOM) - Tampa, Florida United States Cyber Command (USCYBERCOM) – Hanover, Maryland United States European Command (USEUCOM) - Stuttgart, Germany United States Indo-Pacific Command (USINDOPACOM) - Honolulu, Hawaii United States Northern Command (USNORTHCOM) - Colorado Springs, Colorado United States Southern Command (USSOUTHCOM) - Miami, FL United States Space Command (USSPACECOM) – Colorado Springs, Colorado United States Special Operations Command (USSOCOM) – Tampa, Florida United States Strategic Command (USSTRATCOM) – Omaha, Nebraska United States Transportation Command (USTRANSCOM) - O'Fallon, Illinois

Sample Deliverables:

PWS Task#
Deliverable Title
Format
Due Date
Distribution/ Copies
Frequency and Remarks
6.1.2
Contract Management Plan Update
Contractor Determined Format delivered in MS Project
Update within 30 calendar days after award
Standard Distribution*
Update required when a new Task Order is awarded
6.1.3
Contract Work Breakdown Structure and CWBS dictionary Update
Contractor Determined Format delivered in MS Excel
Update within 30 calendar days after award
Standard Distribution*
Update required within 10 calendar days after a change or IBR
6.1.4
EVMS Plan
Contractor Determined Format delivered in MS Word
Within 30 calendar days after award
Standard Distribution*
Update annually there-after or within 10 calendar days of a change
6.1.4
CPR Format 1
MS Excel IAW DID-MGMT-81466 (current revision)
Monthly, on 10th working day of each month
Standard Distribution*
Monthly
6.1.4
CPR Format 3
MS Excel IAW DID-MGMT-81466 (current revision)
Monthly, on 10th working day of each month
Standard Distribution*
Monthly
6.1.4
CPR Format 5
MS Excel IAW DID-MGMT-81466 (current revision)
Monthly, on 10th working day of each month
Standard Distribution*
Monthly
6.1.4
IBR Presentation
Contractor Determined Format delivered in MS PowerPoint
Within 30 calendar days after award
Standard Distribution*
Update Annually
6.1.4
EV Metric Calculation Sheet
Government provided templates/format (GFI)
Monthly, on 10th working day of each month and within 3 calendar days prior to MPR
Standard Distribution*
Monthly
6.1.5
Weekly Status Report
Contractor Determined Format delivered in MS Word.
Every Monday, 9 AM upon contract award
Standard Distribution*
Weekly, on 1st workday
6.1.6
Configuration Management Strategy
Contractor Determined Format delivered in MS Word.
Within 60 calendar days after award
Standard Distribution*
Update Annually
6.1.7
Release Management Plan
Contractor Determined Format delivered in MS Word.
Within 90 calendar days after award
Standard Distribution*
Update Annually
6.1.7
Deliverable Tracking Matrix
Contractor Determined Format.
Within 90 calendar days after award
Standard Distribution*
Quarterly
6.1.8
Design for User Assistance Training
Contractor Determined Format delivered in MS Word.
As scheduled in Integrated Master Schedule (IMS) to be included with Critical Design Review (CDR) Materials (see 6.2 for IMS and CDR details)
Standard Distribution*
Updates due at CDR
6.1.8
Familiarization Briefings
Contractor Determined Format delivered in MS Power Point.
As scheduled in IMS, 3 calendar days after delivery
Standard Distribution*
Estimate quarterly
6.1.9
Briefing slides
Contractor Determined Format delivered in MS Power Point.
As scheduled in IMS, 3 calendar days after delivery
Standard Distribution*
No more than bi-weekly and no less than quarterly
6.1.9
Demonstration scripts
Contractor Determined Format.
As scheduled in IMS, 3 calendar days after delivery
Standard Distribution*
No more than bi-weekly and no less than quarterly
6.1.9
Simple instructions for government to verify functionality on First Look Site
Contractor Determined Format delivered in MS Word.
As scheduled in IMS, 3 calendar days after delivery
Standard Distribution*
No more than bi-weekly and no less than quarterly
6.1.9
User Feedback List
CTR Determined Format delivered in MS Word or Excel.
As scheduled in IMS, 3 calendar days after demonstration
Standard Distribution*
No more than quarterly and no less than annually
6.1.9
Lessons Learned
CTR Determined Format delivered in MS Word.
As scheduled in IMS, 3 calendar days after demonstration
Standard Distribution*
No more than quarterly and no less than annually

*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.

**Note: For contactor’s planning purposes, these deliverables are being used as an example. The deliverables will be Task Order specific. The Government reserves the right to add or delete deliverables based on Task Order need.

Task 2 – Planning and Analysis.

Subtask 1 – Integrated Master Schedule (IMS).

The Contractor shall develop and maintain an event-driven Integrated Master Schedule (IMS) 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.

Subtask 2 – Software Release Plan.

The Contractor shall develop and maintain a Software Release Plan (SRP) that is in concert with the IMS. 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 to develop the necessary requirements deliverables. 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.

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 draft 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 maintain a SDLC plan. 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. The Contractor shall deliver an update to the SDLC plan for Government comment and acceptance before any development work is started.

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 current Government DevSecOps toolchain, the Development, Integration and Test Environment (DI&TE) 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 cross functional agile 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 shall 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 software 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 light-weight 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.

Software Acceptance – The Contractor shall provide demonstrations to show completed work and obtain feedback. The Government will only accept code that:

meets the definition of done agreed upon during sprint planning meets all user story acceptance criteria is accompanied by testing and CI/CD automation scripts that properly execute in the DI&TE passes all tests within the DI&TE as defined in the Government’s DevSecOps CONOPS

Third-party software defects – For defects associated with any third-party product incorporated in the solution, Contractor shall be responsible for repair obligations associated with the functionality of underlying third-party software products and services. 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

Severity
Impact
Definition
1
Critical
An emergency software problem that causes either:

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.

2
Major
A software problem that adversely affects the operation's accomplishment of an operational or mission essential capability specified by baseline requirements that degrades performance and for which no alternative work-around solution is known.
3
Moderate
A software problem that adversely affects the operator's accomplishment of an operational or mission essential capability specified by baseline requirements that degrade performance and for which an alternative work-around solution is known.
4
Minor
A software problem that is an operator inconvenience or annoyance and does not affect a required operational or mission essential capability.
5
Negligible
A software or documentation issue with no ill effect to the user. The issue does not affect functionality or data. It does not impact productivity or efficiency. It is merely an inconvenience. Example: Petty layout discrepancies, spelling/grammatical errors.

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.

Sample Deliverables:

PWS Task#
Deliverable Title
Format
Due Date
Distribution/Copies
Frequency and Remarks
6.2.1
Integrated Master Schedule (IMS)
Microsoft Project
30 calendar days after award
Standard Distribution*
Weekly: COB Friday
6.2.2
Software Release Plan
Contractor Determined Format delivered in MS word
30 calendar days after award
Standard Distribution*
Draft 10 days before each release. Final 10 days after each release.
6.2.3
Meeting Agendas
Contractor Determined Format delivered in MS Word
5 work days prior to meeting
Standard Distribution*
Ad Hoc basis: estimate 1-4 times a month
6.2.3
Presentation Materials
Contractor Determined Format delivered in MS Word, Power Point or Excel
3 work days prior to meeting
Standard Distribution*
Ad Hoc basis: estimate 1-4 times a month
6.2.3
White Papers
Contractor Determined Format delivered in MS Word
7 work days after request or date requested by Contractor and approved by government
Standard Distribution*
Ad Hoc basis: estimate 1-4 times a month
6.2.3
Action Items
Contractor Determined Format delivered in MS Word or Excel
1 work day following the meeting
Standard Distribution*
Ad Hoc basis: estimate 1-4 times a month
6.2.3
Meeting Minutes
Contractor Determined Format delivered in MS word
3 work days following the meeting
Standard Distribution*
Ad Hoc basis: estimate 1-4 times a month
6.2.4
User Stories
Electronic Format delivered DevSecOps toolchain
Initially within 30 calendar days after award
Standard Distribution*
Continuously in DevSecOps toolchain, estimate updates no less than daily
6.2.4
RTM
Electronic Format delivered DevSecOps toolchain
At PDR and CDR
Standard Distribution*
Continuously in DevSecOps toolchain, estimate updates no more than daily and no less than once per sprint
6.2.5
SDLC plan Update
Contractor determined format delivered in MS Word
Within 30 calendar days after award
Standard Distribution*
Update annually
6.2.6
Continuous Integration Continuous Delivery Automation (CI/CD)
Electronic Format
As determined by cadence, cadence shall be proposed by the Contractor and approved by the Government, with every code commit into government toolchain if applicable.
Standard Distribution*
Continuously in DevSecOps toolchain, updates with every code commit into government toolchain if applicable.
6.2.6
Test Automation
Electronic Format
As determined by cadence, cadence shall be proposed by the Contractor and approved by the Government, with every code commit into government toolchain if applicable.
Standard Distribution*
Continuously in DevSecOps toolchain, updates with every code commit into government toolchain if applicable.
6.2.6
Deployment Documentation
Electronic Format
Together with any CI/CD deliverables
Standard Distribution*
Continuously in DevSecOps toolchain, together with any CI/CD 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.

**Note: For contactor’s planning purposes, these deliverables are being used as an example. The deliverables will be Task Order specific. The Government reserves the right to add or delete deliverables based on Task Order need.

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 architecture 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 also 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 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.

The Contractor shall conduct Preliminary and Critical Design Reviews in accordance with the IMS providing the Government with insight into JPES design details per Release Plan. All design requirements are re-articulated and documented, as appropriate, in the critical 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 update/modify/or generate relevant Department of Defense Architectural Framework (DoDAF) views in the construction of their architecture and design documents. 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 design reviews:

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

Sample Deliverables:

PWS Task#
Deliverable Title
Format
Due Date
Distribution/Copies
Frequency and Remarks
6.3
Preliminary Design & Briefing Materials
Contractor Determined format delivered in MS Word, Power Point or Excel
Within 60 calendar days after award
Standard Distribution*
Every 9 months
6.3.1
Critical Design Review Briefing Materials
Contractor Determined format delivered in MS Word, Power Point or Excel
Within 90 calendar days after award
Standard Distribution*
Every 9 months
6.3.1
IDD
Contractor Determined format delivered in MS Word or Excel
At CDR as scheduled in IMS
Standard Distribution*
Every CDR. If any interfaces change between CDR and final delivery, the IDD shall be updated as part of final delivery
6.3.1
Web Services Description Document
Contractor Determined format delivered in MS Word or Excel
At CDR as scheduled in IMS
Standard Distribution*
Every CDR. If any interfaces change between CDR and final delivery, the Web Services Description Document shall be updated as part of final delivery
6.3.1
SDD
Contractor Determined format delivered in MS Word or Excel
At CDR as scheduled in IMS
Standard Distribution*
Every CDR. If the software design changes between CDR and final delivery, the SDD shall be updated as part of final delivery
6.3.1
Test Procedures and Test Plan
Contractor Determined format delivered in MS Word or Excel
At CDR as scheduled in IMS
Standard Distribution*
Every CDR. Update required at completion of each release
6.3.1
Software Assurance Case
Contractor Determined format delivered in MS Word or Excel
At CDR as scheduled in IMS
Standard Distribution*
Every CDR. Update required at completion of each release
6.3.1
Compliance Mapping to JC2 reference architecture and JIE
Contractor Determined format delivered in MS Word or Excel
At CDR as scheduled in IMS
Standard Distribution*
Every CDR. Update required at completion of each release
6.3.1
DoDAF views
Contractor Determined Format delivered in MagicDraw native Format .mdzip
At CDR as scheduled in IMS
Standard Distribution*
Every CDR. Update required at completion of each release
6.3.1
ISP
Contractor input data into the GIG Technical Guidance-Federation

(Global Information Grid) GTG-F System.

At CDR as scheduled in IMS
Standard Distribution*
Every CDR. Update required at completion of each release
6.3.1
RTM
Electronic Format delivered DevSecOps toolchain
At PDR and CDR
Standard Distribution*
Continuously in DevSecOps toolchain, estimate updates no more than daily and no less than once per sprint.

*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.

**Note: For contactor’s planning purposes, these deliverables are being used as an example. The deliverables will be Task Order specific. The Government reserves the right to add or delete deliverables based on Task Order need.

Task 4 – Development.

In order to achieve the objectives of this effort, the Contractor shall perform the following:

Agile DevSecOps Software Development Support – Provide development support to secure software utilizing agile methodology integrated with DevSecOps. Provide agile methodology support and specific tools to develop, execute, and integrate products into a government DevSecOps pipeline. Provide test script development and automated test environment support. While a DevSecOps toolchain will be pro-vided by the Government in the DI&TE, the contractor shall create a partial replica of the toolchain in their independent environment. The Contractor shall be responsible for creating artifacts to enable execution of a number of pipelines to meet testing requirements, as described in the DevSecOps CONOPS, including any required infrastructure components and testing tool components, written as Infrastructure as Code, to be automatically deployed and destroyed within the Government provided DI&TE. Provide support to reduce the latent defect “technical debt” of software systems.

Distributed System Development Support in Cloud Environment – Provide support to Distributed Systems architecture and development in Cloud environment, this includes distributed databases as well as distributed system interfaces.

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 .