PRPS PWS - v1.7_20241204.pdf

Purchase Request Process System (PRPS) Capability Support

Performance Work Statement (PWS)

December 2024

Name: Purchase Request Process System

Organization: AFLCMC/GBS

Address: 1865 4th St.

Bldg 14, Room 32

WPAFB, OH 45433

Executive Summary

This Performance Work Statement (PWS) covers all tasks necessary to provide system capability support, maintenance, technical refreshment and modification of the Purchase

Request Process System (PRPS), Data System Designator (DSD) D203. A more detailed depiction of PRPS is contained in the Technical Data Package (TDP) in Appendix A.

Air Force Materiel Command (AFMC) requires system capability support and maintenance support for the PRPS. PRPS is used by the Air Force Sustainment Center (AFSC) to initiate

Purchase Instruments (PIs) for weapon system spare part buys, repairs, and related services needed to support supply chain operations. This work includes converting Supply

Chain Manager functional requirements into system functionality through the Baseline

Change Request (BCR) process, correcting programing/coding errors through the

Deficiency Report (DR) process, performing technical refreshes, maintaining the system and required interfaces, as well as associated administrative functions.

Purchase Request Process System (PRPS) Capability Support

Performance Work Statement (PWS)

Prepared by:

AFLCMC/GBS

1865 4th St.

Bldg 14, Room 32

WPAFB, OH 45433

Table of Contents

1. PURPOSE

2. SCOPE

3. REQUIREMENTS / DESCRIPTION OF SERVICES

3.1 Dependencies 9

3.2 System Details 9

3.3 Systems Support 9

3.3.1 Data Analysis and Maintenance 12

3.3.2 Deficiency Reports, Jira Issues, Help Desk Tickets, and Information Support Requests

3.3.3 Rough Orders of Magnitude (ROMs) or Impact Assessments 12

3.3.4 Major System Changes and Engineering Change Proposal (ECP) 12

3.3.5 Capability Support Release Authorization 13

3.3.6 Contingency Plans 13

3.3.7 User Training 13

3.3.8 Audit Support 13

3.4 Help Desk Support 14

3.4.1 Tier I Help Desk 14

3.4.2 Tier II Help Desk 14

3.5 Systems Operations 14

3.5.1 System Monitoring and Operational Issues 14

3.5.2 Systems Administration Access 15

3.5.3 Database Administration 16

3.6 Technical Interchange Meetings (TIMs) 16

3.7 Technical Reports: White Paper (WP) 16

3.8 Contractor Provided Facility 16

3.9 Virtual Collaboration Capabilities 17

4. ENGINEERING REQUIREMENTS

4.1 Systems Engineering (SE) 17

4.1.1 Life-Cycle Systems Engineering 17

4.1.1.1 Life Cycle Documentation 18

4.1.2 Agile Engineering Process 19

4.1.3 Functional Review Board (FRB) 19

4.1.4 Change Packages (CP) 19

4.1.5 Requirements Analysis Agile Collaboration 20

4.1.6 Functional/Technical Reviews 21

4.1.7 Other Government Reviews 21

4.1.8 Business Capability Acquisition Cycle Process (BCAC) 22

4.2 Architecture and System Design 22

4.2.1 Department of Defense Architectural Framework Guidance 22

4.2.2 System Design Agile Collaboration 22

4.2.3 Database Design and Development 23

4.2.4 Training – Web Based Simulation 23

4.2.5 Air Force Cloud One & BES CI/CD Pipeline Developer Guidelines 24

4.2.6 Data Transport Common Service 25

4.2.7 Air Force Cloud One Software Upgrades 25

4.2.8 Air Force Cloud One Installation 25

4.2.9 United States Government Configuration Baseline 26

4.3 Configuration Management (CM) 26

4.3.1 Configuration Control 26

4.3.2 Software and Documentation Control and Release Procedures 26

4.4 Testing 27

4.4.1 Test Environments 27

4.4.2 Product Testing 27

4.4.2.1 Component Validation and Integration (CV&I) 27

4.4.2.2 System Integration Test (SIT) 28

4.4.2.3 Data Management Evaluation (DME) 28

4.4.2.4 Individual Component Validation (ICV) 28

4.4.2.4.1 Component Integration Testing (CIT) 28

4.4.2.4.2 Requirements Operability Test (ROT) 29

4.4.2.4.3 Regression Test (RT) 29

4.4.2.5 CV&I Sufficiency Review 29

4.4.2.6 Qualification Test and Evaluation (QT&E) 29

4.4.2.7 Full Deployment Decision (FDD) 30

4.4.2.8 Site Acceptance Test (SAT) 30

4.5 Cybersecurity 30

4.5.1 System Cybersecurity 30

4.5.2 Application Cybersecurity 31

4.5.3 Personnel and Cybersecurity 31

4.5.4 Malicious Logic Protection 32

4.5.5 Client Services Administrators (CSAs) 33

4.5.6 Security Reporting Responsibility 33

5. CONTRACTUAL REQUIREMENTS

5.1 Place of Performance 33

5.2 Normal Hours of Operation 33

5.3 Government Furnished Property 34

5.3.1 Procurement 34

5.3.2 Management of Contractor Acquired Equipment 35

5.4 Billable Hours 35

5.5 Non-Personal Services 35

5.6 Contractor Identification 35

5.7 Performance Reporting 36

5.8 Program Management / Project Management 36

5.8.1 Services Delivery Summary 36

5.8.2 Task Order Management 36

5.8.3 Documentation and Data Management 37

5.8.4 Records, Files, and Documents 37

5.8.5 Security 37

