PWS - DDMS Technical Refresh Cloud Host - Final Draft.pdf

PERFORMANCE WORK STATEMENT

DEFENSE DEBT MANAGEMENT SYSTEM (DDMS)

TECHNICAL REFRESH/CLOUD HOST REQUIREMENT

1.0 BACKGROUND

The Defense Finance and Accounting Service (DFAS) provides finance and accounting services to the Military Services and other Department of Defense (DoD) activities. The mission of DFAS Defense Debt Management System (DDMS) is to provide a financial business, on-line debt management system designed and developed to maintain, control and report on DoD individual Out-of-Service (OoS) delinquent debts, in accordance with current Federal debt collection laws and regulations. DDMS relies upon the OoS data received from the military pay system interfaces to as well as other DoD activities to validate, establish, notify, collect and manage valid debts to include performing calculations on interest, penalties and administrative fees. Updates/changes to the OoS members data/status because of managing OoS debts to include calculations are relayed via established system interfaces regarding the collection of debts owed to other intragovernmental Department of Defense (DoD) agencies (specifically the Defense Logistics Agency (DLA), Department of Justice (DoJ) Treasury and the Credit bureaus (Experian, Equifax, TransUnion and Innovis, etc.)). DDMS furnishes OoS debt data via established reports and data files to the DFAS Indianapolis Finance Operations, Debt & Claims Management (DCM) Directorate, and the DFAS Indianapolis Accounting Operations, Accounts Receivable Directorate so they can report on receivables (in collaboration with the DFAS Enterprise Solutions & Standards (ESS) - Accounting Standards & Reporting Directorate) and pursue OoS debt collections on service members, retirees and former civilian employees no longer in an active pay status on the respective military, retiree or civilian pay systems.

Below is an overview of the architecture, hardware, and users of DDMS:

System Architecture: DDMS software is written in COBOL and data is maintained on the VSAM file management system.

DDMS software resides on a logical partition (LPAR) of an IBM mainframe computer, which is managed by the Defense Information System Agency (DISA). The IBM mainframe uses z/OS 2.4 operating system. Users access DDMS application through the NIPRNET telecommunications using a web browser and MIAP. Interface partners send data through DAI’s GEX for consumption by DDMS. The chart below contains the current Lines of Code for DDMS:

DDMS System Lines of Code

Code Type Lines of

Code

ADSO 77,571

COBOL 237,206

PRINT.INFO 17,306

FTP Cards 485

JCL 6279

PROC 67,681

Control Cards 3634

Note: This includes stand-alone programs, programs calling other programs and called modules. The logical codebase is approximately 410,162 lines.

Hardware: DDMS is hosted on an IBM z-series Business Class mainframe computer. All site provided equipment must be common access card (CAC) enabled and be able to support CAC certificate-based login.

Users:

Functional Users: Users are responsible to provide the functional users’ equipment capable of supporting a web browser. Web access is supported for .mil sites only with SSL via DISA’s Multi-Host Internet Access Portal (MIAP). The Cloud version of DDMS will be required to support Chrome, Firefox, and Edge browser access.

DDMS currently has approximately 200 users with roles.

Technical Users: Users are responsible to provide the technical users’ equipment capable of supporting CAC access.

2.0 OBJECTIVE

The objective of DDMS is for a Tech Refresh of the mainframe - Code structure improvement in technology and architecture domains, apply a refresh to the entire technical stack and re-engineering to cloud-based architecture - Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) capabilities to include code transformation.

The intended end state of DDMS will be a Government Owned, Government Operated comprehensive debt management system for the DoD Financial Management Service (FMS) community that is formed entirely of components which are non-proprietary except to the government. The end state will be a common object-oriented codebase and will maintain the functionality and logic of the original COBOL application. The conversion process should adhere to industry best practices including documentation and testing, to ensure a seamless transition and maintainability of the codebase. In addition, the conversion of the DDMS code base to use a common, secure, and supported Cloud and web framework platform for DoD approved browsers (Chrome, Edge, and Firefox). Contractor to provide end to end traceability and visibility of functionality and data. This legacy technical environment needs to be converted to a new modernized single universal interface. This must all be accomplished without loss of functionality or data.

The DDMS system will:

Utilize a single data structure Leverage open architecture Be cloud hosted (on Joint Warfighting Cloud Capability (JWCC) provider) Provide web-based, user-friendly access for DFAS technicians and other Government employees Allow real-time account updating Allow for batch processing where and when appropriate Complete processes, such as processing, in an efficient and timely manner Comply with all DoD and Government regulations governing financial systems including but not limited to

Standard Financial Information System (SFIS) standards and Standard Line of Accounting (SLOA) standards Contain any other actions/activities/requirements that will be needed to develop a modern, customer friendly, secure system Have a codebase that is nonproprietary and not low/no code, the codebase will be robust object-oriented code.

Vendors must design a comprehensive strategy to deploy DDMS in an alternative operating environment.

Recommendations should identify the approach as a revision to modify and refactor DDMS to Cloud or a rearchitect to materially alter DDMS to Cloud. All recommended strategies must address the total environment structure including, but not limited to, hardware, infrastructure, platforms, software, and security. Contractor’s environments (DEV, TEST, PROD) must all be accredited at DoD Impact Level 5 (IL5)

