IPPS-A CS BRIDGE PWS V9.0 (REV 20241024).pdf

0001- PWS - IPPS-A Increment II Contract:

Integrated Personnel and Pay

System-Army (IPPS-A)

Performance Work Statement for

Training, Deployment, Sustainment (TDS) System Integration and Solution Delivery

DRAFT Bridge Contract

27 August 2024

0001 - PWS - IPPS-A Increment II Contract:

27 August 2024 i

Table of Contents

1.0 INTRODUCTION

2.0 BACKGROUND

3.0 SCOPE

4.0 PERFORMANCE REQUIREMENTS

4.1 Task 01 – Program Management

4.1.1 Transition Out Plan

4.1.2 Monthly Program Reviews

4.1.3 Risk and Issue Management

4.1.4 Quality Assurance

4.1.5 Government Governance Boards and Meeting Cadence

4.1.6 Program Metrics

4.1.7 Project Planning and Roadmap

4.1.8 Cost and Software Data Reporting (CSDR)

4.2 Task 02 – System Baseline & Environment Management

4.2.1 Sustainment Planning

4.2.2 Sustainment

4.2.2.1 Operations Support

4.2.2.2 Production Operational Performance Monitoring Report

4.2.3 Cybersecurity

4.2.3.1 Cybersecurity Personnel

4.2.3.2 Cybersecurity Support

4.2.3.3 Risk Management Framework

4.2.3.4 Security Technical Implementation Guidelines (STIGs)

4.2.3.5 Information Assurance Vulnerability Alerts and Bulletins

4.2.3.6 Cyber Security Monthly Status Report

4.2.3.7 SIPRNet Customer Connection Process Guide Support

4.2.3.8 Cross Domain Solution Support

4.2.3.9 Program Protection Implementation Plan

4.2.4 Application Security

4.2.4.1 Provisioning

4.2.4.2 Roles and Permissions Guide

27 August 2024 ii

4.2.5 Auditing

4.2.6 Environments

4.2.7 Disaster Recovery

4.3 Task 03 – Systems Engineering and Build Support

4.3.1 Systems Engineering and Build Support

4.3.1.1 Systems Engineering and Build Support Services

4.3.1.2 Resource Capacity Planning

4.3.1.3 Systems Engineering Management Plan

4.3.1.4 Requirements Management

4.3.1.5 Design Documentation

4.3.1.6 Interface Design Document Development

4.3.1.7 Data Archiving

4.3.1.8 Software Development Plan

4.3.1.9 Software Configuration and Development

4.3.1.10 Configuration Migration

4.3.1.11 Domain Values

4.3.1.12 Configuration Status Accounting

4.3.1.13 Enterprise Service Bus

4.3.2 Technical Architecture

4.3.2.1 Technical Architecture Specification

4.3.3 Data Dictionary and DoDAF Enterprise Architecture

4.3.4 Test and Evaluation

4.4 Task 04 – Solution Integration & Release Management

4.4.1 System Integration

4.4.2 Data Conversion and Interface Plan

4.4.3 Release Management

4.4.4 Training and Deployment

4.4.4.1 Deployment

4.4.4.1.1 Rehearsal of Concept Drills

4.4.4.1.2 Deployment Planning

4.4.4.1.3 Deployment Execution

4.4.4.2 Training

27 August 2024 iii

4.4.4.3 Training Material Maintenance

4.4.4.4 Training Implementation

4.4.4.5 Training Product Development

4.5 Task 05 – Sensitive Activities Support

4.5.1 Sensitive Activities Team

4.5.2 Documentation

4.6 Task 06 – Platform & Software Migration (Optional)

4.6.1 Cloud Migration Services

4.7 Task 07 – Tier 2 Helpdesk and Capability Support

4.7.1 Tier 2 Helpdesk and Capability Support

4.7.2 Knowledge Management and Frequently Asked Questions

4.8 Task 08 – Knowledge Transfer (Optional)

5.0 DELIVERABLES AND CONTRACTOR MAINTAINED DOCUMENTATION 48

5.1 Deliverable Schedule

6.0 KEY PERSONNEL

7.0 PERIOD OF PERFORMANCE

8.0 PLACE OF PERFORMANCE

9.0 GOVERNMENT FURNISHED EQUIPMENT (GFE)

9.1 Facilities and Supplies

9.2 Hardware, Software, and Technology Services

9.3 Government Tools

10.0 COMPLIANCE WITH U.S. ARMY IT STANDARDS

10.1 Section 508 Compliance

11.0 QUALITY ASSURANCE

12.0 SECURITY AND PRIVACY

12.1 Contractor Security

12.2 Safeguarding Classified Information and Materials

12.3 Security Management Support

13.0 THIRD PARTY SERVICE PROVIDERS

14.0 APPLICABLE POLICIES AND PUBLICATIONS

15.0 CONTRACTOR MANPOWER REPORTING

APPENDIX A PERFORMANCE REQUIREMENTS SUMMARY ............................... A-1

27 August 2024 iv

APPENDIX B GOVERNMENT FURNISHED INFORMATION AND EQUIPMENT

ERROR! BOOKMARK NOT DEFINED.

APPENDIX C ACRONYM DEFINITIONS ...................................................................... B-1

APPENDIX D DATA AND DATA RIGHTS ..................................................................... C-1

27 August 2024 1

1.0 INTRODUCTION

The purpose of this contract is to obtain a total solution for the Training, Deployment, Sustainment TDS) System Integration and Solution Delivery to sustain the deployed baseline, implement major and minor HR Enhancements and integrate capabilities provided by other contractors for the Integrated Personnel and Pay System – Army (IPPS-A). This contract meets several Army needs to support the continued development and integration of IPPS-A including includes maintaining the integrity of the software code baseline in all environments (e.g., development, test, training, and production) as well as designing, building, testing, training, and deploying major and minor HR enhancements, and integrating new capabilities (i.e., Army Military Pay) into the deployed baseline. The integration of new or enhanced capabilities may be provided by other contractors requiring collaboration with the respective providers for successful integration into the baseline.

The contractor shall use the Agile SAFe methodology as directed by the Government to support IPPS-A efforts for identified enhancements through change requests to deliver additional integrated personnel and pay capabilities. The Army plans to use the current Army PeopleSoft

9.1 (or higher) ERP and Oracle 12c (or higher) database capabilities, along with Application Technologies outside of the core ERP, to meet user requirements for the total system. IPPS-A will be developed in Agile Sprints and deployed incrementally, delivering full integrated personnel and pay management functionality gradually in the form of multiple releases.

2.0 BACKGROUND