5.8.5.1 CAC Issuance 38

5.8.5.2 Adverse Information 38

5.8.5.3 Protection of System Data 39

5.8.5.4 System and Network Access Requirements 39

5.8.5.5 Foreign Nationals 39

5.8.6 Travel 39

5.8.7 Other Direct Cost (ODC) 40

5.8.8 Post Award Conference 40

5.8.9 Program Management Reviews (PMRs) 40

5.8.9.1 Weekly Status Meetings 41

5.8.9.2 Risk Management 42

5.8.9.3 Combating Trafficking in Persons 42

5.8.9.4 Service Contract Reporting 42

5.9 Training 43

5.9.1 Mission-Unique Training 43

5.9.2 Other Government-Provided Training 43

5.10 COTS Manuals and Third-Party Supplemental Data 43

5.11 Enterprise Software Initiative 43

5.12 Software License Management 44

5.13 Transition Requirements for Task Order Start-up 44

5.14 Transition Requirements for Task Order Conclusion 44

5.15 Section 508 of the Rehabilitation Act 44

5.16 Performance of Services During Crisis Declared by the President of the United States, the Secretary of Defense, or Overseas Combatant Commander 45

6. SERVICE DELIVERY SUMMARY

7. DATA DELIVERABLES

7.1 Non-Deliverable Items 50

8. APPLICABLE STANDARDS AND REFERENCES

8.1 Security Standards 54

9. PRODUCTS STANDARDS AND COMPLIANCE REQUIREMENTS

9.1 Information Assurance (IA) Technical Considerations

9.2 DoD IPv6 Requirement

9.3 Encryption Mandates

9.4 Hardware and Associated Software and Peripherals

10. Appendices

10.1 Appendix A

1. Purchase Request Process System (PRPS) Overview

1. PRPS Description 68

2. PRPS Functionality 68

3. PRPS System Criticality 69

4. PRPS Classification and Sensitivity of Data Processed 69

5. PRPS User Information 69

6. PRPS Key Performance Parameter (KPP) Information 69

7. Government Organizations that Support PRPS 71

i. Maintenance and Supply Materiel Management Branch (AFSC)

ii. Enterprise Logistics Readiness Portfolio (AFLCMC/GBS)

iii. Business and Enterprise Systems Engineering Directorate (AFLCMC/GBE)

iv. Cloud One Development, Integration, and Test (C1D)

v. Cloud One

2. PRPS Description

1. Operating Environment and Software 72

vi. Cloud Architecture

vii. Transparent Router

2. Hardware in the C1D and Cloud One Test environment 74

3. Interfaces 74

4. Protocols and Services 76

5. Remote Access 76

6. Development Tools 76

viii. Bitbucket

ix. Jenkins

x. Maven

xi. JFrog Artifactory

xii. Selenium

xiii. CycloneDX

xiv. Jira

xv. Confluence

xvi. CheckMarx

xvii. SonarQube and CAST AIP

7. Deployment Approach and Test Environments 78

3. PRPS Complexity Details

1. Software Change Report (SCR) History 78

2. Time Compliance Network Orders (TCNOs) 79

3. User Activity and Roles 80

xviii. Active Users

xix. User Roles

4. TDP Attachments

10.2 Appendix B

5. Date: 14 March 2024

6. Overview

1. Roles 86

xx. System/Application Information

xxi. Product Vision

2. Framework Chosen 88

3. Release Pre-Planning 88

4. Estimation 89

5. Product Increment Planning 89

6. Test Planning 90

7. Daily Scrum Meeting 90

8. Sprint Planning 91

9. Configuration Control Board (CCB) 92

10. Component Validation and Integration (CV&I) Sprint Review 92

11. Sprint Retrospective 93

12. Communication 94

13. Requirements and User Story Traceability 95

xxii. Requirements Traceability

xxiii. Cybersecurity Requirements

14. Help Desk/Service Desk Tickets 95

15. Tools Used to Support Agile 96

16. Security Scanning: 96

17. Delivery of Products: 97

18. Metrics: 97

19. Attachments 97

1. PURPOSE

The purpose of this Performance Work Statement (PWS) is to obtain system capability support, maintenance, and modification of the PRPS application and web-based training simulation. In addition, this contract covers support activities related to the support of PRPS in production on the Air Force

(AF) Air Force Cloud One Amazon Web Services (AWS) GovCloud to include commercial off-the-shelf

(COTS) and Open-Source Software (OSS) upgrades. PRPS became fully operational in September

2010 and is used by the Air Force Sustainment Center (AFSC) to initiate Purchase Instruments for weapon system spare part buys, repairs, and related services needed to support supply chain operations. A more detailed description of PRPS is contained in the technical data package (TDP), in

Appendix A. These services are in support of the PRPS (DSD D203) managed by AFLCMC/GBS, 1900 Founders Dr. Room 302 Kettering, OH 45420. AFLCMC/GBS will be hereafter referred to as the

Capability Delivery Team (CDT) or Capability Delivery Manager (CDM).

2. SCOPE

The scope of this task order covers all tasks necessary to provide PRPS capability support, maintenance, and modification.

3. REQUIREMENTS / DESCRIPTION OF SERVICES

The Contractor shall deliver the products and services set forth in this Performance Work Statement

(PWS) in support of the PRPS PMO. The Contractor shall be appraised at Capability Maturity Model

Integration (CMMI) Level II or higher or have a comparable documented Agile and DevSecOps system engineering process for the entire performance of the task order, to include option periods.

3.1 Dependencies

PRPS is dependent on Air Force Air Force Cloud One and their established processes and interface systems’ availability. The Contractor shall support the PRPS PMO with the PRPS application in all Air Force Cloud One environments to include the Development, Integration, Test and Production.