DFAS is open to considering any reasonable designs, however, there are certain technical aspects that have been pre-determined:

a. Code Conversion: The desire of DFAS is to convert/replace legacy code (which includes, VSAM, COBOL, DB2, JCL, CICS) to a modern object-oriented language, to utilize existing languages that have a proven track record for auditability, compliance, and accuracy. The current DFAS code base for this conversion effort is approximately 920,000 lines of code.

b. Clean Code: It is the expectation of DFAS that the code will be fully converted to a new language vice migrating

COBOL to a new (cloud) environment. In addition, it is the expectation that the converted code will also be refactored to provide a modern, clean, and efficient code base, which leverages modularity and microservices to the greatest extent possible, in the target language (i.e. Java). Final object-oriented code base should be easily integrated with other code bases in the same language. Code will be readable, clear, reliable, secure, easy to test, documented, annotated and modular.

c. Database Structure: The desire of DFAS is to consolidate disparate data types with different data structures into a single data structure that will comply with DoD and DFAS data standards (i.e. SFIS, SLOA). It will apply/leverage an efficient design that best utilizes a high performance and scalable Relational Database Management System (RDBMS) that aligns with DFAS Enterprise Architecture. The target database will also need to comply with and accommodate National Archives and Records Administration (NARA) requirements and will need to retrieve archival data for retroactive processing.

d. Data Cleansing and Conversion: The desire of DFAS is to cleanse, convert, and migrate all necessary system and account data, current and historical, from the legacy systems into the new data structure. Data in the DEV and TEST environments should be refreshed at an agreed upon frequency. This data consolidation only impacts this application.

e. Application: The system should utilize a common modern language, in the application logic. Support natural update to the user interface (UI) that occur with the transition from mainframe UI to web-based UI. In addition, all coding (developed and converted) should follow Federal best standards for efficiencies, secure coding, and maintainability.

f. Business Intelligence and Analytics: In alignment with DFAS enterprise technology architecture and DFAS expertise, the system should integrate with a current DFAS commercial Business Intelligence and Analytics tool such as Microsoft Power BI.

g. Cloud Hosting: The production environment will reside in a DoD Cloud enclave engineered for large, high-performance workload. It is the expectation of DFAS that the system will be hosted in an IL 5 certified DISA approved environment.

h. Security: All software, commercial and developed, must fully comply with all applicable DoD and DFAS Cyber

Security requirements and guidelines, including Zero Trust, and Security Technical Implementation Guide (STIG), National Institute for Standards and Technology (NIST), Statement of Standards for Attestation Engagements (SSAE18) and DoD Financial Management Regulation (FMR). All tools, platforms, and software libraries must be current, with patches, versioning, and under vendor support. Software must also comply with Supply Chain requirements and clearly identify company and country of origin. In addition, all products, commercial and custom, must be analyzed for vulnerabilities using code analysis tools such as FORTIFY or ACAS. Vulnerabilities found in testing or code scanning to be tracked in a Vulnerability tracker and noted on a POAM (Plan of Action and Milestones) or risk tracker.

i. DevSecOps: The desire of DFAS is to utilize DevSecOps and Agile methodology for this project and to transition these processes to DFAS upon completion. Following Agile methodology, development and testing will follow Sprint cycles that will refine user stories and acceptance criteria, allow for collaborative development and testing, and produce potentially shippable products beginning with the deployment of the minimum viable product (MVP), followed by minimum viable capability release (MVCr) that will occur on a scheduled basis. The establishment of a DevSecOps pipeline must comply with DoD, DISA, and DFAS standards to include monitoring and providing compliance enforcement of containerized applications which cover all the DevSecOps pillars (Develop, Build, Test, Release & Deploy, and Runtime) for a secure posture with the focus being on automation and integration going forward. The contractor must demonstrate a proven method for leveraging Cloud services including Continuous Integration/Continuous Deployment (CI/CD) and DevSecOps.

The Contractor shall propose a clear DevSecOps strategy and explanation of the continuous delivery pipeline that aligns with the guidance provided in the DoD Enterprise DevSecOps Reference Design published by the DoD Chief Information Officer.. After contract award, the Contractor shall work with DDMS IT to increase continuous integration and continuous delivery capability by progressively layering more sophisticated automation components into the continuous integration/continuous delivery pipeline while also reducing the time to move approved code from development to production.

In support of this effort, the Contractor shall bring to bear industry and Government practices for elements of

DevSecOps such as code repository management, configuration management, branching/merging code, building automation, test code coverage, and automated scanning tools. The Contractor shall look for practices to streamline and integrate security practices within the continuous integration/continuous delivery pipeline.

The DevSecOps support required includes:

1. Installing and configuring application lifecycle management, continuous integration/continuous delivery, and continuous monitoring tools.

2. Designing, implementing, and maintaining the DevSecOps continuous integration/continuous delivery pipeline for cloud and on-premises deployments.

3. Recommending and implementing industry-based practices for continuous monitoring.

4. Training and coaching development teams in utilizing the application lifecycle management and continuous integration/continuous delivery tools.

