RACER 11_12 PWS 08 July 2025 synopsis.docx

Performance Work Statement (PWS) Remedial Action Cost Engineering and Requirements (RACER™) Software Development 08 July 2025

1. GENERAL/BACKGROUND

1.1 Mission

The United States Army Corps of Engineers, Huntsville Center (CEHNC) is the Assigned Responsible Agency (ARA) for providing operation and maintenance support to the Remedial Action Cost Engineering and Requirements (RACER) software. The RACER software is a Windows-based environmental remediation/corrective action cost-estimating system.

1.2 Background

The U.S. Air Force developed RACER to support a growing number of environmental sustainment, management, and remediation efforts. RACER is based on parametric cost estimating techniques and is used to create parametric cost estimates for environmental remediation projects where the factors affecting the project vary widely from site to site. It provides a common shared platform for similar activities performed under similar circumstances. The software code is copyrighted by AECOM under the title “RACER.” This software title is provided for use under a Government Purpose Rights.

Both Department of Defense (DoD) Financial Management Regulation (FMR) and Defense Environmental Restoration Program (DERP) guidance provides for the use of electronic cost estimating software in most environmental liability (EL) estimating situations. The RACER application is used by DoD (including the Army and the Air Force) and other Federal agencies for developing parts of out-year EL estimates and annual budgets. Other DoD and Federal agencies also use RACER to prepare parametric cost estimates. Electronic cost estimating applications provide for consistency among EL cost estimates.

1.3 Scope

The purpose of this contract is to support and sustain RACER software title. The Contractor shall provide all personnel, technical, and functional services and supplies, as defined within this PWS, necessary to execute this work. The work will consist of a helpdesk, software sustainment, document development, training, and other services needed to ensure the satisfactory operation and output of RACER.

1.4 Software Management

a) The Environmental Estimating Community of Practice (EECoP) is composed of DoD Component lead representatives (Mission Area Manager Representatives) with a direct role in development and maintenance of processes, procedures, and tools and are responsible for environmental liability cost management. The EECoP Chair and Co-Chair are representatives from the offices of the DASD(EMR) and the Deputy Assistant Secretary of the Army for Environment, Safety and Occupational Health (DASA(ESOH)). Membership is open to DoD Components and Federal agencies that engage in the preparation of E&DL cost estimates. The EECoP receives information from the RACER Technical Review Group (TRG) for consideration in the development of RACER.

b) The RACER TRG is composed of DOD cost engineers and other participating federal agency cost engineers who have the technical responsibility to perform quality assurance reviews of RACER submittals. In addition, the TRG is responsible for reviewing Problem/Change Requests (P/CR) for RACER and determining their technical priority in being addressed in future versions of RACER. The EECoP has final say on RACER enhancement approvals.

1.5 Current Maintenance Environment

RACER is a parametric, integrated cost estimating application designed to provide an automated, consistent, and repeatable method to estimate and document the cost for the environmental remediation/cleanup of contaminated sites with the information available at the time of the estimate preparation. RACER provides the detail of an engineers’ estimate, but it also can be used at early order-of-magnitude stages of cost estimating.

1.6 RACER Hardware/Operating System Requirements

The current minimum hardware and operating system requirements needed to install RACER include an Intel Core i3 (3rd generation) processor or equivalent AMD processor (Intel Core i5 (8th generation) or AMD Ryzen 5 equivalent recommended); 4 GB RAM (8 GB or above recommended); 256 GB Hard Disk Drive (HDD) or Solid State Drive (SSD) (512 GB or above SSD recommended); CD ROM Drive (if the software is not downloaded); Microsoft Windows 10 or later (64-bit) Operating System (Windows 10 Pro or Windows 11 recommended); Microsoft Excel® 365; Microsoft .NET Framework 4.8. RACER is developed and maintained in the VB.NET and C# programming languages with a Microsoft Access database.

1.7 Interfaces/Compatibilities

The Contractor shall preserve a file interface for the RACER title, specifically the EDR/PP Utility, during defect management and enhancements work affected by this contract. File interfaces may require updates to meet changes in the destination software. Maintenance of the interfaces should be managed under this contract.

1.8 Definitions

Agile: A software development methodology under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, and continual improvement, and it encourages rapid and flexible response to change. Popular agile software development frameworks include the Agile Unified Process (AUP), Extreme Programming (XP), Feature-Driven Development (FDD), Lean Software Development, Kanban, Rapid Application Development (RAD), and SCRUM. Agile software development practices include Agile Testing, Backlogs (Product and Sprint), Behavior-Driven Development (BDD), Continuous Integration, Iterative and Incremental Development (IID), Pair Programming, Refactoring, Retrospective, Story-Driven Modeling, and Test-Driven Development (TDD).

Area Cost Factors (ACF): Area Cost Factors are location-dependent cost multipliers used to enhance the accuracy of cost estimates for programmed federal construction projects throughout the world.