IPPS-A Inc II is both a Defense Business System and a National Security System (categorized as "Sensitive Activities") based on operational requirements on the Non-secure Internet Protocol Router Network (NIPRNet) and Secure Internet Protocol Router Network (SIPRNet). IPPS-A is under the Milestone Decision Authority (MDA) of the Army Acquisition Executive (AAE). It is managed by the Army Program Executive Office Enterprise Information Systems (PEO EIS), Project Manager (PM) IPPS-A, located in Arlington, VA. PEO EIS develops, acquires, and deploys tactical and management Information Technology (IT) systems and products and is a Systems Acquisition, Development, and Integration Center of Excellence. The INC II IPPS-A baseline was deployed in phases to 1.1M users in DEC 22 through JAN 23. The deployment subsumed 12 legacy systems and partially subsumed 11.

The objective of the IPPS-A program is to develop and deliver a single, integrated, multi-component personnel and pay system which streamlines Army HR, enhances the efficiency and accuracy of Army personnel and pay procedures, and supports Soldiers and their families. IPPS- A will incrementally provide personnel and pay management functionality for all Components of the Army (Active, Guard and Reserve). At Full Deployment, the total system will provide:

• Single Comprehensive Personnel and Pay Record

• Self Service Access

• Data Standardization

• Integrated Personnel and Pay

• Strength Management and Accountability

• Personnel Asset Visibility

27 August 2024 2

• Efficiencies Gained by Workflow

• Cross Component Support

• Business Process Standardization

• NIPRNet and SIPRNet Integration with Enterprise Cross Domain Support

3.0 SCOPE

The scope of this requirement includes maintaining the integrity of the baseline in all environments (e.g., development, test, training, and production) as well as designing, building, testing, training, and deploying major and minor HR enhancements, and integrating new capabilities (i.e. Army Military Pay) into the deployed baseline. The integration of new or enhanced capabilities development may include other vendors and will require collaboration with other vendors for successful integration into the baseline.

IPPS-A is managed via the Scaled Agile Framework (SAFe) methodology. The contractor shall adopt processes and procedures that complement SAFe. IPPS-A will operate in 12-week planning increments with 2-week Sprints. The contractor shall use Azure Dev Ops (ADO) to manage the baseline backlog and for integrating future capabilities. Unless specifically stated below, it is acceptable for the contractor to leverage the ADO tool for delivering metrics and for the general management of the product development in collaboration with the Government.

The following figures provide an overview of the capabilities, system interfaces, and legacy systems targeted for subsumption. Each figure indicates whether the capabilities align to the following scope areas:

• Maintain the Baseline – Represents capabilities and interfaces currently included in the baseline and subject to ongoing maintenance, break/fix, and regression testing as enhancements and new capabilities are added. It is assumed that the baseline scope for maintenance will expand as new capabilities are integrated and released.

• Work the Prioritized Backlog – Represents capabilities, interfaces, and legacy systems that require new development work to enhance and deliver continuous value to the IPPS- A users and stakeholders. The order and volume of backlog work performed under this requirement is subject to prioritization, backlog refinement, and capacity as driven be available funding.

• Integration to the Baseline – Represents capabilities, interfaces, and legacy systems that require work to integrate new/modified code, interfaces, or legacy data into the baseline for the release of value-added capability.

27 August 2024 3

Figure 1: Capability Planning for Continuous Improvement to the Baseline

The Army requires the following to deliver an TDS total solution as follows: (1) manage, (2) sustain the system baseline and perform environment management, (3) provide systems engineering and build support, (4) perform solution integration and release management, (5) provide sensitive activities support, (6) execute platform and software migration, and (7) transition IPPS-A Increment II TDS functionality.

A list of the Tasks that will be addressed in the remainder of the PWS. Example: The IPPS-A Increment II TDS total solution will encompass the following tasks:

· Task 1: Program Management

· Task 2: System Baseline & Environment Management

· Task 3: System Engineering and Build Support Services

· Task 4: Solution Integration & Release Management

· Task 5: Sensitive Activities Support

· Task 6: Platform & Software Migration (Optional)

· Task 7: Tier 2 Helpdesk and Capability Support

· Task 8: Knowledge Transfer (Optional)

CUI // Acquisition Sensitive

Controlled Unclassified Information (CUI)

HR Capability Backlog

Baseline

Army Military Pay

As of: 05JAN24

“Integration to the Baseline”Scope

Continuous Improvements subject to“Work the Prioritized Backlog” Scope

“Maintain the Baseline”Scope

Continuous Improvements & Baseline Integration Assignments/Transfers Awards/Decorations (Partial) DigitalSignature DisciplinaryActions Duty Status Hire/Rehire Job Openings/Requisitions Leave (Partial)

Mass Updates (Partial) Member Benefits (Partial) Member Restrictions Performance Evaluation (Partial) Physical Profiles Position Management Promotions/Demotions (Partial) Reporting &Analytics Retention Management (Partial)

Retirement Points (Partial) Self Service(DD 93/Address

Change/Contact Details/PARs) Separations/Retirements (Partial) Strength Management Unit Level Manning Talent Management 25 Point

- Profile/Search Match (Partial)

- Succession Planning (Partial)

Training Requirements User Security/AuditTrails Workflow/Visibility Internal Controls MILPAY (Partial) Data Services (Partial)

Allotments Allowances Base Pay Basic Allowance for Housing/

Basic Allowance for Subsistence Bonuses Collections Disability/Incapacitation Pay Duty Participation Incentives Pay Leave (Full) Leave and Earnings Statement Payroll Processing Reimbursements

Reliable Cost Estimate (Full) Reporting &Analytics Retirement Points Special Duty Pay Tax es Thrift Savings Plan/TSP Catch Up User Security/Audit Trails Workflow/Visibility Separations/Retirements (Full) Contracts Benefits (Full) Data Services (Full)

Cu rr en t B ac klo g Application Security (7 ECRs) Assignments (15 ECRs) Benefits & Pay (13 ECRs) BI Reporting (6 ECRs) CRM/ELM (1 ECRs) Foundations (13 ECRs)

Hire/Rehire (6 ECRs) Outbounds +Arch (10 ECRs) Promotions (6 ECRs) Talent Management (15 ECRs) Infrastructure (9 ECRs) 46 Uncategorized ECRs

Pr io rit ize d Pi pe lin e Pay Impacting:

Benefits & Pay (2 BPs) Talent Management (1 BP) Foundation Profile (9 BPs) Promotions (4 BPs) Hire/Rehire (4 BPs) Assignments (6 BPs) Separations/Retirements (6 BPs)

Non-pay Impacting:

Application Security (1 BP) Audit (1 BP) Internal Controls (2 BPs) Awards (2 BPs) Personnel Checklists (1 BP) Interest Inventories (1 BP) Packet Repository (1 BP)

Fu tu re Pi pe lin e Archive (2 BPs) Talent Management (13 BPs) Sponsorship (1 BP)

Assignments (2 BPs)

New Capability Development under separate contract(s)

27 August 2024 4

3.1 Contract Type

This is a Hybrid contract including Firm Fixed Price (FFP), Cost Plus Fixed Fee (CPFF) Completion, and Cost Reimbursable (no fee) line items for Travel and Other Direct Costs (ODCs).