5. Establishing and maintaining standards for use of the application lifecycle management and continuous integration/continuous delivery tools.

6. Recommending industry-based practices for incorporating testing, security, and operations representation into the Agile Team early and continuously in the application lifecycle.

7. Recommending industry-based approaches and tools for instrumenting DevSecOps elements to provide greater visibility, transparency, and awareness related to pipeline bottlenecks, security, and operational issues.”

Per the DoD Enterprise DevSecOps Reference Design, the following capabilities must be addressed when standing up a software factory:

Use of Open Container Initiative (OCI) compliant and Cloud Native Computing Foundation (CNCF) certified

Kubernetes platform to enable interoperability from one Kubernetes installation to the next and allow flexibility to choose between vendors if needed

Use of hardened containers to maintain security Use of the DoD Centralized Artifact Repository (DCAR) to hold the hardened vitual machine (VM) images and hardened OCI compliant container images of DevSecOps tools, container security tools and common programming platform components (e.g., COTS or open-source products) that the DoD program software teams can utilize as a baseline to facilitate the authorization process.

Use of a Sidecar Container Security Stack (SCSS) - A new service that is enabled by DevSecOps and the container-based Kubernetes runtime environment is the Sidecar Container Security Stack (SCSS). This security stack enables correlated and centralized logs, container security, east/west traffic management, a zero-trust model, a whitelist, Role-Based Access Control (RBAC), continuous monitoring, signature-based continuous scanning using Common Vulnerabilities and Exposures (CVEs), runtime behavior analysis, and container policy enforcement. In addition to the components in the sidecar, there are a few services that support the security sidecar.

These include:

1. Program-specific Log Storage and Retrieval Service

2. Service Mesh

3. Program-specific artifact repository

4. Runtime Behavior Analysis Artificial Intelligence (AI) service

5. DCAR for the hardened containers

6. Common Vulnerabilities and Exposures (CVE) Service / host-based security to provide CVEs for the security sidecar container Vendors shall be required to work within a government furnished DevSecOps environment in order to get full Source and Resulting Code access, and in order to be able to perform full functional and security tests Use of one CI/CD orchestrator per software factory Support for automation o Development teams developing application code and Infrastructure-as-Code (IaC) to improve quality of integrations, releases and deployments.

o Security teams strive to automate security by implementing security compliance checking and auditing as code (SaC) o Both IaC and SaC are treated as software and go through the rigorous software development and processes including design, development, version control, peer review, static analysis and test o Support for continuous and automated testing across the software development lifecycle (Lifecycle phases include - plan; develop; build; test; release; deliver; deploy; operate; monitor) o Use of one CI/CD Orchestrator per software factory

j. Agile Methodology: The contractor shall work in a team-based Agile environment. The Product Owner will specify high-level requirements/capabilities to the Agile team. As in typical Scrum-based Agile processes, the Agency Product Owner will work together with the team to develop and estimate user stories and establish acceptance criteria. These acceptance criteria shall specify expected functionality for a user story, as well as any non-functional requirements that must be met in the development of the story. The Agency Product Owner, supported by subject matter experts and business analysts, will determine whether acceptance criteria have been satisfied.

k. Authority To Operate (ATO): The desire of DFAS is to complete a full ATO, following the (NIST) Risk Management Framework guidelines and standards for the submission and completion of the ATO. In addition, the initial ATO should be positioned for migration to a Continuous ATO as instructions and guidance are established.

l. Interfaces: The desire of DFAS is to modernize interface processing to the extent possible but utilizing an interface broker and utilizing modern formatting and processing. The system must retain the capability to send and receive data via all existing interfaces.

m. System Integrator: The desire of the DFAS is to work with a vendor that has experience leading large modernization efforts that involve many different technical aspects that will need to be brought together for an efficient and stable modern system.

3.0 SCOPE

The scope of this requirement is to provide modernization and re-architecture to the DDMS system by providing planning, developing, designing, building and licensing to support the requirement. In addition, the contractor shall provide all personnel, management, administrative and technical services to meet the requirements outlined in this PWS.

4.0 TASKS/REQUIREMENTS

The contractor is required to convert the DDMS interface into a common, supported, and secure Cloud and web enabled software platform, with the code base backend of the system converted to a language readily available in the job market, and the entire technical stack refreshed to meet modern financial information system standards.

4.1 PHASE 1 – ANALYSIS

The contractor shall review submitted point papers from Operations and any other sources, System Change Requests (SCRs), email requests, or meeting action items. Written analysis of proposed changes shall be provided, to include affected system components and expected level of effort to make requested changes. All responses shall be coordinated with the DDMS System Manager.

4.2 PHASE 2 – IMPLEMENTATION

Within 120 days from the beginning of the contract, the Contractor shall develop and present at least on general menu screen (The initial screen seen by the end user), at least one inquiry screen (no database updates), at least one update screen (including database updates) for approval to proceed. This plan will include documented architecture of modernized target environment. The proposal would include plan to convert all screens to a web-based UI.

4.3 REQUIREMENTS ANALYSIS AND FUNCTIONAL CONFIGURATION