ARA: Assigned Responsible Agency. Documented responsibility designated to a group or team of government employees. In this case, the ARA is the Huntsville Engineering Support Center, assigned the responsibility for maintaining and enhancing the software and databases needed to support the Cost Engineering Community of Practice.

ARA PM: Assigned Responsible Agency Project Manager. There will be one PM who is assigned as the primary point of contact. The ARA PM is responsible for the overall execution of scope, schedule, and budget associated with requirements outlined in this base contract.

Azure DevOps: The Azure DevOps system is used to track RACER Problem/Change Requests (P/CR) and defect remediation. This system contains the detailed review and testing correspondence between the Government, Government Contractors, and AECOM. The RACER Azure DevOps system is available to key Government stakeholders to add to, comment on, and check the latest status of P/CRs.

CEHNC: United States Army Corps of Engineers, Huntsville Engineering Support Center CLIN: Contract Line Item. The only CLINs associated with this contract are labor, travel, and ODCs. Work will be ordered via task order by negotiating firm-fixed quantities of each CLIN according to the estimated effort required to complete the task.

Contractor Manpower Reporting: The Office of the Assistant Secretary of the Army (Manpower & Reserve Affairs) operates and maintains a secure Army data collection site where the contractor will report ALL contractor manpower (including subcontractor manpower) required for performance of this contract. The contractor is required to completely fill in all the information in the format using the Contractor Manpower Reporting website.

Contracting Officer (KO): The warranted individual responsible for the proper acquisition and administration of this contract.

Contracting Officer’s Representative (COR): The COR will be identified by separate letter. The COR monitors all technical aspects of the task order and assists in task order administration. The COR is authorized to perform the following functions: assure that the Contractor performs the technical requirements of the task order; perform inspections necessary in connection with task order performance; maintain written and oral communications with the Contractor concerning technical aspects of the task order; issue written interpretations of technical requirements, including Government drawings, designs, specifications; monitor Contractor's performance and notify both the Contracting Officer and Contractor of any deficiencies; coordinate availability of government furnished property; and provide 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 with regard to changes in cost or price, estimates or changes in delivery dates. The COR is not authorized to change any of the terms and conditions of the resulting order.

Contracting Officer Representative Tracking Tool (CORT Tool): A web-enabled application designed to provide insight into the COR nomination and designation process. Designed to track COR and COR-related actions within the DOD including the nomination, appointment, revocation, and termination of an individual as a COR against a DOD contract or a contract or order issued on behalf of a DOD assisting agency.

Contractor: The primary private entity responsible for the execution of the requirements of this contract.

Contractor Performance Assessment Reporting System (CPARS): A web-enabled application that collects and manages the library of automated Contractor Performance Assessment Reports (CPAR). A CPAR assesses a Contractor’s performance and provides a record, both positive and negative, on a given Contractor during a specific period of time. Each assessment is based on objective facts and supported by program and contract management data, such as cost performance reports, customer comments, quality reviews, technical interchange meetings, financial solvency assessments, construction/production management reviews, Contractor operations reviews, functional performance evaluations, and earned contract incentives. CPAR ratings include ‘Exceptional’, ‘Very Good’, ‘Satisfactory’, ‘Marginal’, and ‘Unsatisfactory’.

COP: Community of Practice Commercial Cost Book: An electronic database consisting of construction task items with specific cost information for crews (labor & equipment) and materials necessary to calculate cost for construction projects.

CSI (Construction Specifications Institute): An authority which prescribes a special industry-recognized format by which all construction tasks are listed and organized. A unique 12-digit number is used to identify each task. The first two numbers of each task identify which of 50 “divisions” the task falls under, based loosely upon the primary construction discipline used for each task (electrical, mechanical, etc.)

DOD: Department of Defense EDR/PP Utility: Estimate Documentation Report / Post Processor Utility. A software title that manually (no machine-to-machine direct interface) pulls both costs and cost estimate information from RACER. Manually creates reports that are then manually transferred in the Formerly Used Defense Site Information System (FUDSMIS) for archiving.

EECoP: Environmental Estimating Community of Practice. The Government group that governs environmental estimating capabilities, including RACER.

EM-CX: Environmental Munitions Center of Expertise.

FAR: Federal Acquisition Regulation. The federal government’s regulation for the execution of all federal acquisitions and purchases with Contractors and suppliers. It contains clauses which may or may not be included in the contract.

Government Agent: A representative acting in an official capacity on behalf of the Federal government.

MII: (Microcomputer Aided Cost Engineering System—2nd Generation). The latest detailed construction cost estimating software developed and maintained by the TRACES team for use by the U.S. Army Corps of Engineers and other federal agencies. It has replaced the MCACES Gold and MFW estimating systems, which were phased out.

Master format: See CSI ODC: Other Direct Costs. Other Direct Costs in a contract that cannot be attributed to any other CLIN, such as shipping of materials, reproduction expenses, software licenses, or other requirements defined at the task order level.