3. 2 Expedited Delivery and Enhanced Performance The Government may utilize a FFP Expedited Delivery and Enhanced Performance (EDEP) CLIN(s) under this contract to encourage delivery of the IPPS-A Baseline development, integration, maintenance, and sustainment requirement. The Government anticipates ordering the respective CLIN, when determined applicable and appropriate, and in conjunction with a single Planning Interval (PI), Delivery Interval (DI), or 6-month transition-out period. The total ceiling value of the FFP CLIN is based upon a capped FFP amount. No more than one (1) FFP CLIN will be issued per one (1) PI/DI ordered or (1) 6-month transition out period.

Each EDEP CLIN is associated with individual PI/DIs and 6 – month Transition-out period and is payable to the Contractor after the completion of a PI/DI and/or 6-month transition-out period.

The Contractor shall exceed the Acceptable performance standard(s) as defined in the QASP for all performance metrics selected for the associated PI/DI and/or 6-month Transition-out period.

The Government reserves the right to unilaterally cancel each EDEP CLIN and de-obligate all funding under each EDEP CLIN if the Contractor does not meet all performance metrics. The Contractor shall not be entitled to payment if the quality level of the selected metrics does not at least meet the minimum threshold of Acceptable. Cancellation of this CLIN will not negatively impact the Contractor’s CPARS rating.

Metrics may include all or a combination of the performance metrics outlined in the Performance Requirement Summary of the Quality Assurance Surveillance Plan (QASP) (Contract Attachment 2).

AQLs: TBD

The Government reserves the right to add or revise the performance metrics throughout contract performance.

3.3 Period of Performance and Place of Performance

The period of performance is one twelve (12) month base period, broken into 12-week Delivery Intervals (DI)/Planning Intervals (PI) supporting all deployed functionality followed by a six (6) month transition out and knowledge transfer period, and a three-month option. The Contractor shall perform the work under this PWS at the Government’s IPPS-A Program Management Office (PMO) facility and other CONUS and OCONUS Government designated facilities.

27 August 2024 5

4.0 PERFORMANCE REQUIREMENTS

4.1 Task 01 – Program Management

The Contractor shall provide program management to support the following work areas:

4.1.1 Transition Out Plan