The contractor will confirm, configure, document and verify implementation of the Technical Refresh/Cloud Host in DDMS and all associated interfaces, integrations and automated processes. The deliverables associated with this task are IPT Meeting Minutes, Configuration Document(s), Interface Requirements Specifications and User Guides.

The contractor shall provide support for all aspects of functional system requirements to the DFAS DDMS program deliverables to include that of Business Intelligence activities. Contractor shall support related applications such as integration with the D-System suite (Defense Retiree & Annuitant Pay System (DRAS) and Defense Joint Military Pay System (DJMS)). As part of Financial Improvement and Audit Readiness (FIAR) projects, the contractor shall also perform research and analysis to develop functional requirements for data interfaces between D-System and non-D-System applications.

The contractor will research, analyze give proof the developed functional requirements designed to carry out a migration of the DDMS applications to the Technical Refresh/Cloud Host. The contractor shall also record the new interfaces, modify existing interfaces, provide in writing data queries, data screens and system business functions as part of carrying out this migration.

The contractor will research, analyze and document the developed functional requirements designed to adapt/integrate DDMS with new Technical Refresh/Cloud Host to the Department of Treasury and other legacy and ERP systems.

The contractor shall research, analyze and document the developed functional requirements designed to adept/integrate the functional needs for DoD and Army Departmental. Output from these related efforts support monthly and quarterly critical path financial statement reporting.

4.4 SYSTEM DEVELOPMENT

All existing interfaces, integrations, and automated processes shall be modified to support Technical Refresh/Cloud Host requirements. Perform code impact analysis, review the Configuration and IRS documentation, make required updates to existing DDMS interfaces and integrations and conduct unit testing.

The contractor shall apply the user interface (UI) extensions necessary to provide for consistent business process terminology between DDMS and Performance Budgeting. These extensions shall be consistent with the Configuration Guides.

The contractor shall provide documentation to include all relevant process requirements and an updated Data Dictionary of developed functional descriptions to support new interfaces, modifications of existing interfaces, data queries, data screens, system business functions, use of Electronic Data Interchange conventions, and other possible solutions to expose the data in the library to financial system applications.

The contractor shall develop all SCRs to update the required financial reports and customer exports to comply with the Technical Refresh/Cloud Host

4.5 DATA MIGRATION

The contractor shall convert existing DDMS data to the Technical Refresh/Cloud Host requirements during the Data Conversion IPT. The contractor shall develop custom migrations scripts to convert Production data from the requirements identified. Deliverables required are the Data Migration Plan and Data Reconciliation Results Memorandum.

4.6 TESTING

The contractor shall work with the Program Office to design, develop and execute a coordinated test strategy that meets DFAS policies and guidelines. The strategy will be included in the Test Plan along with specific testing tasks, schedules, and roles and responsibilities. The testing phases will be Regression Testing, System Integration Testing and System Acceptance Testing, and Production Validation Testing. Deliverables are Test Plan, Test Scripts and Testing Results Report.

When supporting testing activities, the contractor shall develop scenarios, scripts, acceptance criteria, setting-up test environments and using the relevant testing software.

4.7 PRODUCTION DEPLOYMENT

The Production Deployment phase will immediately precede the system go-live. The contractor shall ensure all tasks required for the cutover are completed and that the Production environment is functional prior to go-live. This phase will begin the week before the Production environment scheduled system downtime. This phase will require 24-hour weekday and weekend support from the contractor. The deliverable is the Production Deployment Confirmation Memorandum.

4.8 TRAINING

The contractor shall provide training for the Technical Refresh/Cloud Host. High-level User Testing Training will be conducted prior to the start of to prepare for system testing. Deployment Training will be provided prior to the go-live date to familiarize users with new DDMS functionality and business processes. Training will include prototype demonstrations, navigation, workflow and basic system processes.

Deliverables are User Manual, Training Materials and Course Evaluation Reports.

4.9 POST IMPLEMENTATION SUPPORT

The contractor will provide 60 calendar days of post-implementation support after the Technical Refresh/Cloud Host implementation go-live, to include correcting any failures and providing expert advice and assistance to answer questions or concerns. The contractor shall provide a Post Implementation Support document at the completion of the post implementation support phase.

4.10 MONTHLY STATUS REPORT

The contractor shall submit a Monthly Status Report that includes accomplishments, schedule status, risks, tasks completed, planned activities for the next period, status of deliverables, work hours per task, and any issues/concerns to accomplishing objectives. This report shall document all significant activities, deliverables and problem/resolution areas that occur under contract performance for the previous month. As documented within the Project Plan and agreed upon by DFAS PM.

4.11 MONTHLY RESOURCES REPORT

The contractor shall prepare a Monthly Resource Report, presenting the amount of time and cost for each contractor employee. As documented within the Project Plan and agreed upon by DFAS PM.

4.12 INTEGRATED MASTER SCHEDULE

The contractor shall submit an Integrated Master Schedule that includes: the complete schedule for the project with all remaining processes and tasks included. The contractor shall provide detailed analysis and guidance to DFAS throughout the full life cycle of SFIS/SLOA implementation. As documented within the Project Plan and agreed upon by DFAS PM.