P/CR: Problem/Change Request. A process used for RACER to identify bugs and enhancement ideas typically generated by the RACER TRG, the Contractor, or other users. The RACER TRG works closely with the Contractor to prioritize the P/CRs using DevOps and meetings and P/CRs that require formal vote are brought before the EECoP.

PDF: Portable Document Format. Electronic document format most closely associated with Adobe® Acrobat software.

Performance Work Statement (PWS): A definition of the specific requirements expected in executing a contract line item.

PMBOK: Project Management Body of Knowledge. The PMBOK is widely acknowledged as the comprehensive authority on effect project management practices.

PMI: Project Management Institute. A group of professionals who created the Project Management Body of Knowledge.

PMP: Project Management Plan. The Contractor’s plan that describes how projects are to be executed and completed and who is responsible for each aspect of the project.

Project Manager (government): The government representative directly responsible for the proper management and administration of the requirements and deliverables of the contract and the resources to meet them. The project manager also leads the government’s integrated project delivery team for the contract.

ProjNet: The on-line document and submittal review system created by the Construction Engineering Research Laboratory, U.S. Army Corps of Engineers. It was developed primarily as a collaborative tool to review construction contract drawings and specifications between government and Contractor personnel, but has been successful in being used to review data submittals for RACER and PACES projects as well.

QA: Quality Assurance. The government’s method of verifying that the Contractor’s quality control (QC) system is working.

QC: Quality Control. The Contractor’s system of ensuring that all product submittals and deliverables meet the level of quality specified in the government’s performance work statement.

QMP: Quality Management Plan. The Contractor’s plan that describes in detail how their QC system works.

RACER (Remedial Action Cost Engineering and Requirements): A parametric Environmental and Munitions remediation estimating system developed by AECOM Technical Services, Inc., and used by the Tri-Service cost engineering community and other federal agencies.

TRG: Technical Review Group Tri-Service Automated Cost Engineering System (TRACES) Cost Book: A collection of data containing specific information (task descriptions; associated crews, labor, equipment, and production rates; task material prices, etc.) on specific construction tasks. This data is compiled and used by a number of automated cost estimating systems used by the federal government (MII, PACES, RACER, or other software titles) to create accurate and reliable construction cost estimates. The TRACES Cost Book will be compiled and combined from a specified list of approximately 17,000 government-maintained tasks. The TRACES Cost Book must be maintained in both English and Metric units as separate databases. The equipment portion of the TRACES Cost Book will be based upon the EP-1110-1-8, Region VIII, and Seattle Davis Bacon Labor Rates. The TRACES Cost Book is restricted information that cannot be disseminated in whole or displayed in part to any other agency or entity.

Tri-Services: The Army, Navy, and Air-Force cost engineering communities.

VV&A (Verification, Validation, & Accreditation): Key processes in the development and maintenance of models to ensure they are reliable and accurate.

Waterfall: A structured and linear software development methodology that emphasizes a logical progression of steps/phases including requirements, analysis, design, programming, testing, deployment, and operations & maintenance (O&M). Before moving to the next step/phase, there is usually a review and sign off process to ensure that all defined goals have been met. Is ideal for projects that have specific documentation, fixed requirements, ample resources, an established timeline, and well-understood technology.

Wide Area Workflow (WAWF): A web-based application that allows DOD vendors to submit and track invoices, receipts, and acceptance documents electronically.

2. GENERAL REQUIREMENTS AND REQUIRED RESULTS

The purpose of this contract is to provide maintenance and support services for the RACER application. This shall include the development of a new version of the RACER software and may include resolutions to existing Defects and development of model documentation. The following contract task and subtask areas apply to the work to be performed:

· RACER 11.12

· Database Maintenance

· Software Testing

· EDR/PP Utility

2.1 Knowledge, Skills, & Abilities

The Contractor shall have the functional and technical knowledge of developing parametric construction and environmental models, programming software logic for and usage of RACER, cost engineering for Environmental and munitions projects, and instruction expertise on RACER. The Contractor shall have at least three years of experience in environmental parametric cost model development and have legal rights to use the RACER modeling methodology. The Contractor shall also have the capability to create the models in the correct structure format that are usable by the RACER software. In addition, the Contractor shall have at least three years of experience in providing effective instruction on the RACER software for the primary purpose of performing cost engineering on environmental and munitions remediation projects. The Contractor shall furnish all services and supplies requested by the KO through the issuance of this contract as generally characterized within this section. The Contractor shall provide qualified personnel in the cost engineering and software development disciplines to: (1) Perform specified services and (2) Furnish the management, administration, training, travel, supervision, quality assurance, supplies, materials and equipment (not otherwise furnished as Government Furnished Materials). These personnel shall deliver services within schedule and in accordance with contract terms, reference documents conditions, specific contract requirements, and contract clauses.