3.2 System Details

System details are documented in the separate TDP in Appendix A.

3.3 Systems Support

The Contractor shall design, develop, test, and support the implementation of systems and software changes, and provide problem resolutions for the existing system. The Contractor shall maintain the current baseline of the system and provide software changes and problem fixes to this baseline as required. The Contractor shall provide to the Government all developed, modified, or converted systems, source code, processes, programs, scripts, operating instructions, databases, system files, documentation, test files, and test conditions used to develop each approved systems change request.

The contractor shall work in a team-based Agile environment. The Agile methodology along with its related-processes, procedures, and metrics will be documented in the PRPS Agile Strategy in

Appendix B.

The Government will provide Product Owner(s), subject matter experts, and functional customers to participate in and support Agile processes.

The contractor shall complete specific tasks which may include the following:

1) Monitor system performance and provide operational troubleshooting support.

2) The Product Owner will specify high-level requirements/capabilities to the Agile team through the Product Backlog. Each Product Backlog Item (PBI) will contain the acceptance criteria.

PBIs may include but are not limited to Jira issues, PRPS Helpdesk tickets, Deficiency Reports

(DRs), Information Support Requests (ISRs), Baseline Change Requests (BCRs), and

Technical Change Requests (TCRs). These changes may be the result of new requirements, technologies, mandates, or required PRPS functional/process changes, which require fixes or changes to PRPS hardware, systems software, database, application code, and web-based training simulation. Consistent with Agile software development, the PBIs are ever-evolving and subject to change during the period of the contract/task order.

The contractor shall evaluate the PBIs and update the items (e.g. User Story. Etc.) with enough detail to explain the solution that will be used to accomplish the requirement (including approach, risks, and assumptions). The contractor shall work together with the Government team to refine and estimate user stories and confirm its understanding of the Government-established acceptance criteria. These acceptance criteria will specify expected functionality for a user story. The Government will identify requirements that must be met in the development of the story through the Definition of Ready/Definition of Done processes. Refer to the PRPS Agile Strategy, in Appendix B, for the Definition of Ready and the Definition of

Done.

3) Conduct software development, software security, web services development, messaging infrastructure configuration, web services testing, security layer integration, database clean-up, data wrapping, and data conversion as required.

4) Contractor must give priority resolution to any performance problems that are detected.

5) Provide documentation in accordance with the applicable Contract Data Requirements Lists

(CDRLs) that are associated with each release and submit them to the PRPS PMO for

Government approval.

6) Analyze, design, develop, test, and prepare release application software and installation artifacts. Two major releases (approximately 7,000-7,500 hours per release) and 10 minor releases (approximately 1,200-1500 hours per release) per year are projected using an Agile

DevSecOps philosophy leveraging automated testing capabilities to maximize efficiency and effectiveness to releasing the ‘Minimum Viable Product’ (MVP) content through a Continuous

Integration/Continuous Delivery Pipeline to the PRPS user community. Releases could contain multiple Change Requests (CRs) consisting of Deficiency Reports (DRs), Baseline Change

Requests (BCRs), Technical Change Requests (TCRs), Information Support Requests (ISRs), and Jira stories. Major releases should not be planned for deployment during the last quarter of the Fiscal Year (Jul–Sep). The Contractor shall accomplish 10 minor releases and one major release in the Base Period. The Contractor shall accomplish two major releases and 10 minor releases in each of the Option Years 1-4, if exercised. The Contractor shall accomplish one major release and five minor releases in the six-month extension of services Option , if exercised. Contractor will be using a government provided DSO pipeline and all Infrastructure as Code (IAC) provided by the contractor must execute in the designated DSO pipeline to successfully execute the PRPS release package through to Production.

7) Support the development and review of Interface Control Documents (ICDs) using the

Corporate Data Repository System (CDRS) or its replacement system.

8) Modify Help applications and the web-based simulation training (e.g., Computer Based Training

(CBT)) when implementation of changes to PRPS necessitate a change to the training software.

9) Maintain the development and test environment and data to be representative of the production environment.

10) Provide cloud system administration support of the Development, Integration, Test and

Production environments. The Operations Support task performed by these SAs include but should not be limited to the following:

a. Monitor the health of and troubleshoot any issues like PRPS Air Force Cloud One AWS EC2 instances and other Air Force Cloud One AWS services such as Amazon Virtual Private

Cloud (Amazon VPC), Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load

Balancing (ELB), and AWS Auto Scaling.

b. Monitor the health of and troubleshoot any issues like PRPS Air Force Cloud One AWS interface infrastructure to include AWS Simple Storage Service (S3) buckets and AWS

Simple Queue Service (SQS) queues.

c. Coordinate and collaborate with Air Force Cloud One, external interface partners and CDT personnel to troubleshoot any issues observed with the Air Force Cloud One Data Transport, Web Services like Application Programming Interfaces (APIs) and future interactions of these interface infrastructure services and components.

d. Manage resource consumption in an AWS account using tags, Amazon CloudWatch, and

AWS Trusted Advisor.

e. Monitor Time Compliance Network Orders (TCNOs), test and apply recommended security corrective actions (patches, parameter changes, etc.) to PRPS COTS and OSS products in all Cloud environments.

f. Report to the PRPS PMO the status of all issues, outages, degradations, corrective actions, and patches as applied to PRPS via automated or manual means.

11) Provide database administration to include standard database administration tasks, as well as performance monitoring and tuning and cost optimization.

12) The AF has a mandate to consolidate logistics functions with Defense Logistics Agency (DLA).