5.0 PERIOD OF PERFORMANCE: The Base period of performance shall be for (12) months with one 12 month

Option Year.

Base Year: 10/01/2026 – 09/30/2027 Option Year 1: 10/01/2027 – 09/30/2028

6.0 PLACE OF PERFORMANCE: The work will be performed remote. Travel may be required to CONUS locations to support DDMS customers at their place of business. CONUS sites are predominantly military bases or other Government installations.

When performing at DFAS sites, the contractor shall require their employees to follow the following requlations as if they contractor employees were DFAS employees, unless relieved of that responsibility by the Contracting Officer.

DFAS 2000.1-I,

DFAS 5200.1-I

DFAS 5200.8-I, and

DFAS 5200.10-I

7.0 DELIVERABLES: The contractor shall submit electronic copies of all deliverables in the current version of the

Microsoft Office Suite of software used by DFAS to the COR and DFAS Project Manager, unless otherwise directed, as specified in the chart below, on or before the required date. The contractor shall notify the COR and the DFAS Project Manager as soon as a problem or potential problem appears to the contractor. The contractor will have 5 calendar days to revise and resubmit any rejected deliverables. The Government retains ownership and rights of all deliverables and rights of all deliverables.

PWS reference Deliverable Frequency Section 4.1 Status report on current progress Weekly on Monday

Section 4.2 Develop and present at least one general menu screen. At least one inquiry screen. At least one update screen

Within 120 days of contract start.

Section 4.3 Requirements Analysis and Functional Configuration– Meeting Minutes, Configuration documents, Interface Requirements Specifications, and User Guides

Minutes – within 24hrs of meetings

As documented within the Project Plan and agreed upon by DFAS

PM

Section 4.4 System Development As documented within the Project Plan and agreed upon by DFAS

PM

Section 4.5 Data Migration - Data Migration Plan and Data Reconciliation Results Memorandum

As documented within the Project Plan and agreed upon by DFAS

PM

Section 4.6 Testing - Test Plan, Test Scripts and Testing Results Report

As documented within the Project Plan and agreed upon by DFAS

PM

Section 4.7 Production Deployment - Production Deployment Confirmation Memorandum

As documented within the Project Plan and agreed upon by DFAS

PM

Section 4.8 Training - Training Materials and Course Evaluation Reports

As documented within the Project Plan and agreed upon by DFAS

PM

Section 4.9 Post Implementation Support – Post Implementation Support Document

As documented within the Project Plan and agreed upon by DFAS

PM

Section 4.10 Monthly Status Report As documented within the Project Plan and agreed upon by DFAS

PM

Section 4.11 Monthly Resource Report As documented within the Project

PM

Section 4.12 Integrated Master Schedule As documented within the Project

PM

8.0 PERFORMANCE REQUIREMENTS SUMMARY MATRIX

The contractor service requirements are summarized into performance objectives that relate directly to mission essential items. The performance threshold briefly describes the minimum acceptable levels of service required for each requirement. These thresholds are critical to mission success.

PWS reference Objective/Result to be achieved Acceptable Level of Performance

Surveillance Method

Section 4.0 Configure system to Technical Refresh/Cloud Host

Target system will be 100% Technical Refresh/Cloud Host

1) Internal (DFAS) system assessment

2) Testing by a DoD CIO approved/assigned testing agency

Section 4.0 Configure system to comply with required business rules.

Target system will be 100% Technical Refresh/Cloud Host

1) Internal (DFAS) system assessment

2) Testing by a DoD CIO approved/assigned testing agency

Section 4.0 Configure system to send and receive attributes and financial information via interfaces (trading) partners.

Target system will be 100% Technical Refresh/Cloud Host

1) Internal (DFAS) system assessment

2) Testing by a DoD CIO approved/assigned testing agency

Section 4.5 Code changes are produced and are able to be compiled and executed in packages ready for Unit testing

Code completed with minimal rework 95% of the time.

Automated code conversion solution deployed Automated code conversion of COBOL, and/or development into modern backend language

Review of schedule for timeliness and routine review of test defect report (TDRs) generated

Section 4.6 Defects are uncovered and immediately fixed and retested to validate correctness.

Test defects are discovered and fixed within schedule for unit test.

Development team lead review of unit testing plan and results.

Section 4.6 Comments/Feedback on content and quality as well as suggestions is provided.

Content and Quality are accurate 95% of the time.

Review of comments resulting from peer review. Routine review of test defect report (TDRs) generated per SCR.

9.0 INSPECTION AND ACCEPTANCE

Phase 1 – Analysis o Inspection – DDMS system office will review the approach deliverables.

o Acceptance – DDMS system office will review the approach deliverables within five (5) workdays of receipt. If the DDMS system office concurs with the approach, the DFAS Project Manager will provide written confirmation to the contractor/Contracting Officer/COR that the DDMS system office concurs with the approach. If the DDMS system office has concerns regarding the approach, the DFAS Project Manager will provide written notice to the contractor/Contracting Officer/COR regarding the concerns and the contractor will have five (5) calendar days to revise the approach and respond to the DFAS Project Manager.