The Contractor shall provide an outgoing transition draft and final plan (See Section 5.1) for transitioning work from this contract to a follow-on effort. The government will provide the Contractor 30 business days’ notice via an ECR as the timeline is defined. The ECR will begin the 9-month period of transition planning (3 months) and transition execution (6 months. In accordance with the approved plan, the Contractor shall assist the Government in planning and implementing a complete transition from the existing contract to the Capability Support contract (if not awarded to the incumbent). The Transition Out Plan shall address how the Contractor will formally coordinate with the Government and incoming contractor staff and management on the transition; update manuals, procedures, and other documents to reflect the current state;

deliver copies of existing policies and procedures and Government furnished assets; deliver required metrics and statistics; transfer work in progress; conduct necessary security debriefings in accordance with the Army Program Executive Office, Enterprise Information Systems (PEO EIS) and IPPS-A Information Security Program to personnel holding security clearances; and migrate databases (if required). The Contractor shall ensure that the Transition Out Plan is current and updated with changes that occurred throughout the life of the contract.

Deliverable: Transition Out Plan – Refer to Deliverable Schedule in Section 5.1

4.1.2 Monthly Program Reviews

The Contractor shall conduct a Monthly Program Review (MPR) with IPPS-A PMO leadership to present program status, compliance with objectives, and other topics. The Contractor shall schedule the MPR, provide an agenda and presentation materials, and document results in MPR meeting minutes. The Contractor shall also participate in meetings preceding the MPR to discuss Sensitive information.

Deliverables: Monthly Program Project Review Presentation Materials – Refer to Deliverable Schedule in Section 5.1

Monthly Program Review Meeting Minutes – Refer to Deliverable Schedule in Section 5.1

4.1.3 Risk and Issue Management

The Contractor shall participate in and support the IPPS-A Risk Management program in accordance with the IPPS-A PMO Risk Management Plan, utilizing government furnished equipment. The Contractor shall share joint responsibility with the IPPS-A PMO in the identification, assessment, handling, controlling, and managing of program risks. IPPS-A is an Agile developed project and risk practices will utilize the Resolve, Own, Accept, and Mitigate (ROAM) practice as documented in the IPPS-A Risk Management Standard Operating Procedure (SOP). In addition, the Contractor shall handle risks for which they are the primary owner to avoid the risk becoming an issue and adversely impacting the program. The Contractor shall provide input to the Issue/Risk Management tool as required.

27 August 2024 6

The Contractor shall participate in and support the IPPS-A Risk Management program in accordance with the IPPS-A PMO Issue Risk Management Plan, utilizing government furnished equipment. The Contractor shall share joint responsibility with the IPPS-A PMO in the identification, prioritization and assignment, status reporting, and resolution and escalation of program issues, to include issues derived from program risks. In addition, the Contractor shall handle issues for which they are the primary owner to avoid issues adversely impacting the program.

4.1.4 Quality Assurance

The Contractor shall maintain and execute a Quality Assurance (QA) and Metrics Plan that supports the IPPS-A PMO Quality Assurance and Metrics Plan. The Plan shall include at a minimum:

• Contractor’s approach for conducting QA within the IPPS-A program

• Identification of institutionalized QA processes and procedures that ensure product quality and maturity throughout the system life cycle in accordance with CMMI Level 3

• Processes and step-by-step procedures for QA, to include how the use of metrics will influence continuous process improvement and identification of lessons learned

• Processes for validating Contractor functions performed in accordance with the approved Contractor management plans

• Identification of metrics to be collected, reporting format, and reporting frequency of each metric

• Templates for QA Review, QA Audits, QA Peer Review, and QA Metrics reports

4.1.5 Government Governance Boards and Meeting Cadence

While specific dates and schedules of meetings may change, the Government intends to hold meetings in accordance with the cadence outlined in Table 1. The Contractor’s support and integration with the Government will be based on specific agenda topics, actions, and documentation required during each meeting.

Table 1 - IPPS-A Meeting Cadence

Monday Tuesday Wednesday Thursday Friday

Week 1

TCB

SA DRB

DS

DRB

ACCB

IP IPT

DS

STS

STE

ARTS

DRB

CWG

DS

DRB

RPM

MPR

Week 2

SA DRB

DS

DRB

ACCB

IP IPT

STS

DRB

CWG

DS

Sprint Demo

SMR

DRB

RPM

27 August 2024 7

STE

ARTS

Week 3

SA DRB

DS

DRB

ACCB

IP IPT

DS

STS

STE

ARTS

DRB

CWG

DS

DRB

RPM

Week 4

SA DRB

DS

DRB

ACCB

IP IPT

DS

STS

STE

ARTS

DRB

CWG

DS

Sprint Demo

SMR

SA WPR

DRB

RPM

DS

DS

The list below provides the meeting names for the acronyms used in Table 1. The notation “(SI)” indicates the SI attends the meeting.

• Contract Working Group (CWG)

• Sprint Demo (SD) (SI)

• Sprint Metric Review (SMR) (SI)

• Defect Review Board (DRB) (SI)

• Daily Scrum (DS) (SI)

• Engineering Change Request Collaboration Board (ECR) (SI)

• Interface Partner/IPT Integrated Product Team (IP)

• Monthly Program Review (MPR) (SI)

• Release Planning Meeting (RPM)

• Sensitive Activities DRB (SA) (SI)

• Test Review Board (TRB) (SI)

• Technical Control Board (TCB) (SI)

• Solution Train Synch (STS) (SI)

• Solution Train Events (STE) (SI)

• Agile Release Train Synch (ARTS) (SI)

The Contractor shall provide meeting support and supporting material, including read-aheads and meeting minutes, for specified meetings in which the Contractor is the host.

4.1.6 Program Metrics

The Contractor shall support Agile Program Metric reporting in accordance with the Assistant Secretary of the Army (Acquisition, Logistics and Technology) Software Metrics and Management Policy. The IPPS-A program is adopting the Deputy Assistant Secretary of the Army (Data, Engineering and Software) (DASA (DES)) metrics for monitoring program health.

The tables below outline the required and optional metrics along with the data needed to perform the measurement and reporting. The Contractor shall conduct Agile practices, capture

27 August 2024 8 data (e.g. story points, defects, etc.), and provide access to the data to support program metric reporting, Table 2 - Required DASA (DES) Software Metrics

Required Software Metric

Metric Name Category Description Importance Measurement

Trend Over Time

Velocity

Software Process Metrics

Amount of work the team completes during a given period.

Note: Due to the variation of relative size (story) estimates, Velocity is team specific and should not be used to compare one team against another or for contract progress and incentives.

Key planning factor for estimating the amount of work that can move through the CI/CD Workflow

# 𝑜𝑜𝑜𝑜 𝑆𝑆𝑆𝑆𝑜𝑜𝑆𝑆𝑆𝑆 𝑃𝑃𝑜𝑜𝑃𝑃𝑃𝑃𝑆𝑆𝑃𝑃 [𝐶𝐶𝑜𝑜𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑆𝑆𝐶𝐶]

𝑆𝑆𝐶𝐶𝑆𝑆𝑃𝑃𝑃𝑃𝑆𝑆

Normalize to steady state

Defect Rate Software Quality

Number of defects created during a set interval

Improve the quality processes in the delivery flow

# 𝑜𝑜𝑜𝑜 𝐷𝐷𝐶𝐶𝑜𝑜𝐶𝐶𝐷𝐷𝑆𝑆𝑃𝑃

# 𝑜𝑜𝑜𝑜 𝐷𝐷𝐶𝐶𝐶𝐶𝐶𝐶𝑜𝑜𝑆𝑆𝐶𝐶𝐶𝐶𝑃𝑃𝑆𝑆𝑃𝑃

Decreases

Recidivism Rate

Software Quality

Percent of work returned to the developer

Indicates effectiveness of execution and adherence to acceptance criteria

# 𝑜𝑜𝑜𝑜 𝑆𝑆𝑆𝑆𝑜𝑜𝑆𝑆𝑆𝑆 𝑃𝑃𝑜𝑜𝑃𝑃𝑃𝑃𝑆𝑆𝑃𝑃 [𝑅𝑅𝐶𝐶𝑆𝑆𝑅𝑅𝑆𝑆𝑃𝑃𝐶𝐶𝑅𝑅]

# 𝑜𝑜𝑜𝑜 𝑆𝑆𝑆𝑆𝑜𝑜𝑆𝑆𝑆𝑆 𝑃𝑃𝑜𝑜𝑃𝑃𝑃𝑃𝑆𝑆𝑃𝑃 [𝐶𝐶𝑜𝑜𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑆𝑆𝐶𝐶𝑅𝑅]

Decreases

Root Cause Analysis Accuracy

Software Process Metric the percentage of identified issues where the root cause is correctly identified in the first attempt without causing additional issues.

Higher accuracy indicates that the root cause analysis process is robust and reliable.

= % 𝑅𝑅𝑜𝑜𝑜𝑜𝑆𝑆 𝐶𝐶𝐶𝐶𝑅𝑅𝑃𝑃𝐶𝐶𝑃𝑃 𝐼𝐼𝐷𝐷 𝑜𝑜𝑃𝑃𝑆𝑆𝑃𝑃𝑆𝑆 𝐶𝐶𝑆𝑆𝑆𝑆𝐶𝐶𝐶𝐶𝐶𝐶𝑆𝑆 Increases

Delivery Frequency

Software Development

Progress

The frequency that changes are delivered to production/ Operationally Relevant Environment

(ORE)

Reduce the size of delivered change, improve the feedback loop on quality and increase the

# 𝑜𝑜𝑜𝑜 𝐷𝐷𝐶𝐶𝐶𝐶𝐶𝐶𝑜𝑜𝑆𝑆𝐶𝐶𝐶𝐶𝑃𝑃𝑆𝑆𝑃𝑃 𝑆𝑆𝑜𝑜 𝑃𝑃𝑆𝑆𝑜𝑜𝑅𝑅𝑅𝑅𝐷𝐷𝑆𝑆𝑃𝑃𝑜𝑜𝑃𝑃

𝑄𝑄𝑅𝑅𝐶𝐶𝑆𝑆𝑆𝑆𝐶𝐶𝑆𝑆

Increase state

27 August 2024 9 speed of value delivery.

Mean Time to Remediate

Cybersecurity The average time it takes to repair/restore a module, component, system to functional use after a security incident

Time to respond cyber threats is critical to the security and protection of the system/data

𝑇𝑇𝑃𝑃𝐶𝐶𝐶𝐶 𝑆𝑆𝑜𝑜 𝑅𝑅𝐶𝐶𝑃𝑃𝑜𝑜𝐶𝐶𝑅𝑅𝐶𝐶

# 𝑜𝑜𝑜𝑜 𝐼𝐼𝑃𝑃𝐷𝐷𝑃𝑃𝑅𝑅𝐶𝐶𝑃𝑃𝑆𝑆𝑃𝑃

Decreases

Cost Per Release

Cost Shows the cost per release to trend over time and to compare against the value delivered per release

Provide insight into cost per delivery of a feature / capability

𝑇𝑇𝑜𝑜𝑆𝑆𝐶𝐶𝐶𝐶 𝐶𝐶𝑜𝑜𝑃𝑃𝑆𝑆 𝑇𝑇𝑜𝑜 𝐷𝐷𝐶𝐶𝑆𝑆𝐶𝐶

𝑇𝑇𝑜𝑜𝑆𝑆𝐶𝐶𝐶𝐶 𝐷𝐷𝐶𝐶𝐶𝐶𝑃𝑃𝑅𝑅𝐶𝐶𝑆𝑆𝐶𝐶𝑅𝑅 𝐹𝐹𝐶𝐶𝐶𝐶𝑆𝑆𝑅𝑅𝑆𝑆𝐶𝐶𝑃𝑃

Decreases to steady state

Level of User Satisfaction

Value Metrics This metric represents the degree of user satisfaction based on the value delivered by the product or solution.

Ensuring the user wants to use the product

𝑆𝑆𝑅𝑅𝐶𝐶 𝑜𝑜𝑜𝑜 𝑆𝑆𝐶𝐶𝑆𝑆𝑃𝑃𝑃𝑃𝑜𝑜𝐷𝐷𝐶𝐶𝑆𝑆𝑃𝑃𝑜𝑜𝑃𝑃 𝑆𝑆𝐷𝐷𝑜𝑜𝑆𝑆𝐶𝐶𝑃𝑃

# 𝑜𝑜𝑜𝑜 𝑅𝑅𝐶𝐶𝑃𝑃𝐶𝐶𝑜𝑜𝑃𝑃𝑅𝑅𝐶𝐶𝑃𝑃𝑆𝑆𝑃𝑃

Increases

The following programmatic software metrics are optional but may be updated or included to monitor a program’s success:

Table 3 - Optional DASA (DES) Software Metrics

Optional Software Metrics

Metric Name Category Description Importance Measurement

Trend Over Time

Cumulative Flow

Software Process Metrics

Shows: 1) # of stories created over time 2) # of stories completed over time 3) amount of work in