As part of this effort, PRPS must create a new communication flow with DLA’s eProcurement contract writing system. DLA’s eProcurement system will handle all purchase instruments generated in PRPS to be worked by DLA contracting organizations. The Contractor shall complete the full end-to-end PRPS requirement of this overall effort. Work for this effort will be documented as user stories, added to the product backlog and worked with the standard releases that will be in addition to the standard release cadence. The Contractor shall ensure adequate management and support necessary to complete and sustain this effort.

3.3.1 Data Analysis and Maintenance

The Contractor shall analyze and execute data maintenance actions requested, documented, and tracked via ISRs that are stored in a shared location (e.g., Information Systems

Management Tool (ISMT), SharePoint, etc.). The Deficiency Review Team (DRT) will request the Contractor review the ISR. Upon receipt of the request, the Contractor shall provide initial analysis/recommended solution for review through the shared tools. The DRT will review the analysis and provide written feedback and/or ISMT notification to the Contractor. The

Contractor shall take the appropriate action and post results to the shared location after written feedback and/or ISMT notification receipt.

3.3.2 Deficiency Reports, Jira Issues, Help Desk Tickets, and Information

Support Requests

DRs, Jira Issues, and a PRPS help desk ticket are discrepancies between delivered software and the Government requirements/exit criteria. The Contractor shall support and take action, as required, to address time-sensitive or mission-critical events such as system outages or system deficiencies designated by the Government as a high priority or those events that adversely affect the accomplishment of an essential capability.

An ISR documents a Data Maintenance Activity (DMA), which are data updates not covered by a TCR, DR, or BCR. The DRT reviews the ISR and works with the Contractor to include it in a release. The exception is an ISR written to document an “open re-occurring” issue and to request the Contractor implement an immediate fix for a known Production issue, which may turn into a work-stoppage if not addressed quickly.

The Contractor shall fix and field DRs, PRPS help desk tickets, Jira issues, and ISRs to include operational site problem analysis and resolution.

3.3.3 Rough Orders of Magnitude (ROMs) or Impact Assessments

The Contractor shall develop Rough Orders of Magnitude (ROMs) or impact assessments, as requested, for required changes to the Computer Software Products (CSP) (CDRL A040)).

These changes may be the result of new requirements/technologies, mandates, or required

PRPS functional/process changes, which require fixes or changes to PRPS hardware, systems software, database, application code, and web-based training simulation.

DELIVERABLES: Technical Report – Study/Services: Technical Solution and Rough Order of Magnitude (ROM) (CDRL A115)

3.3.4 Major System Changes and Engineering Change Proposal (ECP)

Engineering Change Proposals (ECPs) are not currently a priced requirement. Any ECPs shall be requested by the contracting officer and will result in a bilateral contract modification.

The Government anticipates that major system changes to PRPS may be required during the duration of this contract. The Government may request the Contractor analyze and propose on major system changes that are greater than the size of a major release. Proposals for major system changes will be requested by the CO.

The Contractor shall generate and/or process ECPs in accordance with the guidance provided in Military Handbook (MIL-HDBK)-61A, Configuration Management Guidance (paragraph 6.2) and Table 6-6) and Agile value and impact mapping. When authorized by the CO via request letter, the Contractor shall develop ECPs for additions to Capability Support Releases and other projects such as Financial Improvement and Audit Readiness (FIAR) Section 508

Compliance, development, or production environment migration into a Consolidated Data

Center (CDC) etc., to include an implementation schedule with start and end dates, detailed technical proposal including hours, price, technical approach, risks, and assumptions. The contractor shall deliver the proposals in the timeframe defined within the request for proposal or ECP letter.

DELIVERABLES: Engineering Change Proposal (ECP) (CDRL A003)

3.3.5 Capability Support Release Authorization

The Government will validate and prioritize the PBIs for inclusion in the Sprints/Releases as identified through the Product Backlog and related activities.

3.3.6 Contingency Plans

The Contractor shall support the PRPS PMO’s effort to update the PRPS Contingency Plans by providing technical information when requested by the PMO, but no more than once annually.

3.3.7 User Training

The Contractor may be requested to conduct training for users on specific components or other aspects of PRPS. Requirements shall include computer-based training, and tutorials.

The CO will request a proposal from the Contractor if additional training is required.

3.3.8 Audit Support

The Contractor shall, upon government request, provide evidence of programmatic due diligence in support of the PMO, Auditing agencies, and auditors to include:

1) Air Force Audit Agency (AFAA)

2) Federal Financial Management Improvement Act of 1996 (FFMIA) Compliance

3) Standard Financial Information Structure (SFIS) compliance

4) Universe of Transactions (UoT)

5) GAO FISCAM

6) Financial Improvement and Audit Readiness (FIAR)

7) Annual Independent Public Account (IPA) audits

The Contractor shall provide evidence of compliance in the form of transactional documentation and/or proof of adherence to documented procedures.

The Contractor shall provide, as required, audit support resources to include, but not limited to:

1) Pre audit and post audit overview/meetings

2) Pre audit business/IT processes and related artifact discovery/validation

3) Audit Walk-Thru participation inclusive of explanations and demonstrations resulting in artifact capture

4) Pre and Post audit business/IT artifacts creation/update in support of Provided By Client (PBC) requests

5) Assist in creation/implementation of Corrective Action Plans (CAPs) resulting from audit finding including new potential solution, possible manual work-a-rounds as well as automated improvements

3.4 Help Desk Support

3.4.1 Tier I Help Desk