Phase 2 – Implementation o Inspection – After the contractor has described that the Technical Refresh/Cloud Host have been completed, the DDMS system office will inspect to determine whether the system has full compliance.

o Acceptance – When the DDMS system office has determined that the system has achieved full

Technical Refresh/Cloud Host, the DFAS Project Manager will provide formal written notification to the contractor/Contracting Officer/COR of that determination.

10.0 PAYMENT

The contractor may submit a monthly invoice for labor hours incurred to perform the required tasks to meet the objectives specified in the contract and that meets the qualifications of the labor categories specified in the contract.

11.0 ADDITIONAL INFORMATION:

11.1 Interaction with Contractor Personnel: The COR shall forward questions or concerns directly to the prime contractor official representative who is directly responsible for managing its own employees/subcontractor personnel.

The prime contractor official representative shall coordinate a training schedule with the COR that does not cause undue delays to Task Order (T.O.) performance.

The prime contractor official representative (including subcontractor’s personnel, when applicable) shall provide the COR, within 30 days after T.O. award/exercise of an option, a written report identifying:

(1) Contractor employees required to take the training

(2) Contractor employees who completed the training

(3) Contractor employees who are delinquent

Contractor personnel shall direct their questions or concerns to their contractor management chain and/or company representative.

11.2 Recognized Holidays:

New Year’s Day Independence Day Martin Luther King Jr.’s Birthday Labor Day President’s Day Columbus Day Memorial Day Veteran's Day Independence Day Thanksgiving Day Juneteenth Christmas Day

11.3 Hours of Operation: The contractor shall conduct business between the hours of 6:00AM and 6:00PM, Monday thru Friday except the Federal holidays listed in 11.2 or when the Government facility is closed due to local or national emergencies, administrative closings, or similar Government directed facility closings. The contractor must at all times maintain an adequate workforce for the uninterrupted performance of all tasks defined within this PWS when the Government facility is not closed for any of the above reasons.

11.4 Extended/Emergency Hours: When mission needs dictate, at the request of or upon coordination with the COR, Contracting Officer Technical Representative (COTR), the contractor staff shall be available outside facility duty hours (i.e. will work nights and weekends) to support the types of work described within the PWS.

11.5 Remote Location: The contractor may be authorized to work from a remote location when it’s advantageous to the DFAS mission. This must be coordinated and approved by the COR and CO. NOTE: Work involving classified information will not take place at the contractor facility.

11.6 Post Award Conference/Periodic Progress Meetings: The contractor agrees to attend any post award conference convened by the contracting activity or contract administration office in accordance with Federal Acquisition Regulation Subpart 42.5. The COR, and other Government personnel, as appropriate, may meet periodically with the contractor to review the contractor's performance. At these meetings the CO will apprise the contractor of how the Government views the contractor's performance and the contractor will apprise the Government of problems, if any, being experienced. Appropriate action shall be taken to resolve outstanding issues. These meetings shall be at no additional cost to the Government.

11.7 Knowledge Transfer Plan:

Whenever there is a transition in support personnel, the current contractor shall be required to transition specific systems knowledge to the replacing labor resources. This transition period will be no longer than 90 days from the end of the current period of performance. Actual transition time will be determined by DFAS. Typically, the time will be less than sixty (60) days.

During the transition, it is expected that the contractor shall be onsite and shall work cooperatively with the replacement resources to transfer knowledge.

11.8 Contracting Officer Representative (COR):

The COR is the primary point of contact for the contractor. The COR shall interface with DFAS Information and Technology (IT) Point of Contact (POC) as well as the appropriate DFAS Site Force Protection Office POC to maintain internal monthly system updating to DoD compliance. To identify Site Force Protection Officers at each DFAS location consult the Agency Force Protection ePortal Page.

https://eportal.dfas.mil/portal/server.pt/community/force_protection/656

Follow the link titled “Site Specific Force Protection/Security Services” in the Additional Points of Contact section near the top right side of the Web page.

The COR/DFAS Project Manager is responsible for monitoring all technical aspects of the award and assisting in contract administration. COR/DFAS Project Manager duties include:

Ensure contractor performs the technical requirements of the award.

Perform inspections necessary in connection with contract performance.

Maintain written and oral communications with the contractor concerning technical aspects of the award.

Monitor contractor’s performance and notifies both the CO and contractor of any deficiencies.

Coordinate availability of Government furnished property and site entry of contractor personnel.

A letter of designation issued to the COR, a copy of which is sent to the contractor, states the responsibilities and limitations of the COR, especially regarding changes in cost or price, or changes in delivery dates. The COR is not authorized to change any of the terms and conditions of the resulting order.

11.9 Type of Contract: The award will be a Labor Hour contract type.

11.10 Identification of Contractor Employees: All contract personnel attending meetings, answering Government telephones, and working in other situations where their contractor status is not obvious to third parties are required to identify themselves as such to avoid creating an impression in the minds of members of the public that they are Government officials. They must also ensure that all documents or reports produced by contractors are suitably marked as contractor products or that contractor participation is appropriately disclosed. Contract personnel will be issued Government Common Access Cards (CACs) identifying them as a contractor after favorable security adjudication. Contractor employees must wear CAC’s while in the facility.