Indicates information about the amount of work moving through the team's workstream show the health of the

𝐷𝐷𝑃𝑃𝐶𝐶𝐷𝐷𝑆𝑆𝐶𝐶𝐶𝐶 𝑆𝑆ℎ𝑜𝑜𝑜𝑜𝑃𝑃𝑃𝑃𝐷𝐷 𝐻𝐻𝑃𝑃𝑃𝑃𝑆𝑆𝑜𝑜𝑆𝑆𝑆𝑆 𝑜𝑜𝑜𝑜:

# 𝑜𝑜𝑜𝑜 𝑆𝑆𝑆𝑆𝑜𝑜𝑆𝑆𝑃𝑃𝐶𝐶𝑃𝑃 𝑃𝑃𝑃𝑃 𝐵𝐵𝐶𝐶𝐷𝐷𝐵𝐵𝐶𝐶𝑜𝑜𝐷𝐷

# 𝑜𝑜𝑜𝑜 𝑆𝑆𝑆𝑆𝑜𝑜𝑆𝑆𝑃𝑃𝐶𝐶𝑃𝑃 𝑃𝑃𝑃𝑃 𝑃𝑃𝑆𝑆𝑜𝑜𝐷𝐷𝑆𝑆𝐶𝐶𝑃𝑃𝑃𝑃

# 𝑜𝑜𝑜𝑜 𝑆𝑆𝑆𝑆𝑜𝑜𝑆𝑆𝑃𝑃𝐶𝐶𝑃𝑃 𝐶𝐶𝑜𝑜𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑆𝑆𝐶𝐶𝑅𝑅

Backlog not excessively growing, and work in progress remains consistent to the number

27 August 2024 10

Metric Name Category Description Importance Measurement

Trend Over Time progress over time development cycle agile teams

Code Coverage

Software Quality

Unit and Automated Test Coverage

Best efforts made towards a bug free codebase that is repeatable build / deployment methods

# 𝑜𝑜𝑜𝑜 𝐿𝐿𝑃𝑃𝑃𝑃𝐶𝐶𝑃𝑃 𝑜𝑜𝑜𝑜 𝐶𝐶𝑜𝑜𝑅𝑅𝐶𝐶 𝐸𝐸𝐸𝐸𝐶𝐶𝐷𝐷𝑅𝑅𝑆𝑆𝐶𝐶𝑅𝑅

𝑇𝑇𝑜𝑜𝑆𝑆𝐶𝐶𝐶𝐶 𝑁𝑁𝑅𝑅𝐶𝐶𝑁𝑁𝐶𝐶𝑆𝑆 𝑜𝑜𝑜𝑜 𝐿𝐿𝑃𝑃𝑃𝑃𝐶𝐶𝑃𝑃 𝑜𝑜𝑜𝑜 𝐶𝐶𝑜𝑜𝑅𝑅𝐶𝐶

Increase

Change Fail Rate

Software Quality

The percentage of changes to the production system that fail

Identifies changes that fail in production

# 𝑜𝑜𝑜𝑜 𝐶𝐶ℎ𝐶𝐶𝑃𝑃𝐷𝐷𝐶𝐶 𝐹𝐹𝐶𝐶𝑃𝑃𝐶𝐶𝑅𝑅𝑆𝑆𝐶𝐶𝑃𝑃

# 𝑜𝑜𝑜𝑜 𝐷𝐷𝐶𝐶𝐶𝐶𝐶𝐶𝑜𝑜𝑆𝑆𝐶𝐶𝐶𝐶𝑃𝑃𝑆𝑆𝑃𝑃

Decreases

Progress Against

Roadmap

Software Development Progress

Rate features on the roadmap are delivered as planned

Ensuring Work Planned is being delivered on Time and in an acceptable manner

= 𝐹𝐹𝐶𝐶𝐶𝐶𝑆𝑆𝑅𝑅𝑆𝑆𝐶𝐶𝑃𝑃 𝑅𝑅𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑃𝑃𝐶𝐶𝑅𝑅 𝑜𝑜𝑃𝑃 𝑇𝑇𝑃𝑃𝐶𝐶𝐶𝐶 𝑅𝑅𝑃𝑃

𝑄𝑄𝑅𝑅𝐶𝐶𝑆𝑆𝑆𝑆𝐶𝐶𝑆𝑆𝐶𝐶𝑆𝑆 𝑅𝑅𝑜𝑜𝐶𝐶𝑅𝑅𝐶𝐶𝐶𝐶𝐶𝐶 𝐷𝐷𝐶𝐶𝑆𝑆𝐶𝐶𝑃𝑃

towards 1

Mean Time to Detect Cybersecurity

Amount of time it takes to discover a security incident/threat

Identifies time taken to detect cyber threats critical to the protection of the system

𝑇𝑇𝑜𝑜𝑆𝑆𝐶𝐶𝐶𝐶 𝑇𝑇𝑃𝑃𝐶𝐶𝐶𝐶 𝐵𝐵𝐶𝐶𝑆𝑆𝑜𝑜𝐶𝐶𝐶𝐶𝑃𝑃 𝐷𝐷𝐶𝐶𝑆𝑆𝐶𝐶𝐷𝐷𝑆𝑆𝑃𝑃𝑜𝑜𝑃𝑃