The Tier 1 Help Desk is supported by the Field Assistance Service (FAS). PRPS problem tickets are submitted in the Remedy Mid-Tier system. Service Now and Cloud environment problem tickets are submitted in Jira or comparable tool.

The Contractor shall enter PRPS application software, Service Now, and Cloud environment related issues and problem tickets into Jira or comparable tool.

3.4.2 Tier II Help Desk

The DRT serves as the PRPS Tier II Help Desk and conducts weekly DRT meetings to address production problems and errors reported to the FAS Help Desk, Jira or through other sources. The Contractor shall participate in these weekly meetings and provide high level technical support to determine if problems and errors are PRPS application problems, training issues, interface problems, Cloud issues, etc.

For PRPS Tier II problems and issues, the Contractor shall conduct further analysis to determine if a problem becomes a DR, BCR, Jira ticket or ISR and post the results of their analysis in a joint Contractor/PMO shared repository within 5 days of the DRT unless additional information is required. If additional information is required, the Contractor shall submit the request to the PMO by email within 5 days of the DRT.

The Contractor shall resolve questions, issues and problems that are complex in nature and that require PRPS application-specific knowledge that is beyond the ability of the Tier I Help

Desk to resolve.

DELIVERABLES: Technical Report/Study Services: Weekly Status Report (WSR) (CDRL

A101)

3.5 Systems Operations

Systems operations requirements must comply with applicable documents and standards specified in Section 8 of this PWS.

3.5.1 System Monitoring and Operational Issues

The Contractor shall support the PMO, Cloud 1 Development (C1D), and Air Force Cloud One in monitoring of system performance and the troubleshooting of operational issues. Monitoring and analysis of the system consists of checking general health of the application, database utilization, error logs, recycle file sizes, and interface message status. The Contractor shall make cloud sizing change recommendations based on database utilization, utilization trending, and cost optimization.

In C1D and Air Force Cloud One Test environments the tools used to monitor and analyze the system include tools such as Oracle Application Express (APEX) and TOAD for database analysis and functional administration, Interface monitoring over data transport service and via

AWS Dashboard metrics pulled from AWS Simple Storage Service (S3) and AWS Simple

Queue Service (SQS). PRPS also utilizes a custom MiniServiceBus (MSB) and Transparent

Router application in C1D and Air Force Cloud One Test environment for verifying the transfer of files between PRPS and its interface partners. In the Air Force Cloud One Test environments, the tool currently used to access application logs is AWS CloudWatch. In Air

Force Cloud One Production the tools currently available to monitor and analyze the system are Oracle APEX, data transport monitoring application, AWS Dashboard metrics for the AWS

S3 buckets and AWS SQS, and AWS. The tools available in the Air Force Cloud One are subject to change.

The Contractor shall assign two, a primary and alternate, Mission Application Engineers to monitor PRPS production performance metrics and review production logs. These individuals shall be required to comply with DoDD 8570.01-M Baseline Certifications and a Secret

Clearance to obtain the Air Force Cloud One Privileged Access accounts required to access these metrics and logs.

The Contractor, the PMO and other stakeholders, as necessary, shall meet a minimum of weekly to discuss system monitoring, operational issues within C1D and Air Force Cloud One

Int, Test and Production environments, and other technical design or operational considerations.

3.5.2 Systems Administration Access

In C1D, Air Force Cloud One Integration and Air Force Cloud One Test compliant environments the Contractor shall remotely administer the AWS Elastic Compute Cloud (EC2), Virtual Private Cloud (VPC), Network Access Control List (NACL) using the toolset currently used by the customer, such as JFrog Artifactory, AWS Elastic Beanstalk with Glassfish and

ElastiCache, Git, Mailhog; configure the PRPS database instances and ensure all servers to which they have full system administration privileges have current Time Compliance Network

Orders (TCNOs) and Information Assurance Vulnerability Alerts (IAVAs).

In the Air Force Cloud One Production environment, the Contractor shall update data in the

PRPS Production database in response to ISRs and Jira tickets from the Government using

Oracle APEX.

The Contractor shall identify to the PMO all personnel requiring systems administrator access to C1D, Air Force Cloud One Integration, Test and Production environments. The Contractor shall limit systems administrator access to the minimum number of personnel required to reliably sustain PRPS. The Contractor shall submit a Department of Defense Form (DD Form)

2875, System Authorization Access Request (SAAR) and proof of certifications to the PMO for all personnel requiring Privileged Access to Air Force Cloud One environments. All contractor personnel shall resubmit 2875s yearly and in a timely fashion that prevents loss of authorization privileges.

The Contractor shall identify to the PMO all personnel that require APEX Read access to the

PRPS databases in C1D, Air Force Cloud One Test and Air Force Cloud One Production environments. In addition, the Contractor shall identify two individuals that require Write access privileged Write database access in C1D, Air Force Cloud One Test and Air Force

Cloud One Production environments. Contractor cannot authorize any code developers to have administration capabilities in any Government facilities (i.e. Zone B, Zone A, Production).

They must maintain a strict separation of duties between the Development staff and the

Operations staff.

3.5.3 Database Administration

The Contractor shall assist developers of data exposure services in engaging with the PRPS database in C1D, Air Force Cloud One Int, Air Force Cloud One Test and Air Force Cloud One

Production environments. The Contractor shall create and test backups of data, provide data cleansing services, verify data integrity, implement access controls, administer AWS Relational

Database Service (RDS), recommend, and implement cost optimization options, and populate the PRPS database with data as necessary. The Contractor shall identify and execute any fine tuning and optimization of database parameters and Structured Query Language (SQL) statements that may result in improved performance.

3.6 Technical Interchange Meetings (TIMs)