2.2 Parametric Estimating and Software Requirements

The parametric tools provided under this contract shall utilize a parametric estimating approach to estimate such that the estimator can enter a minimal amount of information to generate a cost estimate; each cost model has required parameters that drive secondary parameters which calculate based on algorithms and assumptions built into each cost model. The estimating tools provided under this contract shall include a comprehensive library of cost models and assemblies, to support the full range of project needs and preserve estimating functionality over time. Outputs from the tools provided under this contract shall maintain functionality to be exportable to key federal Government systems, such as the Estimate Documentation Report/Post Processor (EDR/PP) Utility, etc.

2.3 Reporting and Export Functionality

The parametric tools provided under this contract shall maintain the ability to export reports in multiple formats (Excel, PDF, RTF, XML, etc.) to facilitate integrations with Government systems such as Formerly Used Defense Sites Management Information System (FUDSMIS), etc. The Contractor shall provide support for batch reporting and automated documentation processes to streamline Government program reporting needs. The Contractor shall provide for the delivery of essential report types, including Uniformat (Levels 1-4), CSI, DD Form 1391, assembly detail, and cost markup reports.

2.4 Transparency, Traceability, and Markups

The Contractor shall be required to deliver detailed backup documentation for the parametric tools under this contract, including, but not limited to, model reports and cost assumptions, supporting transparency and accountability of the tools. The Contractor shall ensure markups (e.g. prime, subcontractor, overhead, contingency, SIOH) are configurable and allow for flexible and tailored estimates. All estimates shall maintain traceable links from model inputs to final outputs to support internal QA/QC processes and external audits.

2.5 Integration of Key Data Sources

The Contractor shall have the ability to integrate and update various authoritative data sources within the estimating tools, including, but not limited to, TRACES Cost Book and pricing databases, escalation factors, Area Cost Factors (ACFs), Per Diem rates, and location modifiers (i.e. seismic zone, winter dry bulb, frost line depth, etc.). The parametric tools under this contract shall allow for updates of these data sources.

2.6 Communication, Meetings, and Coordination

Communication between the Contractor and Government will be necessary and frequent throughout the period of performance of this contract. Communication will take various forms on both a scheduled and unscheduled basis. The Contractor should be prepared to partake in review meetings, teleconferences, internet-enabled conferences, or other requirements defined within this contract. Meetings will be held subject to Army Conference policy. The Contractor may necessarily gather information, prepare and provide a draft agenda at least three (3) business days prior to a meeting, coordinate interfacing with other automated systems, demonstrating features, disseminate information and meeting minutes, perform training, and provide user support.

For all meetings, the Contractor shall prepare the meeting minutes to capture discussion during the meeting. The Contractor shall submit meeting minutes within 7 calendar days following the meetings. Meeting minutes shall be sent via e-mail to all attendees as well as the EECoP and TRG members who could not attend in MS Word and/or other MS applicable format (e.g. MS Access, PowerPoint, Excel) as a draft. Attendees should add comments within 7 calendar days of receipt. The comments will be provided to the Contractor at that time through the KO or their representative. The Contractor shall then incorporate comments and submit final minutes within 7 calendar days of their receipt to all attendees. If no comments are provided to the Contractor within 7 calendar days of the aforementioned draft provision, the Contractor will resubmit the meeting minutes and mark them as final

2.7 Contractor Travel

Contractor will be required to travel CONUS during the performance of this contract to attend meetings. Contractor will be authorized travel expenses consistent with the substantive provisions of the Joint Travel Regulation (JTR) and the limitation of funds specified in this contract. All travel requires Government approval/authorization and notification to the COR.

2.8 Personnel Requirements

The Contractor shall provide key personnel to fill the roles identified below. The years of experience included within the minimum criteria as set forth below for key personnel are considered concurrent, i.e., any years shown for specialized experience are not in addition to the time for general experience. The Contractor’s personnel as described in the proposal are hereby incorporated by reference and the Contractor shall provide these persons as part of contract performance. The KO will make final determinations as to whether personnel meet criteria requirements. Should key personnel change during the life of the contract, new resumes and qualifications will be provided and approved in advance of performance by the KO for those personnel. Key personnel are as follows: Program Manager, Project Manager, Lead/Senior Computer Programmer, Quality Control Representative, Technical Writer, and Principal Cost Engineer. If any key personnel perform in more than one capacity within the same contract, it is imperative that the Contractor charge appropriately the labor category and rates for the work being performed for individual tasks on this contract. Key personnel are required to attend all meetings, scheduled and ad hoc. Meetings shall be attended either virtually or in-person and will be defined specifically in each task.

2.9 Project Management