# 𝑜𝑜𝑜𝑜 𝐹𝐹𝐶𝐶𝑃𝑃𝐶𝐶𝑅𝑅𝑆𝑆𝐶𝐶𝑃𝑃

Cost Per Agile Team Cost

This metric shows the cost of Labor Costs per Agile Team + Non-Labor Costs Per Agile Team to develop and deliver value to the customer

Identifies costs related to the entire agile team taken to get a release to the customer

= 𝐴𝐴𝐷𝐷𝑃𝑃𝐶𝐶𝐶𝐶 𝑇𝑇𝐶𝐶𝐶𝐶𝐶𝐶 𝐶𝐶𝑜𝑜𝑃𝑃𝑆𝑆𝑃𝑃

+ 𝑁𝑁𝑜𝑜𝑃𝑃 𝐿𝐿𝐶𝐶𝑁𝑁𝑜𝑜𝑆𝑆 𝐶𝐶𝑜𝑜𝑃𝑃𝑆𝑆𝑃𝑃

state

27 August 2024 11

Metric Name Category Description Importance Measurement

Trend Over Time

Net Promoter Score

Value Metric

Customer satisfaction score that demonstrates if customers would recommend your product to other users

Identifies customer promotability of a feature

= % 𝑃𝑃𝑆𝑆𝑜𝑜𝐶𝐶𝑜𝑜𝑆𝑆𝐶𝐶𝑆𝑆𝑃𝑃 − % 𝐷𝐷𝐶𝐶𝑆𝑆𝑆𝑆𝐶𝐶𝐷𝐷𝑆𝑆𝑜𝑜𝑆𝑆𝑃𝑃

Deliverable: Program Metric Reports – Refer to Deliverable Schedule in Section 5.1

4.1.7 Project Planning and Roadmap

The Contractor shall prepare, manage, and implement a Roadmap and Prioritized Backlog in accordance with the principles outlined in the GAO Agile Assessment Guide 2024 [GAO-24- 10556].

The Contractor shall:

• Conduct rolling wave planning in conjunction with Scaled Agile Framework Planning Increment (PI) sprints and capture details for the following PI and high-level assumptions for the following two PIs during the Innovation and Planning sprint

• Utilize tools as specified and made available by the Government supporting the reporting on velocity, sprint burndown, Epic and Release Burndown, (i.e., reporting, management tools, etc.)

Deliverables: Product Roadmap - Refer to Deliverable Schedule in Section 5.1

4.1.8 Cost and Software Data Reporting (CSDR)

CSDR is the DoD system for collecting actual costs and software data and related business data.

The resulting repository serves as the primary contract cost and software data (CSD) repository for most DoD resource analysis efforts, including cost database development, applied cost estimating, cost research, program reviews, analysis of alternatives (AoA), and lifecycle cost estimates. The contractor shall systematically collect and report actual contract costs to provide DoD cost analysts with needed data to estimate future costs. The Cost and Software Data Reporting System shall comply with the criteria in the DFARS 252.234-7003, and DFARS 252.234-7004

27 August 2024 12

Contractor reports shall be prepared in accordance with the instructions contained in the DI- FNCL-81565, DI-FNCL-81566, and DI-FNCL-81765 DIDs (most current versions).

After contract award, the Contractor shall:

• Provide the final CWBS and CWBS Dictionary in accordance with the DI-MGMT-81334 DID within 60 days after contract award. Maintain and update the CWBS and CWBS Dictionary during contract execution. Submittals will be no more frequent than CCDR reports.

• Prepare the Contract Funds Status Report (CFSR) in accordance with DI-MGMT-81468 (or most recent).

• Prepare and provide Contractor Cost Data Reports (CCDRs) in accordance with the DI- FNCL-81565, DI-FNCL- 81566, and DIFNCL-81765 DIDs (most current versions).

• Flow down CCDR requirements to any lower tier contractor that will have a contract valued at over $50 million or any contracts valued at between $7 million and $50 million that are designated by the IPPS-A PMO and DoD office as being high risk, high value, or high technical interest.

CCDR Evaluation

Throughout the contract period of performance, the contractor’s submitted Forms 1921 and 1921-1 and CWBS Dictionary will be evaluated based upon their consistence with the respective CSDR DIDs.

Deliverables: Contract Funds Status Report (CFSR) – Refer to Deliverable Schedule in Section 5.1 Contractor Business Data Report (CBDR) (DI-FNCL-81765) – Refer to Deliverable Schedule in Section 5.1 Contract Work Breakdown Structure (CWBS) and CWBS Data Dictionary – Refer to Deliverable Schedule in Section 5.1

4.2 Task 02 – System Baseline & Environment Management

4.2.1 Sustainment Planning

The Contractor shall develop and maintain a Post-Production Support Plan (PPSP) that identifies the activities, tasks, processes, procedures, and checklists required for operations and sustainment of Releases of IPPS-A. The Contractor’s Post-Production Support Plan shall include, at a minimum:

• Identification of tasks/activities roles and responsibilities

• Post-production checklists

• Identification of metrics to measure system performance, operations, and utilization

• Participation in Test Reviews, Configuration Control Boards and Defect Review Boards

• Resolution of production service requests, defects, and enhancements

• Testing and implementation of Service Packs, as required

27 August 2024 13

• Training product update, Training Environment administration and implementation

• System Administration to include Application and Database,

• Manage and maintain appropriate support and infrastructure tools

• Production Control and Table Maintenance

• Maintenance of system reference tables (metadata, lookup data, etc.)

• Assessment, test, and implementation of IAVAs, POAM monitoring and follow-up

• Operations, to include Helpdesk consistent with the approved Help Desk Support Plan

• Monthly Capacity Planning

• Updated RASCI

Deliverables: Post-Production Support Plan – Refer to Deliverable Schedule in Section 5.1

4.2.2 Sustainment

The Contractor shall sustain each IPPS-A Release that has been deployed and is in operational use. Sustainment shall be conducted in accordance with the approved Post-Production Support Plan. Sustainment for the final IPPS-A Release shall be conducted in conjunction with the Transition Out Task. All Sustainment activities shall cover the entire program including SA, AMP and VMM.

Additionally, the Contractor shall maintain any Administrator and User documentation necessary to support and maintain IPPS-A. Performance requirements and AQLs shall be reviewed with the contractor at least semi-annually, as specified in the IMS, or as requested.

The Contractor shall execute the Post-Production Support Plan for the sustainment of each deployed Release. The sustainment shall encompass activities, tasks, processes, procedures, and checklists required to sustain the IPPS-A deployed product. to include but not limited to:

4.2.2.1 Operations Support

The Contractor shall document in an SOP and provide operations support in the following areas:

• Helpdesk support Tier 2 and 3 monthly metrics, updates to Frequently Asked Questions