The Contractor or Government may request TIMs be convened as required for technical interchanges. The Contractor shall attend Agile meetings/activities as defined in the PRPS

Agile Strategy in Appendix B. If minutes are requested from the contractor, CDRL A100 applies.

DELIVERABLE: Report, Record of Meeting/Minutes (CDRL A100)

3.7 Technical Reports: White Paper (WP)

The Contractor shall be required on an “as requested” basis, but no more than once a year, to provide technical reports as related to PRPS. These reports shall be provided as the result of requests from the PMO and not referenced or in support of tasks identified elsewhere in this PWS.

The Contractor shall also identify the need to provide special reports to the PMO, as needed.

DELIVERABLE: Technical Report - Study/Services: White Paper (WP) (CDRL A114)

3.8 Contractor Provided Facility

During major release testing and other special PRPS events, if requested, the Contractor shall provide a dedicated conference room that shall accommodate up to 12 persons. The conference room shall:

1) Have a phone with conference call capability.

2) Have at least 2 - 4’x4’ white boards.

3) Have capability to hook up a Government laptop to provide large format display capability.

4) Have print capability from Government laptops.

5) Have secure wireless and Ethernet cable connectivity to the internet for Government laptops.

This connection must allow for encrypted USAF AFNET VPN usage by Government personnel.

The major release test events typically last six weeks. The Contractor shall implement automated testing (as applicable), automated static and dynamic cyber security scanning, and fully integrated

Developmental Test/Operational Test (DT/OT) to reduce the testing timeline.

The Contractor shall also provide scan to email capability in a space accessible to the

Government.

3.9 Virtual Collaboration Capabilities

The following collaboration capabilities shall be required throughout the task order to support Agile work teams.

1) File share capability with Read/Write access controls and CM Check Out/In capability

2) Phone teleconference capability to accommodate 20 participants

3) Screen sharing presentation capability

4) Real time text-based group collaboration capability with file and screen capture sharing

5) Issue tracking capability

All of the above capabilities shall be accessible by PMO and Functional Customer personnel from either commercial or .mil NIPRNet networks.

The Contractor shall provide solutions for these collaboration capabilities should any Government solutions become unusable or inaccessible.

4. ENGINEERING REQUIREMENTS

4.1 Systems Engineering (SE)

The PRPS PMO will rely on the Contractor’s expertise to continue more adoption of Agile and collaborative DevSecOps processes. The goal is to adopt a software Continuous Integration and

Continuous Delivery (CI/CD) philosophy that will allow for smaller and more frequent capability delivery and defect corrections without sacrificing the USAF Acquisition Process Model’s System

Engineering tenants of Reliability, Repeatability and Reproducibility.

As the BES PEO continues to update the USAF Acquisition Process Model to better align with proven Agile practices the Contractor shall participate in these processes and shall support any applicable USAF Acquisition Process Model activities as they become available.

4.1.1 Life-Cycle Systems Engineering

The Contractor shall employ disciplined Agile systems engineering processes including, but not limited to, technical planning, decision analysis, technical assessment, requirements management, risk management, configuration management, data management, interface management, requirements definition, requirements analysis, value mapping, Impact Mapping, architecture design, implementation, continuous integration/continuous delivery, verification, validation, and transition the period of performance of task orders in accordance with Air Force

Instruction (AFI) 63-101/20-101, Integrated Life Cycle Management.

The Contractor shall demonstrate an understanding of systems development methodologies to enable transformation of user requirements into software. The current methodology by the AF and PEO BES is the Agile methodology.

The Contractor shall:

A. Support the Government and its Agile delivery capability. This includes, but is not limited to:

1. support for virtual development, test, and production environments in the cloud

2. use of Agile toolsets (like Jira) to track requirements from development, through test, and finally to production

3. use of Agile toolsets (like Confluence) to provide architecture and design documents and development information

4. use of various toolsets (like SonarCube, CheckMarx, and CAST AIP) for static code analysis in the areas of performance, security, quality, and modularity

5. use of CI/CD toolsets to automated software delivery across development, test, and production environments

4.1.1.1 Life Cycle Documentation

The Contractor shall create, modify, update, and deliver software life cycle documents in accordance with respective CDRL instructions and specified content guidance.

DELIVERABLES: Software Transition Plan (STrP) (CDRL A023)

Software Requirements Specification (SRS) (CDRL A027)

Software Design Description (SDD) (CDRL A029)

Software Test Description (STD) (CDRL A033)

Computer Software Product (CSP) (CDRL A040)

Presentation Material (CDRL A099)

Report, Record of Meeting/Minutes (CDRL A100)

Product Roadmap (CDRL A116)

Technical Report/Study Services: Weekly Status Report (WSR) (CDRL A101)

Technical Report/Study Services: Change Packages (CP) (CDRL A108)

Technical Report/Study/Services: White Paper (WP) (CDRL A114)

Technical Report/Study/Services: Technical Solution and Rough Order of

Magnitude (ROM) (CDRL A115)

4.1.2 Agile Engineering Process

The Contractor shall follow a comprehensive Agile engineering process similar in breadth to at least CMMI Level II or a comparable documented Agile and DevSecOps engineering process to effectively maintain and sustain a system with the complexity of PRPS. These processes include, but are not limited to, decision analysis and resolution, integrated Project

Management, organizational process definition and focus, organizational training, continuous integration/continuous delivery, requirements and change request analysis and development, risk management, technical solution generation, and validation and verification.

The Contractor shall refer to the USAF Acquisition Process Model (APM) website for guidance, common plans, procedures, checklists, forms, and templates that the PRPS PMO employs to support system life cycle management and systems engineering processes as it applies to