2.9.1 The Contractor shall provide program/project management and supervisory functions to ensure timely performance for this contract. The Contractor shall provide substantive guidance, policy and practices, for managing and executing the terms of the contract and demonstrate a commitment for continuous improvement of internal work processes, minimizing the impact of changes on external system users, and providing security safeguards for proprietary information. USACE recognizes the Project Management Institutes (PMI) Project Management Body of Knowledge (PMBOK) as the industry standard. For software processes, the Contractor shall provide project management leadership in the areas of Waterfall or Agile development processes. The Contractor shall describe experience with these software development processes. This experience shall describe the type of experience, years, and organization’s ability to support modern software development practices.

2.9.2 Contractor Manpower Reporting (CMR): The Office of the Assistant Secretary of the Army (Manpower & Reserve Affairs) operates and maintains a secure Army data collection site where the Contractor shall report ALL Contractor manpower (including subcontractor manpower) required for performance of this contract. The Contractor shall completely fill in all the information in the format using the Contractor Manpower Reporting website. The required information includes: (1) Contracting Office, KO, and COR; (2) Contract number, including task and delivery order number; (3) Beginning and ending dates covered by reporting period; (4) Contractor's name, address, phone number, e-mail address, identity of Contractor employee entering data; (5) Estimated direct labor hours (including sub-Contractors); (6) Estimated direct labor dollars paid this reporting period (including sub-Contractors); (7) Total payments (including sub-Contractors); (8) Predominant Federal Service Code (FSC) reflecting services provided by Contractor (and separate predominant FSC for each sub-Contractor if different); (9) Estimated data collection cost; (10) Organizational title associated with the Unit Identification Code (UIC) for the Army Requiring Activity (the Army Requiring Activity is responsible for providing the Contractor with its UIC for the purposes of reporting this information); (11) Locations where Contractor and sub-Contractors perform the work (specified by zip code in the United States and nearest city, country, when in an overseas location, using standardized nomenclature provided on website); (12) Presence of deployment or contingency contract language; and (13) Number of Contractor and sub-Contractor employees deployed in theater this reporting period (by country). As part of its submission, the Contractor shall provide the estimated total cost (if any) incurred to comply with this reporting requirement. Reporting period shall be the period of performance not to exceed 12 months ending September 30 of each government fiscal year and must be reported by 31 October of each calendar year. Contractors may use a direct XML data transfer to the database server or fill in the fields on the website. The XML direct transfer is a format for transferring files from a Contractor’s system to the secure website without the need for separate data entries for each required data element at the website. The specific formats for the XML direct transfer may be downloaded from the website.

2.9.3 Azure DevOps. The Contractor shall maintain an Azure DevOps system for RACER for the purpose of tracking and prioritizing defects, P/CRs, status, testing results and collaboration. The Contractor shall maintain access to the Azure DevOps systems and grant Government and Government Support Contractors access to the systems upon agency TRG lead approval. Additionally, the Contractor shall have an approval process in place for internal personnel access. During monthly status meetings, Azure DevOps system access shall be reviewed to ensure personnel from each agency still require access to the system. If it is determined during the monthly status meeting or at any other time that personnel have access to the RACER Azure DevOps system and are no longer involved with the development or testing of RACER, the Contractor shall revoke their access immediately.

2.9.4 Contractor’s Project Management Plan (PMP). The Contractor shall develop a PMP for the general operations under this contract. It shall act as the primary example of the support provided to the Government through the contract along with roles and responsibilities delivered by AECOM. Submission of the Master PMP will be required following the award of this contract. The PMP shall include the details necessary and relevant, including a project baseline schedule, for managing the work specific to this contract. The Contractor’s performance will be rated in accordance to how tasks are planned and executed under the framework of the PMP. The PMP shall be briefed during the kickoff meeting of this contract. The PMP will be accepted as final after all valid comments have been adjudicated in ProjNet or Azure DevOps. The system in which comments will be tracked for the PMP shall be agreed on between AECOM and the Government prior to delivery. Without reiterating this PWS, the PMP shall include procedures for fulfilling the requirements of the contract, information on procedures and software development processes (e.g. – Waterfall, Agile, SAFE) for developing automated databases and other software, as well as information on functionality (including accurate and auditable estimates) and operational characteristics of automated databases and software used to develop RACER assemblies and models and on the currently produced RACER software. Off-the shelf software, which will be used, shall be specifically identified and related to functional relationship within the contract that it will be used for. The Contractor shall designate the following within the PMP: (1) the principal company officer responsible for administering this contract, (2) the principal company officer who is authorized to negotiate technical and management considerations (these first two officers may be one in the same) and (3) the principal company officer responsible for administrating the Quality Management Plan (shall be a separate individual). The final PMP will be signed by AECOM and RACER Project Manager(s).

2.10 Quality Management

2.10.1 All Quality Control (QC) is the responsibility of the Contractor. The Contractor is responsible for the quality of all contract deliverables. The Contractor shall exercise in-house QC of all contract deliverables by qualified independent team members and thoroughly test all updates and installation procedures prior to submittal delivery to the Government. The independent team members providing QC should be familiar with RACER but not working on this specific contract. Testing will be performed on current Government approved operating system platform(s), generally the latest Microsoft product(s). The Contractor will be required to support the software’s functionality with the Government’s current operating environment at the time of contract completion.