11.11 Travel Policy: The Government will reimburse the contractor for allowable travel cost incurred by the contractor in performance of the contract in accordance with FAR 31.205-46. Overhead, profit and Other Direct Costs are not an allowable travel cost for this requirement. The contractor will only be reimbursed for allowable direct labor costs.

Travel must be approved by the COR prior to any travel being made. When travel is required, the contractor is responsible for making all needed arrangements for their personnel. Actual travel costs will be reimbursed IAW

FAR 31.205-46.

The contractor shall provide a trip report five (5) days after each trip associated with a travel approval. The contractor shall maintain a summary of all approved travel, to include at a minimum, the name of the traveler, location of travel, duration of trip, total cost of trip. The contractor shall confirm travel requests in writing and shall provide the COR with names of travelers, expected duration of travel, travel locations, cost estimates and labor effort associated with the travel prior to travel period. No travel is expected outside the continental United States

(OCONUS).

Travel, subsistence, and associated labor charges for travel time are authorized for travel beyond a 50-mile radius of the local office, whenever a task assignment requires work to be accomplished at a temporary alternate work site. No travel, subsistence, or associated labor charges for travel time shall be charged for work performed within a 50-mile radius of the Contractor’s local office, normal work site, or temporary work site unless approved in advance by the COR. Under no circumstances will costs be reimbursed for travel performed for personal convenience and daily travel to and from the normal work site, to include parking expenses. A CLIN will be used for contractor travel reimbursement.

11.12 Data Rights: This requirement is covered by the data rights clauses included in the Task Order. In the event Data or Application Code is required that was developed exclusively at private expense of the contractor DFARS Clause 252.227-7015 is applicable. In the event Data or Application Code is developed during performance of this requirement using government funds DFARS Clauses 252.227-7013, 252.227-7016, 252.227-7017, 252-227-7030, and 252-227-7037 is applicable.

11.13 Organizational Conflict of Interest: Contractor and subcontractor personnel performing work under this Task Order may receive, have access to or participate in the development of proprietary or source selection information (e.g., cost or pricing information, budget information or analyses, specifications or work statements, etc.) or perform evaluation services which may create a current or subsequent Organizational Conflict of Interests (OCI) as defined in FAR Subpart 9.5. The contractor shall notify the CO immediately whenever it becomes aware that such access or participation may result in any actual or potential OCI and shall promptly submit a plan to the CO to avoid or mitigate any such OCI. The contractor’s mitigation plan will be determined to be acceptable solely at the discretion of the CO and in the event the CO unilaterally determines that any such OCI cannot be satisfactorily avoided or mitigated, the CO may affect other remedies as he or she deems necessary, including prohibiting the contractor from participation in subsequent contracted requirements which may be affected by the

OCI.

11.14 Section 508 Compliance:

Requirements for accessibility based on Section #508 of the Rehabilitation Act of 1973 (29 U.S.C. 794d) are determined NOT to be relevant for the following program need: DDMS is a legacy application hosted by the Defense Information Systems Agency (DISA) on a Unisys mainframe platform. DDMS must utilize DISA’s Multi-host Internet Access Portal (MIAP) website and access protocols. The DDMS application inherits any Section 508 compliance it has from DISA. There has been no tester/development support required from DDMS in terms of the Section 508 compliance requirements with DISA because that is performed in MIAP.

12.0 GOVERNMENT FURNISHED PROPERTY:

Government Furnished Property, Equipment, or Information (GFP, GFE, and GFI): All facilities and services (i.e.

computer products-PCs, printers, telephones, software and Government provided developmental platforms) will be furnished by DFAS for use within the DFAS Center. When required to travel to a DFAS site, the DFAS site location will furnish office space, desks, chairs, and supplies for Contractor Personnel working on this task order.

Office space supplies and equipment will be of the type ordinarily found at the DFAS site. The furnishings will be of the type used by personnel at the DFAS site.

All computer software required to complete the tasks will be made available to the Contractor. Desktop

Management Initiative (DMI) is the DFAS Standard for software/hardware. All computers connected at DFAS sites must be configured under DMI. Vendor’s employees will be provided standard issue DMI laptop. For Contractor personnel working at alternate locations agreed upon by DFAS and the Contractor, logon ID’s will be provided to access to the required platforms. The Contractor shall provide the access network connection via the Pulse Secure for any personnel not working at the physical DFAS site.

Government Furnished Property is subject to the following clauses which have been included in this RFQ by full text.

FAR 52.245-1 Government Property DFARS 252.245-7003 Contractor Property Management System Administration DFARS 252.245-7005 Management and Reporting of Government Property

The awardee of this contract must have an acceptable Property Management System, per DFARS 252.245-7003 and 52.245-1(f) in place to be able to receive GFP. The Contractor will provide sufficient information as part of their offer for the CO to determine the Contractor’s Property Management System is acceptable. Reporting requirements are defined in the provisions/clauses above.

GFP on this contract will be in the form of DFAS formatted laptop in which the contractor will need to remove the laptop from a Government Controlled Facility to perform the tasks that are required on the contract at an alternate location.