Defense Acquisition, Technology, and Logistics tailored to CMMI disciplines, or be able to demonstrate comparable Agile processes and artifacts.

The Contractor shall develop solutions that employ principles of Agile software development, open technology development and a modular open systems architecture for hardware and software as described in the Department of Defense (DoD) Open Technology Development

Guidebook and Net-Centric Enterprise Solutions for Interoperability (NESI) body of knowledge.

The Contractor’s systems engineering plan and design activities shall also adhere to the DoD

Information Sharing and Net- Centric Strategies published by the DoD Chief Information

Officer (CIO), and the engineering body of knowledge and lessons-learned accumulated in

NESI.

4.1.3 Functional Review Board (FRB)

The Contractor shall participate in Functional Review Boards (FRBs) in an as-required advisory capacity to discuss problem reports, to gain an understanding of the requirements being presented in Value Mapping and Impact Mapping formats, and to provide information in support of the meeting. The Contractor’s main role shall be to provide information support for the meeting. The meetings occur weekly.

4.1.4 Change Packages (CP)

The Contractor shall document all information realized out of Agile collaboration sessions using Change Packages. A new Change Package will be created in association with each new release requirement (e.g., DRs, BCRs, TCRs). Changes Packages will document the following information:

1) Requirements Elaboration

2) System Design

3) Test Strategy

Change Packages shall be updated daily as part of Agile Collaboration Sessions. They will be uploaded and made accessible to the collaboration team via the previously mentioned File

Share Virtual Collaboration Capability under PWS Section 3.9.

Requirements Elaboration shall include but is not limited to Realized Use Cases.

System Design shall include but is not limited to Screen Mockups, Entity Relationship

Diagrams, Interface Diagrams, Example Code Changes, Impacts to Security, Impacts to

Training, etc.

Test Strategy shall include but is not limited to Requirements Traceability to the associated

Manual Test Cases/Scripts and/or Automated Test Scripts as referenced within the Software

Test Description (STD). Agile tools (e.g. Jira, Confluence, JMeter, Selenium, and BitBucket) will be leveraged to the maximum extent possible to provide insight to requirements traceability (requirements to code to test).

The Contractor shall update Draft Change Packages as Agile Collaborations Sessions progress and make them available for review by members of the Agile team at any time.

The Contractor shall roll-up all Requirements Elaboration information contained within each

Change Package into the next Software Requirements Specification (SRS) deliverable required under each Major Release.

The Contractor shall roll-up all Design information contained within each Change Package into the next Software Design Description (SDD) deliverable required under each Major Release.

The Contractor shall document all Test Strategy information realized under Agile Collaboration

Sessions within the Change Package associated with each release requirement (e.g., DRs, BCRs, TCRs). This Test Strategy information should include references to existing, updated or new test scripts as documented within the Software Test Description (STD) deliverable required with every Minor and Major release.

Change Packages for both Draft and Final deliverables shall be made available through the appropriate Agile tool (Confluence, Jira, etc.) and communicated through a delivery letter showing the information available and the location of that information in the Agile tool set.

DELIVERABLES:

Technical Report/Study Services: Change Packages (CP) (CDRL A108)

Software Requirements Specification (SRS) (CDRL A027)

Software Design Description (SDD) (CDRL A029)

Software Test Description (STD) (CDRL A033)

4.1.5 Requirements Analysis Agile Collaboration

The Contractor shall utilize an Agile process that includes users (or their representatives) and PRPS PMO participation to analyze the functional and technical requirements associated with change requests. The goal is to ultimately reduce the time required under the previous requirements design process while continuing to make sure the requirement is clear and testable.

The Contractor shall lead the Requirements Elaboration process with the PRPS PMO and

Functional and Technical customer participants (or their representatives), to ensure requirements are sufficiently documented and identify the appropriate system (to include Air

Force Cloud One Services) or interface processes affected using Value Mapping and Impact

Mapping. This includes identifying the impacts all Government Requirement Exit /

Acceptance Criteria (Exit Criteria) have on every proposed requirement.

The Contractor shall document all Requirements Elaboration information realized under

Agile collaboration sessions within the Change Package associated with each release requirement (e.g., DRs, BCRs, TCRs).

The Contractor shall roll-up all Requirements Elaboration information contained within each

Change Package into the next SRS deliverable required under each Major Release.

The Contractor shall document all Test Strategy information realized under Agile collaboration sessions within the Change Package associated with each release requirement

(e.g., DRs, BCRs, TCRs). This Test Strategy information should include references to existing, updated, or new test scripts as documented within the STD deliverable required with every minor and major release.

DELIVERABLES: Report, Record of Meeting/Minutes (CDRL A100)

Software Requirements Specification (SRS) (CDRL A027)

4.1.6 Functional/Technical Reviews

The Contractor shall conduct functional and technical reviews with the Government for each release. These reviews shall be conducted in accordance with the PRPS Agile Strategy, in

Appendix B.

Component Validation and Integration (CV&I) Sufficiency Review – a post-Component

Integration Testing (CIT) and ROT activity to demonstrate the degree to which the system meets specified requirements and expectations to begin Qualification Test & Evaluation

(QT&E).

DELIVERABLES: Report, Record of Meeting/Minutes (CDRL A100)

Presentation Material (CDRL A099)

4.1.7 Other Government Reviews

The Contractor shall support technical and management reviews conducted for each release. These reviews include:

Full Deployment Decision (FDD) – a post QT&E activity to determine readiness to deploy the release into production.

DELIVERABLES: Report, Record of Meeting/Minutes (CDRL A100)