2.10.2 Contractor’s Quality Management Plan (QMP). The Contractor shall develop, maintain and execute an approved QMP. The QMP shall clearly depict how the Contractor will provide effective QC to deliver quality products consistent with contract requirements for the full scope of the contract. Furthermore, the QMP shall list the names, qualifications, authority/chain of command, and responsibilities for each staff member responsible for ensuring quality management for all contract deliverables and the overall RACER products.

2.10.3 Quality Assurance Surveillance Plan (QASP). One of the outputs from the QMP is the QASP. The QASP provides a systematic method to evaluate performance for the stated contract. The Contractor’s performance will be evaluated in part to how tasks are executed in accordance with the QASP. It is the Government’s responsibility to be objective, fair, and consistent in evaluating performance. The Government will provide a draft QASP with the RFP. The contractor can recommend edits to the QASP and the QASP will be considered final when it is signed by both parties. The QASP shall contain a table depicting the standard, acceptable quality level, method of surveillance, and incentive for each task deliverable.

2.11 Documenting Performance / Quality Standards

2.11.1 Quality Deficiencies. Deficiencies for each deliverable shall be tracked in WAWF, the CORT Tool, CPARS, and/or as an administrative record in ProjNet and/or DevOps.

2.11.2 Quality Assurance. The Government will perform periodic quality assurance checks on all Contractor deliverables to make certain of product conformance with contractual requirements during the product development and after the product has been issued to the users. The results of these reviews will be formally furnished to the Contractor as written comments in ProjNet or DevOps. The Contractor shall evaluate all comments and provide red-lined copies of the deliverable as a means for the commenter to verify recommendations are incorporated appropriately. The Contractor shall indicate in their evaluation if they believe the review comment has the potential to impact scope, cost, or schedule of the project. Such comments will be flagged and brought to the attention of the Government Project Manager and KO. The KO will make a final determination regarding scope, cost, or schedule impacts from such flagged comments. The Government will back check the comments following submission of the Contractor’s evaluation. Deliverables will not be accepted as final until all comments in ProjNet or DevOps have been closed and adjudicated to the satisfaction of the Government. If comments are unsatisfactorily incorporated, the KO has the right to ask for a corrected final.

2.11.3 Re-submittal of deliverable(s). Unacceptable or incomplete deliverables will be returned to the Contractor for correction of deficiencies. The Contractor will correct the errors and re-submit the deliverable with a new transmittal letter within 10 working days (unless indicated otherwise on the contract baseline schedule) at no additional cost to the Government. Any associated schedule changes (if any) must be approved by the KO.

2.11.4 Comment Log. The Government’s user community will review the deliverables and will provide comments in ProjNet or DevOps. After submitted reviews, the KO or their representative may also provide formal written comments. If ProjNet, DevOps, or similar tracking software is not used, the Government will provide the Contractor a report of all comments. As a minimum, the report will contain the reviewer’s name, the reviewer’s comment number, date and content of comment, reviewer’s comment, comment status, deliverable incorporated into and date and description of the comment resolution. Each comment will have a unique log ID separate from the reviewer’s comment number. The report will be capable of recording subsequent comments of Contractor and Government rebuttals to provide a complete history of the comment, from creation to resolution. The comment log will be used during the review process of Contractor submittals associated with individual task orders.

2.11.5 Responding to comments. Unless otherwise notified, the Contractor can provide evaluations in ProjNet or DevOps immediately after a comment is entered. Notwithstanding, the Contractor shall provide a complete evaluation within 10 business days of the Government comment suspense date. Official comments by definition are considered by the Government to be within scope. The Government project manager will coordinate all team member/reviewer comments and separate out comments from team members/reviewers that were not developed based on this PWS and therefore would not be considered in scope by the Government and would not be submitted via the KO. Official comments will be managed within the ProjNet, DevOps, or equivalent system. The log format for comments will be established by the Government and contain fields for the Contractor to respond to each individual comment. The log format will be organized into categories that relate to the task as specified under this contract. Specific instruction on the ProjNet system will be provided to the Contractor as needed. In-scope comments submitted separately via e-mail from technical users and/or TRG/EECoP members, may be responded to by the Contractor, however the Contractor shall always reply to sender comments with a “copy furnished to” the KO and/or the Government ARA Project Manager. When responding to comments, the Contractor shall always annotate all comments as being “concur,” ”non-concur,” “check and resolve,” or "for information only" with rationale for accept/dispute, respectively. When writing evaluations, enough detail shall be provided so that the Government can verify how each comment was adjudicated. The Contractor may state recommendations when deemed necessary to support decisions. Any items that the Contractor finds dispute with will be resolved via conference calls with the Government. Once the Contractor accepts a comment it is considered to be in scope of the contract. The Government may take up to twenty one (21) calendar days to review the Contractor’s submittals.