Receipt and return of GFP will be created and tracked through the GFP Tool.

13. SECURITY REQUIREMENTS.

Security Requirements.

General Requirements. Contractor personnel must meet the following conditions of employment.

1. Must be a U.S Citizen or National

2. Registered for Selective Service (males born after 12-31-1959). A Status Information Letter is required for any male born after 12-31-1959 that is not registered with Selective Service.

3. This is a national security position which requires a favorable fitness review and background investigation as a condition of employment. Failure to maintain security eligibility may result in termination.

Personnel Security Investigation (PSI) Requirements. Contractor personnel working on this contract will require a favorably adjudicated Tier 3, or equivalent Noncritical Sensitive (formerly IT-II) level or higher investigation. No access to classified information is required. IAW standard DFAS Personnel Security policy, ALL incoming contractors must submit a new set of fingerprints (taken within the last 30 days)*. A Declaration for Federal Employment (OF-306) should then be submitted to the Contracting Officer Representative (COR), who will submit this form along with a Contractor Request for Investigation (CRI) (DFAS Form 9035) to DFAS Personnel Security as soon as possible, but not less than fifteen (15) calendar days prior to the intended start date. DFAS Personnel Security will review all submitted documentation to validate whether contractor personnel meet personnel security requirements to perform work on the contract or if a new background investigation is required.

*New fingerprints are not required if any of the following apply:

1. The person has been fingerprinted for the Defense Counterintelligence and Security Agency (DCSA) within the past 30 days.

2. The person is currently undergoing a background investigation, or reinvestigation, by DCSA or any other Federal agency.

3. The person has a background investigation currently being adjudicated by the DCSA Adjudication and Vetting Services (DCSA AVS) or another AVS.

4. The person has been favorably adjudicated within the past 30 days by the DCSA AVS or a AVS from any other Federal agency: or

5. The person is coming directly from another DoD agency, with no break in service. This includes any of the military branches as well as the U.S. Coast Guard; however, service members in an inactive reserve status are not included.

6. The DFAS Personnel Security Office otherwise determines that no new fingerprints are required.

Regulatory Requirements. Contractor personnel shall follow the security and training requirements in DFAS 2000.1-I, “Force Protection Mission,” DoDM 5200.01, Volumes 1-3, “DoD Information Security Program,” DoDI, 5200.48, “Controlled Unclassified Information,” DFAS 5200.1-I, “Information Security Program,” DFAS 5200.8-I, “Physical Security Program,” and DFAS 5200.10-I, “Counter Insider Threat Program.” Contractor personnel shall follow all host security requirements in accordance with Part 117 of Title 32, Code of Federal Regulations; paragraph 117.16. The contractor shall immediately report any occurrences of violation of stated regulations to the Contracting Officer (CO), COR, and the DFAS Personnel Security Office.

DFAS Personnel Security Incident Reporting Requirements, the National Industrial Security Program and Due Process as it Relates to DFAS Contractor Personnel. The National Industrial Security Program (NISP) is a partnership between the federal government and private industry to safeguard classified information and CUI.

Executive Order 12829, as amended, "National Industrial Security Program", further amended by Section 6 of E.O. 13691, was established to achieve cost savings and to ensure that industry safeguards the classified information with which it is entrusted while performing work on contracts, programs, bids, or research and development efforts while working for United States Government.

It is important to note that personnel employed as contractors for DFAS are not covered under the National Industrial Security Program (NISP) and are exempt from the provisions of 5 C.F.R. 731. This means that DFAS contractor personnel involved in an incident that potentially violates one or more of the National Security Adjudicative Guidelines found at https://www.dni.gov/files/NCSC/documents/Regulations/SEAD-4-Adjudicative-Guidelines-U.pdf , are not entitled to Due Process rights normally afforded to federal civilian employees and those personnel covered under NISP; more specifically, DFAS Personnel Security may suspend or revoke their access to DFAS IT systems, sensitive information and/or DFAS facilities.

Incident Reporting Requirements.

In all cases, whenever a DFAS contractor displays conduct, or is involved in any incident, which is in violation of any of the thirteen National Security Adjudicative Guidelines*, the contractor must immediately report the incident to the contractor company Security Office/Facility Security Officer, the DFAS Manager of the area to which they are assigned, the COR, and the DFAS Personnel Security Office. Reporting to DFAS Personnel Security may be made by phone to (317) 212-7888, by email to dfas.indianapolis-in.zh.mbx.dfas-inhrsecurity@mail.mil, or, in the case of personnel physically located at DFAS Indianapolis Center, in person to the DFAS Personnel Security Office located on the third floor center hallway at Column 320T.

All incidents will be investigated by DFAS Personnel Security and, depending on the date of the subject’s most recent investigation, may need to have an updated background investigation initiated. Those that do not require a new investigation will have all relevant information regarding the incident forwarded to the DCSA AVS for review and re-adjudication.

*The thirteen National Security Adjudicative Guidelines are:

1. GUIDELINE A: Allegiance to the United States

2. GUIDELINE B: Foreign Influence

3. GUIDELINE C: Foreign Preference

4. GUIDELINE D: Sexual Behavior

5. GUIDELINE E:…