Presentation Material (CDRL A099)

Product Roadmap. As an initial activity, the Contractor shall develop and maintain a Product

Roadmap. The items identified in the roadmap must align with the overall product vision and be organized by features. The team will use the roadmap to organize the Backlog, prioritize work, and ensure that the appropriate features are being delivered at the right time. The team can adjust the Product Roadmap, in consultation with the Product Owner, prior to each release planning event. The team will, also in consultation with the Product Owner and facilitated by the Scrum Master, allocate Backlog items to Sprints that align to the roadmap.

DELIVERABLES: Product Roadmap (CDRL A116)

4.1.8 Business Capability Acquisition Cycle Process (BCAC)

The Contractor shall be familiar with the Business Capability Acquisition Cycle (BCAC) process, AFMAN 63-144 in conjunction with AFI 63-101/20-101, the Air Force execution of the business system process complies with DoDI 5000.75. The process consists of five phases;

capability initiatives will enter into the Capability Need Identification phase but may transition to other phases if the intent and exit criteria for each phase is completed to the satisfaction of the authority-to-proceed approval authority.

4.2 Architecture and System Design

The Contractor shall support the design and development of PRPS and its integration into the overarching enterprise architecture as they pertain to changes/modifications to PRPS.

4.2.1 Department of Defense Architectural Framework Guidance

The Contractor shall provide systems level architecture support, as needed, for the design and development documents as well as the system level contribution to architectural documentation in compliance with the latest Department of Defense Architectural Framework

Guidance no more than once annually when requested.

4.2.2 System Design Agile Collaboration

The Contractor shall work with the PMO using Agile collaboration meetings to describe, demonstrate, and document a design that reflects the baselined requirements. Traceability between the requirements, design, and test documentation shall be provided for each release as encapsulated within each Change Package, as well as for the training simulation modules.

The Contractor shall document all Design information realized under Agile Collaboration

Sessions within the Change Package associated with each release requirement (e.g., DRs, BCRs, TCRs, etc.).

The Contractor shall roll-up all Design information contained within each Change Package into the next SDD deliverable required under each Major Release.

The Contractor shall document all Test Strategy information realized under Agile Collaboration

Sessions within the Change Package associated with each release requirement (e.g., DRs, BCRs, TCRs). This Test Strategy information should include references to existing, updated or new test scripts as documented within the STD deliverable required with every minor and major release. (Reference Para 1.1.24)

DELIVERABLES: Report, Record of Meeting/Minutes (CDRL A100)

Software Design Description (SDD) (CDRL A029)

Change Package (CP) (CDRL A108)

4.2.3 Database Design and Development

The Contractor shall produce the following when a database change is required for a minor or major software capability release:

1) Logical Data Model.

2) Physical Data Model to include the PRPS unique data elements as well as any shared data elements that may be available from the AF Metadata Repository.

3) Physical Database including scripts to create the physical database.

DELIVERABLES: Software Design Description (SDD) (CDRL A029)

Computer Software Product (CSP) (CDRL A040)

4.2.4 Training – Web Based Simulation

The Contractor shall continue to provide an interactive, hands-on, intuitive, web-based user training application (CBT) that can be accomplished on an individual basis at the user’s desk.

The CBT simulations are web-based hypertext markup language (HTML) screens and the data is loaded individually for each simulation screen. The CBT simulations do not pull data from the same central database for each screen.

The Contractor shall make it clear to the functional office and users what training is required for their functional role type, in what logical order training should be accomplished, how to access their appropriate training lesson, and the process to record training lesson activity and completion. All other training resources, such as help screens, field hovers, check lists, and definitions of terms, necessary for the user’s understanding, progress, and training task accomplishment, shall be web-based, available on-line, and associated with the latest version of PRPS. The interactive training shall include instructional text and graphic representation, web-linked references, examples, reviews, and provide reference to the PRPS contact list for questions/comments, reviews, and any other instructional aides as applicable. The Contractor shall provide a web-based Functional User Training Application that shall include all data necessary to conduct on-line, interactive, hands- on, intuitive, web-based user training that employs realistic PRPS operational scenarios.

The Contractor shall continue to provide the capability for the Government to track and report on web-based user training progress. The progress reporting must, as a minimum, provide the ability to report by user type, site, organization, development spiral, training module, and training module completion date. The methodology must include restart/resume capability. The student tracking information must be portable to the production environment and traceable by

Capability Support Release.

1) The Contractor shall modify the Training menu selection leading to the CBTs under the

Help button dropdown menu.

2) When implementing DRs, BCRs, ISRs, and/or TCRs and changes to the training software, the Contractor shall:

a. update lessons in the syllabus.

b. update information accessed by the Quick Reference button.

c. not update the information accessed by the Training Material and References buttons unless a BCR is written.

d. provide CBT test material to test against.

e. ensure modified/updated CBTs are executable and accurate from the beginning to the end of the lesson.

f. ensure data between the CBT simulation screens are consistent within a particular lesson.

DELIVERABLES: Computer Software Product (CSP) (CDRL A040)

4.2.5 Air Force Cloud One & BES CI/CD Pipeline Developer Guidelines

The Contractor shall follow and comply with Air Force Cloud One and AWS GovCloud guidelines, for developing systems and applications that will be deployed to Air Force Cloud

One. In addition:

1) The Contractor shall keep within the range of Air Force Cloud One, AWS GovCloud and

Security Authorizing Official acceptable and supported COTS and OSS versions and provide a strategy for migration to future COTS and OSS versions and/or replacement products.

2) The Contractor shall work with the Air Force Cloud One through the PRPS PMO to determine architecture requirements and…