2.11.6 Comment Resolution. The KO will direct the solution of any comment, which cannot be resolved between the Government and the Contractor. The current status of each comment will be noted in ProjNet, DevOps, or an alternative comment log.

2.12 Defect Management

For the purposes of this contract, a software defect is an instance existing within the source code, or associated databases and models, that results in a condition which does not meet a software requirement (as stated in the model report) or end-user expectation (which may not be specified but is reasonable). The defect may exist as an error in coding or logic that causes a program to malfunction or to produce incorrect/unexpected results. The definition of software defects is further expanded to include conditions that affect display, manipulation, or storage of data as well as layout or operation of the user interface.

3. SPECIFIC CONTRACTOR PERFORMANCE / QUALITY STANDARDS

The Contractor shall develop RACER version 11.12 per the technical requirements in this PWS and address Exigent Legacy Defects and develop specific model / technology documentation, if optional task is exercised, as currently defined within this PWS. To accomplish this effort, the Contractor shall perform the tasks defined in the subsections below.

The Contractor shall adhere to all performance and quality standards defined within this PWS. For this contract, deliverables shall adhere to the following process unless otherwise specified within Section 7 of this PWS.

· Rough Draft – Submitted by Contractor to the Government for review and comments.

· Comment and Response Phase – The Government provides comments, contractor responds to comments and the team reconciles comments and develops a path forward via teleconferences, email, web meetings, etc.

· Draft – The Contractor incorporates comments from the Government.

· Back-check – The Government reviews the Draft to ensure comments were incorporated; the phase can include additional meetings with the Contractor and Government to reconcile issues.

· Final – The final document should include all reconciled comments.

3.1 Task 1 – RACER 11.12 (Basic Task, Non-Severable)

3.1.1 Database Maintenance

3.1.1.1 General

The purpose of this maintenance is to ensure cost models are up to date with the latest, as of March 2026, Cost Book (available from the Gordian Group), HTW/HNC cost data, area cost factors, escalation rates, per diem rates, and Equipment and Labor libraries (available from the Government). The results of these maintenance tasks shall be a new official release of RACER. The maintenance shall include appropriate updates to the help files within the software and RACER user documentation files. The maintenance shall also include the update of RACER supporting data.

3.1.1.2 Assemblies for RACER 11.12

The Contractor shall use the current cost data as described in Section 3.1.1.1 in updating the RACER 11.12 assembly database. The contractor shall work with the Government to determine the appropriate escalation factors and apply these factors to each task. If a line item is not located in the Cost Book, the Contractor shall attempt to remap the line item to a similar line item located in the cost data used. If the Contractor is unable to locate a similar line item for replacement, the contractor shall provide labor, equipment, material, or, sub-bid costs with appropriate backup and these costs shall also be escalated to the current year. During the review specified in Section 3.1.1.3, if the Contractor or the Government identifies a cost in the Cost Book to be unreasonable, the Contractor shall propose a new price from an alternate source or by obtaining at least three quotes per line item (not to exceed 100 tasks) and taking the average. The Government shall review and approve the contractor’s backup and documentation for assembly line items not located in the current Cost Book or line items repriced due to being unreasonable. The Contractor shall supply the following information in the Final RACER 11.12 Database Update Report (DUR):

a) A list of assemblies and their associated line items (including data – source, source extension, source tag, description, Unit of Measure (UOM), crew quantity, crew, man hours, labor cost, equipment cost, material cost, sub bid cost, total cost, and the models they are used in) that are not fully interfaced with the current Cost Book excluding zero cost assemblies (i.e., the line items which make up these assemblies are not all currently found within the current Cost Book) utilized for RACER 11.12).

b) A list of assemblies and their associated line items (including data – source, source extension, source tag, description, Unit of Measure (UOM), crew quantity, crew, man hours, labor cost, equipment cost, material cost, sub bid cost, total cost, and the models they are used in) that are fully interfaced with the current Cost Book (i.e., the line items which make up these assemblies are all found within the current Cost Book utilized for RACER 11.12).

c) A list of all zero cost assemblies

d) A list of assemblies interfaced with Labor Source Tags.

e) A list of assemblies not associated with RACER Models/Technologies.

3.1.1.2.1 Assembly Changes

The Contractor shall coordinate receipt of the most current cost data libraries from the USACE Huntsville Center (HNC) Tri-Service Automated Cost Engineering Systems (TRACES) department and/or the Execution PM. The TRACES department will provide the electronic file formats (MII or Excel) for the current Cost Book; and for Labor and Equipment libraries for use in development of the assemblies used in RACER. The Contractor shall analyze the data to determine data gaps in assemblies based upon revised, new, or deleted line items, and develop the assemblies that shall be documented in the Database Update Report to be approved by the Government.