• Inbound and Out Bound Data interfaces to include activities required to keep the IPPS-A data current, troubleshooting and repair

• Information Assurance to include but not limited to application of STIGS, IAVA/Ms, POAMs DIACAP (or RMF as applicable) package updates

• Infrastructure support to include but not limited to Database Administration, Application Administration, and installation of patches, troubleshooting and repair. Unless otherwise specified, support will be limited to components above the Operating System level.

• Configuration Management to include but not limited to Phire migrations, CSAI reporting, maintenance of the Technical Data Package as required.

27 August 2024 14

• Support SA consistent with NIPR support services. SA support will be consistent with NIPR support services during normal business hours. The SI will respond to SEV 1 defects in SA as notified by the Government during off-duty hours.

• 24x7 IT Operations support for NIPR and SA for system monitoring and maintenance of all processing activities, interfaces, job processing, etc. 24x7 support includes both monitoring by personnel and automated system notifications.

• Closely monitor and maintain all interfaces such that data exchanges are accurate and ensure that schedules are adhered to as indicated in the design or partner agreement.

• Send notifications to concerned parties per government approved communication matrix for outages, service degradation, system updates, and customer facing system issues

• Track and manage system outages and issues according to the government approved plan

• Monitor and manage maintenance outage windows to ensure scheduled outages for maintenance are approved by the government and performed to specification and standard

• Track metrics on system issues, changes, outages to include trend analysis

• Cross functional communication regarding system issues, outages, and changes

• Report system availability monthly

• The contractor shall document and publish the scheduled jobs, timing, and dependencies

• When an operations error occurs, the contractor shall attempt to resolve the incident and enter a ticket for Defect Review Board consideration

• Trading partner collaboration on rejects/errors, reject/error resolution tool improvement, including but not limited to Ab Initio processes, staging tables, and other IPPS-A data integration points (include component CI)

Deliverables: Runbook (NIPR/SIPR)– Refer to Deliverable Schedule in Section 5.1

4.2.2.2 Production Operational Performance Monitoring Report

The Contractor shall deliver a Production Operational Performance Monitoring Report, providing monthly metrics statuses and analysis of Production Operational Performance and showing the results of executing any remedial system changes and/or performance tuning actions as needed and outlined in the Production Operational Performance Monitoring Plan.

4.2.3 Cybersecurity

The Contractor shall provide Cybersecurity services and support for IPPS-A on the Non-Secured Internet Protocol Router Network (NIPRNet) and the Secure Internet Protocol Router Network (SIPRNet) to include work in the following areas:

27 August 2024 15

4.2.3.1 Cybersecurity Personnel

The Contractor shall ensure that Cybersecurity Workforce Personnel are trained and certified in compliance with the requirements as outlined in the latest versions of DoD 8570.01-M, Army Regulation (AR) 25-2, and Army Information Assurance Best Business Practices. Cybersecurity Workforce Personnel are those individuals who will be performing tasks that will require privileged-level access into the system (i.e., Database Administrators, PeopleSoft Application System Administrators, PeopleSoft Application Security Administrators, PeopleSoft Application Migrators, and Identity Management Application Administrators).

Contractor Cybersecurity Workforce Personnel supporting the IPPS-A program will be classified into the Information Assurance Technical (IAT) Level I or II Cybersecurity Workforce category and will be required to hold a valid Cybersecurity baseline certification (i.e., A+, Network+, or Security+) on the first day the individual is on the project site. System access will not be granted to Contractor designated Cybersecurity Workforce Personnel that do not possess a valid required Cybersecurity baseline certification as previously described. The individual must also complete the appropriate Computing Environment (CE) training (i.e., Oracle Database Administrators must complete the required Oracle training) within six (6) months of assignment to the project.

The Contractor shall be responsible for maintaining and renewing Cybersecurity certifications required of Contractor IA Workforce Personnel.

4.2.3.2 Cybersecurity Support

The contractor shall provide cybersecurity personnel to support the Information System Security Manager (ISSM). Personnel must have a minimum Secret Clearance and be trained and certified in accordance with the requirements outlined in DoD 8570.01-M and AR 25-2. The Contractor ISSO shall develop documents and artifacts required to generate system authorization documentation for IPPS-A NIPRNet and SIPRNet environments and supporting local area networks, if applicable, and provide them to the Government Information System Security Manager (ISSM) for review and concurrence. The Contractor ISSO shall provide Cybersecurity support and ensure system compliance with DoD and Army Cybersecurity requirements, guidance, and directives.

4.2.3.3 Risk Management Framework

The Contractor shall provide required support to ensure that IPPS-A NIPRNet and SIPRNet environments, are fully compliant with cybersecurity standards and requirements as identified in DoD Instruction (DoDI) 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT), and AR 25-2, Information Assurance, resulting in approved security authorization packages and an Approval to Operate (ATO). The Contractor shall update the RMF packages for each of the IPPS-A Environments, as well as the hosting facilities when they are built out. Each RMF Package may include, but not be limited to, a security plan, a Security Assessment Report (SAR), supporting documentation for authorization, and a Plan of Action and Milestones (POA&M).

27 August 2024 16

4.2.3.4 Security Technical Implementation Guidelines (STIGs)

The contractor shall strictly abide by applicable Defense Information Systems Agency (DISA) or Government-selected cloud provider STIGs when installing and configuring software applications that comprise IPPS-A.

4.2.3.5 Information Assurance Vulnerability Alerts and Bulletins

The Contractor shall implement applicable Information Assurance Vulnerability Alerts and Bulletins (IAVA/Bs), and applicable vendor released security updates, fixes, patches and bundles for the application, web, and database tiers on environments within the required timeliness and scope of the contract. The Contractor shall test IAVAs and applicable security updates, fixes, vendor released patches and bundles to ensure that their installation will not negatively impact the operations of the target environments.

4.2.3.6 Cyber Security Monthly Status Report

The contractor shall provide status on the activities performed by resources for Cybersecurity services and support for IPPS-A on the Non-Secured Internet Protocol Router Network (NIPRNet) and the Secure Internet Protocol Router Network (SIPRNet) to include work in the following areas: Cybersecurity, Personnel, Cybersecurity Support, RMF, STIGs, SIPRNet Customer Connection Process Guide Support, Cross Domain Solution Support, Technical Monitoring , Continuous Monitoring Activities for implementation and ongoing execution, and Incident Response.

Deliverable: Monthly Cybersecurity Status Report –

4.2.3.7 SIPRNet Customer Connection Process Guide Support

The Contractor shall provide support to accomplish the requirements within the DISA Connection Process Guide or cloud provider equivalent. The Contractor shall complete the SIPRNet Connection Approval Process and required documents. The Contractor shall develop the security package in accordance with the aforementioned DISA guide or cloud provider equivalent. The Contractor shall populate and submit the Defense Information Systems Network (DISN) Connection Request Template. The Contractor shall obtain a “Backside” Internet Protocol (IP) address to provide to the DISA SIPRNet Support Center or cloud provider equivalent. The Contractor shall prepare the hardware and software in advance of the DISA or cloud provider Install Team arrival.