The Contractor shall analyze the raw cost data, in spreadsheet format, and conduct a RACER assembly Cost Evaluation. The Cost Evaluation shall not only take into account cost variances from the previous version, but also the reasonableness of assembly costs and the assembly composition. The Cost Evaluation shall include identification and recommendations of RACER assembly edits which improve cost estimating accuracy. During this analysis, if the Contractor or the Government identifies a task in an assembly that is erroneous, the Contractor shall recommend that a new task be added, or that the task be repriced up to 100 tasks. The Cost Evaluation shall be submitted in a Rough Draft, Draft, and Final version for Government review and incorporation of comments.

The Contractor shall incorporate assembly changes to include deleting and/or adding line items, adjusting factors as approved by the government. These changes shall be summarized in the DUR specified in Section 3.1.1.3.

3.1.1.2.2 Area Cost Factors

The Contractor shall use the Area Cost Factor (ACF) data furnished by the Government. The Contractor shall develop a deliverable spreadsheet document summarizing the ACF locations and the assigned modifier. This spreadsheet shall compare the new ACF data to previous ACF data and should be included in the DUR described in Section 3.1.1.3. The Contractor shall ensure that there is a one to one match between the locations listed in the source document to the locations available in RACER. The Contractor shall provide the Government a sufficient duration of time to review, comment and approve the ACF mapping prior to the Final Release.

3.1.1.2.3 Escalation Factors

The Contractor shall use the Escalation Factors furnished by the Secretary of the Air Force (SAF/FMC) office. The escalation reference information shall be included in the DUR described in Section 3.1.1.3.

3.1.1.2 3.1.1.3 3.1.1.4 3.1.1.5

3.1.1.2.4 Per Diem Rates by Location

The Contractor shall be responsible for downloading most recent electronic versions of the CONUS and OCONUS per diem rates. CONUS rates shall be obtained from the U.S. General Services Administration (www.gsa.gov) and OCONUS rates shall be obtained from the Defense Travel Management Office (www.travel.dod.mil). The Contractor shall indicate the relevant dates pertaining to the per diem information (i.e., updated dates/effective dates and unique dates pertaining to CONUS vs. OCONUS information) such that reviewers are able to determine that relevant per diem rates are incorporated as part of the update. If dates vary by season for a location, the Contractor shall use the most conservative (highest) rate for that location. The Contractor shall provide the Government sufficient duration of time to review, comment and approve the Per Diem mapping prior to the Final Release. The per diem reference information shall be included in the DUR described in Section 3.1.1.3.

3.1.1.3 Database Update Report

The Database Update Report (DUR) shall describe in detail, all changes made to the software to include the following for each data item:

a) Sources of new/revised data used in RACER 11.12. New/revised data shall be identified in such a way to be traceable to its source for auditability per VV&A.

b) Method and procedures for updating data in the RACER database (including handling of orphan records from previous task orders and identification of any new records added to the RACER database). The effective pricing dates of the original data should be shown, as well as escalation calculations and values used to match the effective pricing of the current Cost Book. If all pricing is then escalated to a certain date of the RACER release, then those calculations shall be shown as well.

c) Method procedures for a detailed task and assembly cost evaluation, which shall include analysis results and the Contractor’s recommendations.

d) Side-by-side comparison of values used in the previous released version of RACER with those to be used in the current developed version of RACER (including a percent difference). This includes, but not limited to, task and assembly costs and information, factors, escalation rates, Per Diem rates, and area cost factors.

e) Resolution of any issues that come up while making the upgrades listed.

f) The Contractor’s Quality Control/Quality Assurance methods and procedures, to include, but not limited to, what data was reviewed, what issues were being looked for, whether it was a manual or automated process, reviewer’s statements certifying that reviews were completed.

g) The DUR shall include demonstration of developmental version control, such as a log of interim version changes between the developmental RACER testing stages.

3.1.1.4 Database Update Report Conference Calls

The Contractor shall coordinate, schedule, and conduct conference calls, as required, with the appropriate Government personnel to identify issues proactively and bring them to the attention of the Government prior during development of the DUR. These issues could include problems translating the current Cost Book, line items/assemblies with significant costs changes, or line items/assemblies with problematic unit changes. The goal of these calls will be to gain concurrence on the direction the Contractor should take to address these issues. It is anticipated that four of these calls would be necessary: two during development of the DUR; one to discuss the Rough Draft DUR; one to discuss the Draft DUR. The Contractor shall provide a conference line to the appropriate government personnel. The Government shall identify edits desired within the DUR in order to clarify the scope of the Government QA testing efforts and auditability of the database element changes. The contractor shall provide Meeting Agenda and Minutes per instructions outlined in Section 2.6 of this PWS.

3.1.2 Software Testing

Software testing is a process to evaluate the functionality of a software application with an intent to find whether the developed software meets a specified requirement(s).