4.2.3.8 Cross Domain Solution Support

The Contractor shall support the Cross Domain Solution as part of the Technical Architecture.

Additionally, the Contractor shall provide support to the security and connection requirements as defined by the Army Cross Domain Management Office, the DISA Enterprise Connection Division Connection Process Guide Appendix K (or cloud provider equivalent), and the Unified Cross Domain Management Office. Cross Domain Solutions are defined as “an information assurance solution that provides the ability to manually and/or automatically access and provide

27 August 2024 17 transfer of data between two or more security domains differing in classification or releasability.”

The Government will provide policy on the manual transfer of data.

4.2.3.9 Program Protection Implementation Plan

The Contractor shall perform or update a criticality analysis, vulnerability assessment, risk assessment, and countermeasure selection and implementation, with assumptions, rationale, and results, before each of the Systems Engineering Technical Reviews (SETRs) defined for the program.

The Contractor shall identify the associated logic-bearing hardware, software and firmware that implements critical functions or introduces vulnerability to the associated components (designated as "critical components").

The Contractor shall demonstrate that the contractor has visibility into its supply chain for critical components, understands the risks to that supply chain, and has implemented or plans to implement risk mitigations to counter those risks.

The Contractor shall utilize the Mil-STD 882 System Safety Program definitions of criticality to mission criticality to associate the identified risk, threats, and vulnerabilities with one of the following criticality levels:

• Level I (Catastrophic) protection failure is a failure that results in total compromise of mission capability

• Level II (Critical) protection failure is a failure that results in unacceptable compromise of mission capability or significant mission degradation

• Level III (Marginal) protection failure is a failure that results in partial compromise of mission capability or partial mission degradation

• Level IV (Negligible) protection failure is a failure that results in little or no compromise of mission capability

The Contractor shall plan for and implement countermeasures which mitigate technology exploitation, supply chain and system vulnerabilities that result in the catastrophic (Level I) and critical (Level II) protection failures, including:

• The application of supply chain risk management best practices applied as appropriate to the development of the system. Supply chain risk management key practices may be found in the NIST Interagency Report 7622, Piloting Supply Chain Risk Management for Federal Information Systems, and the National Defense Industrial Association Guidebook, Engineering for System Assurance, both publicly available.

• The application of supply chain risk management best practices applied as appropriate to the development of the system. Supply chain risk management key practices may be found in the National Institute of Standards and Technology (NIST) Interagency Report 7622, Piloting Supply Chain Risk Management for Federal Information Systems, and the National Defense Industrial Association Guidebook, Engineering for System Assurance, both publicly available.

27 August 2024 18

• Risk Management in an Agile environment requires continual feedback. Agile teams utilize time boxes for short, iterative cycles of planning and addressing risks. The process consists of identifying risks, evaluating risks, identifying a risk owner and courses of action to mitigate or eliminate the risk, and documenting the risks and mitigations. This information is critical in maintaining lessons learned and knowledge management files.

Technical risk will be tracked on a Kanban board utilizing the Resolve, Own, Accept and Mitigate (ROAM) method.

• The enumeration of potential suppliers of critical components, as they are identified, including cost, schedule, and performance information relevant for choice among alternates and planned selection for the purpose of engaging with the government to develop mutually agreeable risk management plans for the suppliers to be solicited.

• The processes to control access by foreign nationals to program information, including, but not limited to, system design information, DoD-unique technology, and software or hardware used to integrate commercial technology.

• The processes and practices employed to ensure that genuine hardware, software, and logic elements will be employed in the solution and that processes and requirements for genuine components are levied upon subcontractors.

• The process used to protect unclassified DoD information in the development environment.

The Contractor shall develop a set of secure design and coding practices to be followed for implementation of Level I and II critical components, drawing upon the "top 10 secure coding practices" (https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+ Coding+Practices) and the Common Weakness Enumeration (CWE)/SysAdmin, Audit, Network, Security (SANS) top 25 most dangerous software errors (http://cwe.mitre.org/top25/index.html).

The Contractor shall develop and maintain a Program Protection Implementation Plan (PPIP) that addresses, at minimum, information to be protected, vulnerabilities, countermeasures, program protection risks, and management and implementation of the Program Protection Plan (PPP). The PPIP shall comply with and conform to the most current OSD and Deputy Assistant Secretary of Defense, Systems Engineering Program Protection Plan Guidance.

4.2.4 Application Security

The Contractor shall update and maintain the IPPS-A Application Security Plan, and IPPS-A Application Security Design.

The Application Security Plan and Design shall allow for the engineering of existing business processes, address the NIPRNet and SIPRNet, and include but not be limited to the following:

• Department Security Tree configuration and maintenance

• Query definition security

• On-Line batch process security

• Foundation tables security https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure http://cwe.mitre.org/top25/index.html

27 August 2024 19

• Password controls

• Interface security, to include Component interfaces and Integration Broker

• Workflow security

• Third Party Application Security Configuration and Integration

• Environment Inventory List with Security Function for each

• Application Security Operations Strategy

• Security and Access Controls

• Define Roles and Responsibilities

• Content Management Configuration

• User Profile Configuration

• Workflow Design and Configuration

• Security for Third Party Applications

• Portal Content Configuration

• Data Permission Security

• Security Change Management Process

• Help Desk Support Procedures

• Application Security Testing Procedures

• Application Security Audit

• Segregation of Duties

Additionally, the Contractor shall include privileged user management as part of the Application Security Plan. As a minimum, the plan must include the specific privilege user roles, IT position designation for each role, Information Assurance Workforce Training level, primary authentication mechanisms for the role, and two factor mechanisms for roles that cannot use PKI authentication. The plan shall include a roles and responsibility matrix for privilege user operation and maintenance to include quarterly tracking. The plan must be developed and agreed upon by the program’s Cybersecurity team.

Privileged users shall have the requisite SSBI for the IT Position they occupy per AR 25-2 and DoD 8570.01. Table 4.3.1 depicts the AR 25-2 General IT Positions Guidelines for Privileged Users.

27 August 2024 20

Deliverable: IPPS-A Application Security Plan –

IPPS-A Application Security Design –

Refer to Deliverable Schedule in Section 5.1

4.2.4.1 Provisioning

The Contractor shall update and maintain the IPPS-A Provisioning Plan and IPPS-A Provisioning Design.

The Contractor shall advise the Government on PeopleSoft and Third-Party Software Best Business Practices. The IPPS-A Provisioning Plan and Design shall allow for the engineering of existing business processes, address the NIPRNet and SIPRNet and include the following processes, and any additional processes as identified or defined during the updated maintain sustainment phases:

• Identity Management Architecture core IPPS-A…