Performance Work Statement.docx
DOCX document 111 KB Posted
- Solicitation number
- FA852725RB003
About this file
This Performance Work Statement (PWS) details requirements for Air Force Distributed Common Ground System (AFDCGS) Service-Oriented Architecture Enterprise Service Bus (SOA-ESB) software development and support services. The primary objective is to develop software and provide community support using Agile methodology for the SOA-ESB system, which is a multi-message brokering service used across the DCGS enterprise. Key technical activities include architectural design, software engineering, feature development, system testing, information assurance artifact development, and integration support for open-source communities and platforms.
The contract will have a four-year ordering period, with the contractor responsible for developing modular, working software aligned with government requirements and prioritized by a Government Product Owner. Critical performance objectives include maintaining 75% code coverage through automated testing, achieving 90% manual test pass rates, implementing 100% of required security controls, and supporting the transition of SOA-ESB engineering support to 100% organic posture by contract end. The effort will benefit the United States Air Force by enhancing vigilance, reach, power, and mission planning capabilities of the DCGS weapon system, with a focus on continuous software updates and transparent product development processes.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Performance Work Statement.docx.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Performance Work Statement for
Air Force Distributed Common Ground System (AFDCGS)
Service-Oriented Architecture Enterprise Service Bus (SOA ESB)
Support & Services
Comment by HANSON, TIMOTHY G CIV USAF AFMC AFLCMC/C3IAK: Do we need to add a Table of Contents page? Comment by COCHRAN, CHRISTOPHER S CTR USAF AFMC AFLCMC/C3IAD: I have never had a Table of Contents in a PWS. I just went with what was in the template.
1.0 Description of Services
1.1 Objective(s): The following are the services required to conduct SOA-ESB software development and associated SOA-ESB software, DCGS and Platform One (P1) community support. The contractor shall develop software and provide community support using an Agile software development methodology. As directed by the Government, the contractor shall respond to schedule and programmatic changes of technical requirements, implementation changes, and operational needs. This may require an increase or decrease in the contractor’s team size. The SOA-ESB development effort encompasses but is not limited to technical assessments, architectural design, technical documentation creation and sustainment, software engineering, new feature development, improvement to existing functionality, configuration management, system test, Information Assurance (IA) artifacts development, IA testing and support, and DCGS community operational support.
Development shall also include support to third party (contractor and/or Government) provided component(s). During software development the contractor will interface as required with the Government Test Team and/or other government-directed team/resources as an integrated development team and develop software capabilities prioritized by a Government Product Owner. Software delivered to the Government will be continuously tested as required to verify stated capability functionality and performance. This support will include architecture design, architecture framework development, API interface design and development and capabilities development integration, testing and test support. SOA-ESB support currently also includes interfaces to open-source communities/organizations (e.g., Codice, Apache, etc.) for things such as Distributed Data Framework (DDF) and Alliance support, development and other activities including recommended changes to the DDF or other SOA-ESB subcomponents to include, but not limited to, KEIP/KEIP Canvas, Kubernetes, Artemis/Artemis Cloud, Spring Integration, Enterprise Integration Patterns, Citrus Integration Testing Framework, Cert Manager/Trust Manager, Zookeeper, Terraform, AWS, Bash scripting, Gitlab, Prometheus, Grafana, TimescaleDB, Jupyter Notebook, and OpenTelemetry. Similarly, the Contractor must demonstrate understanding of Government off the shelf (GOTS) software provided by the government. SOA-ESB community support may also include providing technical support, exercise support, deficiency fixes to previous versions of SOA-ESB, SOA-ESB training, or system integration support to Government services and agencies and their integration contractors. (A017)
The contractor shall provide all necessary knowledge sharing, collaboration, assistance, and training to the 577th Software Engineering Squadron (577th SWES), as directed by the Program Office and Product Owner, to facilitate transition of SOA ESB engineering support to 100% organic posture by contract end. (A017)
1.2 Benefit to United States Air Force (USAF): This acquisition will benefit the United States Air Force (USAF) by enhancing the vigilance, reach, power and mission planning capabilities of the AF DCGS weapon system to ensure continued Fly – Fight – Win dominance in assigned domains. In addition, this contract will allow for the SOA ESB program to transition to 100% organic engineering support at contract end.
1.3 Background:
This performance Work Statement (PWS) defines the services required to provide The Air Force Distributed Common Ground System (AF DCGS) with software development for the Service-Oriented Architecture Enterprise Service Bus (SOA ESB) system, a multi-ART message brokering service used to implement features such as publication/Subscription (PUB/SUB), Notification Topics, Orchestration, and message-oriented middleware in a consistent manner across the Open Architecture (OA) DCGS enterprise. This effort will be accomplished by Selected Contractor, hereafter known as the Contractor, for WR-ALC/HBGB, hereafter known as the Government.
The Contractor shall be the single point of responsibility for development, configuration, modification, and integration of the SOA ESB baseline, all with Government concurrence. SOA-ESB is currently based on the Distributed Data Framework (DDF) and Alliance, two fully open-source software products, and is documented to ensure that any vendor can develop and integrate SOA-ESB services as required by the Government. SOA-ESB currently supports DCGS operations both CONUS and OCONUS by providing continuous software updates on a requirements-driven tempo.
The contractor shall participate in Agile methodology development as directed by the PMO. The PMO’s goal for utilizing this methodology is to have full transparency into the product development and test processes. Additionally, this methodology would allow for continual inspection and adaption of the processes and product. The three pillars of Scrum theory, transparency, inspection, and adaption are integral for this effort.
SOA-ESB development activity is expected to include efforts focused on architecture design, technical documentation development and sustainment, architecture framework development, feature development and enhancement, development testing, and release activity as directed by the government.
SOA-ESB development activities may also include providing support to the DCGS community. This support may include, but is not limited to, SOA-ESB integration support, system integration support, training, problem debugging and fixes, issue resolution, Deficiency Report (DR) fixes, and operations and exercise support.
The specific tasks identified in this PWS will require the Contractor to develop, configure, modify, and integrate SOA-ESB in support of operations across all DCGS Agile Release Trains (ARTs). The contractor shall perform agile software activities in support of SOA-ESB and SOA-ESB related capability. Unless directed by the Government, the contractor shall perform all SOA-ESB architecture, development, and community support efforts on the latest version of the SOA-ESB software and subcomponents (currently the current versions of the DDF and Alliance).
The contractor will serve key roles on the Agile Team or other process/support organizations as directed by the PMO. The Integrated Development Team (IDT) will use Agile software development methodology to build capability in short development cycles or sprints lasting between 2 and 4 weeks. Each sprint involves a close coordination of contractor and Government engineering, development and test teams working together planning, analyzing requirements, designing, coding, unit/acceptance testing and functional user story and SOA-ESB testing IAW Agile methods. The objective for the end of the sprint is a working product of Government approved requirements represented in product backlog items approved and prioritized by the Government Product Owner. These objectives will be demonstrated to the Government and stakeholders in Sprint Reviews. The PMO Test Team will utilize Agile processes to develop tests and test scripts to perform Sprint and User Story functional and performance tests on software deliveries to meet Government approved criteria.
The contractor shall synchronize its efforts with the Government, Product Owner, and PMO test team including the DCGS Test and Community Support team. The key activities to accomplish SOA-ESB architecture, development, and community support are specified below and directed by the Government.
2.0 Services Summary
Unless otherwise directed by the PO/PM, the Contractor shall perform work in accordance with the requirements specified herein Section 2.0 Services Summary.
2.1 Performance Objectives
Table 2.1: Performance Objectives
| Performance Objective |
| PWS |
Locator Performance Threshold
Contractor Key Personnel Qualifications and Management
4.10.3 The Contractor shall provide qualified personnel (both technical and management) in order to meet all tasks issued under this subcontract. Upon identification of any shortcomings that will impact tasks assigned by this effort, the Contractor shall undertake corrective action, and notify the Customer within 15 calendar days.
Quality of Delivered Software
4.3 Amendable, modular and working software shall be delivered in correlation with the end of every PI. Software shall be developed at a sustainable constant pace, software code shall focus on simplicity and, to the extent practicable, software shall be designed so that it may be testable with approved automated testing tools.
Quality of Delivered Documentation
4.7 Documentation shall be written in the “just barely good enough” Agile manner. Documents shall contain minimum information while actively pursuing the limiting of text overlap between other documents. Documents shall be for stable concepts, not for speculative ideas. System generated documentation shall be preferred over manually generated. Documentation shall take an evolutionary (iterative & incremental) approach to development. There shall be NO penalty for draft documentation being provided early for review by document consumers due to inaccurate content or grammar errors. All documents shall meet a need and not a want. Documentation shall be treated as PI Objectives. Quality of Technical Orders (TOs) and Time Compliance Technical Orders (TCTOs) are directed by A018.
| Performance Objective |
| PWS |
Performance Threshold
Quality of CDRL Deliverable
4.11.1 There shall be no more than one rejection of any CDRL deliverable. There shall be no more than two total rejection(s) of CDRL deliverables per contract year. The Government will reject a CDRL deliverable if one or more technical errors or two or more minor errors are found within the deliverable. The rejected deliverable shall be corrected and resubmitted within ten business days of notification of Government rejection. This specification does not apply to delivered working data submitted as part of design integration and testing procedures or troubleshooting measures.
Receipt of CDRL Deliverable
4.11.2 CDRL deliverables shall be submitted via Intelink and Platform One with notification to the Multi-function Team (MFT) member identified on the CDRL. There shall be a preference for Automated Publishing over Manual transmittal. There shall be no more than one (1) late submission of final deliverables per contract year. The Contractor shall notify the Government if the delivery of any data/document will not meet the scheduled delivery date and negotiate a revised delivery date. The data/document shall be delivered by the revised delivery date acceptable to the Government.
Automated Testing
4.3.3 There shall be at a minimum 75% code coverage utilizing unit tests on all new code delivered each iteration. The Contractor will employ aggressive application of automated testing to ensure regression testing is accomplished at a minimum of at the end of each iteration. Automated tests will be delivered with each software delivery.
| Performance Objective |
| PWS |
Performance Threshold
Acceptance Testing (AT), Integrated Acceptance Testing (IAT) and System Acceptance Testing (SAT)
4.3.4 In accordance with (IAW) the approved test procedures, ninety percent (90%) of all manual tests shall pass on the first attempt with no Category I (CAT I) Emergency or CAT I Urgent deficiencies IAW T.O. 00-35D-54, USAF Deficiency Reporting, Investigation, and Resolution. The remaining 10% shall pass on the second attempt with no CAT I Emergency or Urgent deficiencies. Using the Continuous Integration/Continuous Delivery (CI/CD) process in the CTE, 100% of test procedures shall pass to complete testing in the automated environments.
T.O. 00-35D-54 Deficiency Reporting is also applicable as previously stated.
Security Controls
5.2.7 The Contractor shall implement 100% of required Security Controls identified by the Customer Cyber Security Specialist in accordance with the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, Security and Privacy Controls for Federal Information Systems and Organizations.
Mishap Notification and Reporting
5.5.2 No more than one (1) instance of late mishap notification allowed per year.
Contractor Manpower Reporting
5.7 Within 30 calendar days of contract/order award, the Contractor shall establish a record for the contract/order in System for Award Management (SAM) including Order Data, Contact Data and Location Data. The Contractor shall provide a count of Contractor and sub-contractor personnel performing services for each fiscal year and report all Contractor/subcontractor labor hours required for performance of services for each fiscal year.
All data shall be reported no later than October 31 of the following fiscal year.
| Adherence to Contractor Quality Management System (QMS) |
| 5.9 |
| The Contractor shall ensure the quality of services through a quality and/or inspection system. The Contractor shall submit a Quality Control Plan (QCP) addressing detection of quality program problems and defects, identification of root causes for quality related problems/defects, correction of root causes related to detected problems/defects, and follow-up to ensure quality related problems/defects do not recur. The plan shall include the schedule of quality assurance/control inspections planned by the Contractor. 100% compliance with the QMS is required. |
2.2 Deficiency Categories
The following table defines the test deficiency categories as defined by the Configuration Management Plan (CMP).
Table 2.2: Deficiency Categories
| Category I |
| Impact |
C1E If uncorrected, may cause death, sever injury or severe occupational illness and no workaround is known; or, if uncorrected, may cause major loss or damage to equipment or a system and no workaround is known; or, prevents the accomplishment of an essential capability or critically restricts Operational Safety, Suitability and Effectiveness (OSS&E), to include required interaction with other mission critical platforms or systems; and no acceptable workaround is known.
C1U Adversely affects an essential capability or negatively impacts operational safety, suitability or effectiveness and no acceptable workarounds are known or adversely affects technical, cost or schedule risks to the project or to life cycle support of the system, or results in a production line stoppage and no acceptable workaround is known.
| Category II |
| Impact |
C2U Adversely affects an essential capability or negatively impacts operational safety, suitability or effectiveness and adequate performance is achieved through significant compensation or acceptable workaround and or adversely affects technical, cost or schedule risks to the project or to life cycle support of the system, but an acceptable workaround is known.
C2R Does not affect an essential capability but may result in user/operator inconvenience or annoyance.
Adequate performance is achieved through minimal compensation. Results in inconvenience or annoyance for development or maintenance personnel but does not prevent the accomplishment of the task. Adequate performance is achieved through minimal compensation. Any other effect (i.e., enhancements) having little or no impact to the OSS&E under current requirements.
3.0 Government Property:
Unless otherwise directed by the PO/PM, the Contractor shall perform work in accordance with the requirements specified herein Section 3.0 Government Property.
3.1 Contractor Responsibility: The Contractor shall be responsible for Government property in accordance with the Federal Acquisition Regulation (FAR) and as specified in the contract/order.
3.2 Government Property to be Provided: Government property to be provided includes:
3.2.1 The Government will provide the following GFE/GFI. Comment by HANSON, TIMOTHY G CIV USAF AFMC AFLCMC/C3IAK: Is our GFE list already in PIEE? Comment by COCHRAN, CHRISTOPHER S CTR USAF AFMC AFLCMC/C3IAD: There is no GFE for this contract. This section is simply in here as required "canned language"
| Item Description |
| Date Required |
| Period Required |
| Access to the ECH/WCH and OA DCGS Enterprise Support Services (ESS) |
| 1 Month After Receipt of Order (ARO) |
| Through contract completion |
| Access to DCGS System Integration Laboratories (DSIL) OA DCGS Stack and ESS at Robins AFB |
| 1 Month ARO |
| Through contract completion |
| Access to DCGS Release and Fielding Center at DGS-X at Langley AFB |
| 1 Month ARO |
| Through contract completion |
| OA Stack at the DSIL, ECH, and WCH (plus DGS-X as needed) |
| 1 Month ARO |
| Through contract completion |
| Access to DCGS Platform One, Confluence, and JIRA |
| 5 days ARO |
| Through contract completion |
Platform One (Contractor access request required)
| Contract award |
| Through contract completion |
| Item Description |
| Date Required |
| Period Required |
| Computer Software Product Executables |
| 1 Month ARO |
| Through contraction completion |
| Computer Software Product Code |
| 1 Month ARO |
| Through contraction completion |
| SOA–ESB Source Code Build Guide, Installation Guides, Administration/Configuration Guides, Security Hardening Guide, Software Version Description Document, Release Notes, Test Plans and Procedures, Test Scripts, Test Results, Test Reports, Analysis Reports, Programmer’s Guide, Integration Guide, Database Design Document, Quick Start Guide, Security Certification Document, and Capability Description Package |
| 1 Month ARO |
| Through contraction completion |
| SOA-ESB Software Development Kit (SDK) |
| 1 Month ARO |
| Through contraction completion |
| OA Stack Virtual Machine hosting configurations to include Security Technical Implementation Guides (STIGs), Puppet Scripts, necessary for SOA-ESB in-plant development and testing, and OA DCGS ESS configurations |
| 15 Days ARO |
| Through contraction completion |
| Software development Backlog |
| Contract award |
| With revisions when |
available
| SOA - ESB Capability User Stories |
| Contract award |
| With revisions when |
available
3.3. Base Support: The Government will furnish property incidental to the place of performance including office space and equipment, i.e., computer equipment, software, output device(s), phone/phone line, facsimile equipment, reproduction equipment and office supplies.
3.4. Reporting of Government Property: The Contractor shall have a system of internal controls to manage (control, use, preserve, protect, repair, and maintain) Government property in its possession in accordance with FAR 52.245-1, and its property management system shall be adequate to satisfy the requirements of this clause. The contractor shall record receipt and return of all Government Furnished Property (GFP), as well as the reporting of shipment, consumption, disposal, or transfer to another contract, in the GFP Module in Procurement Integrated Enterprise Environment (PIEE), https://piee.eb.mil, as stipulated by DFARS 252.245-7002. This reporting requirement does not change any liability provisions or other reporting requirements that may exist under the contract. GFP training and guidance is located at the DoD Procurement Toolbox at https://dodprocurementtoolbox.com/.
3.5. Loss of Government Property
3.5.1. Definition of Loss of Government Property: “Loss of Government property” means unintended loss of or damage to Government property including property that cannot be found after a reasonable search, loss due to inadequate storage, loss due to lack of security, theft, damage requiring repair to restore the item to usable condition, or damage that renders the property useless for its intended purpose or Beyond Economical Repair (BER). Loss of Government property does not include manufacturing defects, obsolescence, normal wear and tear, or purposeful destructive testing. Unless otherwise stated in the contract/order, loss of Government property does not include normal and reasonable inventory adjustments, i.e., losses of low priority consumable material, such as common hardware, as agreed to by the Contractor and the Government Property Administrator.
Comment by HANSON, TIMOTHY G CIV USAF AFMC AFLCMC/C3IAK: Missing paragraph? Comment by COCHRAN, CHRISTOPHER S CTR USAF AFMC AFLCMC/C3IAD: Corrected
3.5.2. Reporting Loss of Government Property: The Contractor shall report loss of Government property in the GFP Module located in PIEE, https://piee.eb.mil/piee-landing/.
3.5.3. Return or Retention of Government Property: All property provided by the Government remains the property of the Government and shall be returned to the Government as directed, but no later than completion of the contract/order, unless the Procuring Contracting Officer (PCO) directs the Contractor to retain the property for continued use under a successor contract. All Government property shall be returned to the Government in the condition provided unless approved in advance by the PCO. All material generated under the contract/order becomes the property of the Government and shall be returned to the Government as directed, but no later than completion of the contract/order, unless the PCO directs the Contractor to retain the material for continued use under a successor contract.
4.0 Technical Requirements
4.1 Software Development
At a minimum, the contractor shall develop capability to include consideration of the following architecture concepts and address each concept during requirement refinement (A021):
· Information Assurance/Cybersecurity – to support a secure, software development life cycle and maintain ATO (A021, A022)
· Federation Architecture Tools and Services – to support exercise and operational interoperation with other capabilities and dependencies (A021, A022)
· Web Service Security - Define the impact the capability has on the security architecture. (A021, A022)
· Documentation - Ensure each capability is sufficiently documented to support DCGS PoR integration, test, exercise and operational activities (A021, A022)
· Metrics - Each capability developed shall be evaluated and if necessary, enhanced in order to collect system and enterprise level metrics (e.g., number of items retrieved) (A021, A022)
· Sustainability – Consideration should be given to best development practices that reduces the amount of or prevents creation of additional technical debt. (A021, A022)
4.2 Scrum Master
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. Scrum Masters assist the Product Owner and the organization in facilitating understanding and practice of Agile. (A003)
· The contractor shall provide at least one Scrum Master and the government will provide at least one Scrum Master to ensure that there is at least one dedicated Scrum Master for every two teams of developers. (A003)
· Scrum Masters will serve as support to the SOA ESB Agile Team as directed by the government Product Owner. (A003)
4.3 Software Architecture
· The contractor shall perform software engineering and architectural design. The contractor shall provide the PMO with architectural and design engineering as directed by the Government and support technical evaluations/analysis with the DCGS Enterprise and Platform One to include, but not limited to (A003, A018, A021, A022, A027):
· Recommendations regarding the establishment and composition of DCGS Enterprise and P1 services and capabilities, (A003, A018, A021, A022, A027)
· Recommendations to align SOA-ESB with industry and Government technology best practices, standards and specifications. (A003 A018, A021, A022, A027)
· Recommendations to the government to align the SOA-ESB development effort with industry best Agile practices, (A003, A018, A021, A022, A027)
· Coordination with PMO IPT members, Government engineers, test representatives, and all stakeholders. (A003, A018, A021, A022, A027)
4.3.1 The contractor shall conduct architectural and software engineering support for all activities, including SOA-ESB development, integration, test, and documentation as well as, but not limited to (A003, A021, A022, A023):
· The contractor shall provide engineering support to continually assess impacts of design and implementation. (A003, A021, A022, A023)
· The contractor shall ensure that the development activities will implement the functionality accepted into User Story and Backlogs by the integrated development team as part of the Agile development process. (A003, A021, A022, A023)
· The contractor shall provide recommendations regarding Distributed Data Framework (DDF) updates and potential configuration changes, SOA-ESB application packaging, and delivery. (A003, A021, A022, A023)
· The contractor shall ensure that new development will not impair or disable the existing functionality without PMO approval. (A003, A021, A022, A023)
· The contractor shall ensure the SOA-ESB consists of independent applications that are separately packaged and released to a Catalog Framework. Applications can be easily replaced in the SOA ESB without changing other applications’ features and/or bundles. (A003, A021, A022, A023)
4.4 The contractor shall conduct technical exchange sessions as directed, supporting architecture and design of SOA-ESB, including, but not limited to (A003, A018, A021, A022, A023, A027):
· Provide engineering support to the PMO team for technical exchanges with community stakeholders. (A003, A018, A021, A022, A023, A027)
· Conduct user site visits, telecons, and other venues of direct and indirect support for integration, test and fielding, and other tasks as required by the government. (A003, A018, A021, A022, A023, A027)
· The contractor shall provide architectural engineering support to the Product Owner meetings on request of the government. (A003, A018, A021, A022, A023, A027)
4.5 Research
· The contractor shall, if directed by the Government, conduct research above and beyond normal accomplished research during development on new feature requests or architectural changes that require long lead time.
4.6 Release Management
· The Contractor shall provide recommendations on managing, planning, scheduling and controlling software build(s) through different stages and environment, including testing and deploying software releases. (A021, A022)
· Software Code Drops: The contractor shall support nightly source code drops for testing in the PMO Continuous Integration Environment (A021, A022)
4.7 Software documentation
The contractor shall deliver all developed software, software capabilities, and respective product documentation IAW PMO documentation requirements which provides a detail level consistent with existing SOA-ESB documentation for incorporation into the documentation set maintained by the test and integration members of the product team (A021, A022)
· Software (source code including all associated files such as properties files and scripts, executables, and Open Service Gateway initiative (OSGI) ;bundles) (All delivered software will be government unlimited rights) (A021)
· Software Development Kit (SDK) (A021, A022)
· Interface Control Document (ICD) (A021, A022)
· Installation Guides (IG) that result in the installation of a SOA - ESB with a Government-specified set of capabilities (A021, A022)
· Administration/Configuration Guide (A021, A022)
· Security Hardening Guide, if necessary (A021, A022)
· Software Version Description Document (SVDD) (A021, A022)
· Release Notes (A021, A022)
· Test Scripts (A021, A022)
· Test Results (A021, A022)
· Analysis Reports (i.e., Performance, technology assessments) (A021, A022)
· Programmer’s Guide (A021, A022)
· Integration Guide (A021, A022)
· Feature guides that describe installation, administration, configuration, and integration of those features not installed by using the Installation Guides described in 3.10.4 (A021, A022)
· Trusted Facility Manual (TFM) (A021, A022, A024)
· Standard Operating Procedures (A048)
4.8 Information Assurance
· The contractor shall support the Government in information assurance certification processes and testing as directed by the PMO. (A003, A022)
4.9 Community Support
· The contractor shall provide community support as directed by the Government. This support includes, but is not limited to, providing technical support, exercise and operational support, deficiency fixes to previous versions of the SOA-ESB, SOA-ESB training, or system integration support to Government services and agencies and their integration contractors. (A003, A017, A018, A023, A027)
4.10 Period and Place of Performance
4.10.1 Contract/Order Period of Performance The basic contract's Ordering Period will be four (4) years consisting of a basic year and three (3) optional one-year ordering periods. The Period of Performance of each order will be determined at the Task Order level, potentially extending beyond the Ordering Period by up to twelve months. Comment by HANSON, TIMOTHY G CIV USAF AFMC AFLCMC/C3IAK: five (5)* Comment by COCHRAN, CHRISTOPHER S CTR USAF AFMC AFLCMC/C3IAD: Corrected. Should actually be 4 in order to keep it <$10M
4.10.2 Place of Performance: The Contractor’s primary place of performance will be its own facilities as well as Government sites within the Continental United States (CONUS) and outside the Continental United States (OCONUS) as follows: Comment by HANSON, TIMOTHY G CIV USAF AFMC AFLCMC/C3IAK: We will need to add each site our pre RFP DD254 and to our award DD254 Comment by COCHRAN, CHRISTOPHER S CTR USAF AFMC AFLCMC/C3IAD: Acknowledged
· DGS-X, Langley AFB, VA
· East Coast Hub, Langley AFB, VA
· West Coast Hub, Beale AFB, CA
· DGS-1, Langley AFB, VA
· DGS-2, Hickam AFB, HI
· DGS-3, OCONUS
· DGS-4, Ramstein AFB, Germany
· DGS-5, Hickam AFB, HI
4.10.3 Contractor Key Personnel Qualifications and Management: The Contractor shall provide qualified personnel (both technical and management) in order to meet all tasks issued under this contract. Upon identification of any shortcomings that will impact tasks assigned by this effort, the Contractor shall undertake corrective action, and notify the Customer within 15 calendar days (A008).
4.10.4 Contractor shall deliver a comprehensive integrated master schedule (IMS) that reflects the iterative and incremental nature of the program in contractor format. The IMS shall include all contractor teams, their sprints, dependencies, risks, and milestones. It shall be a living document updated regularly during each PI and communicated clearly to all stakeholders, including the customer and any subcontractors. The IMS shall be used as a tool for monitoring and controlling the program, identifying issues or delays, and taking appropriate action to mitigate them. in accordance with associated CDRL (A007).
4.10.5 Contact shall provide Software Product Specification (SPS) in accordance with associated CDRL (A032).
4.10.6 The Contractor will maintain an internal Self-Assessment Program (SAP) to evaluate the effectiveness of existing procedures and internal controls, to determine organizational compliance with regulatory requirements and to complement external inspections and assessments.
4.10.7 The Contractor shall provide support, as required, for contingencies, exercises, and surge operations. The Product Owner/Product Manager (PO/PM) will notify the Contractor as soon as notification of upcoming event becomes known.
4.11 Contract Data Requirements List(s) (CDRL) Comment by HANSON, TIMOTHY G CIV USAF AFMC AFLCMC/C3IAK: This CDRL list will be finalized after our Data call. PK will need a copy of the signed 1423s when received. Comment by COCHRAN, CHRISTOPHER S CTR USAF AFMC AFLCMC/C3IAD: Acknowledged
The following Contract Data Requirements Lists (CDRLs) will be delivered as part of this effort:
| Item Number Base Year |
| Item Number O/Y 1 |
| Item Number O/Y 2 |
| DID |
| Title |
| PWS Reference(s) |
| A003 |
| B003 |
| C003 |
| DI-ADMN-81373/T |
| Presentation Materials - PMR/Kickoff/Weekly Status Telecons/In Person Meetings |
| 4.2, 4.3, 4.3.1, 4.4, 4.8, 4.9 |
| A005 |
| B005 |
| C005 |
| DI-MGMT-81468/T |
| CONTRACT FUNDS STATUS REPORT (CFSR) |
| 5.6 |
| A007 |
| B007 |
| C007 |
| DI-MGMT-81650/T |
| Integrated Master Schedule |
| 4.10.4 |
| A009 |
| B009 |
| C009 |
| DI-CMAN-1248B/T |
| INTERFACE CONTROL DOCUMENT (ICD) |
| 4.7 |
| A013 |
| B013 |
| C013 |
| DI-IPSC-81442A/T |
| SOFTWARE VERSION DESCRIPTION Document (SVDD) |
| 4.7 |
| A017 |
| B017 |
| C017 |
| DI-ILSS-80872/T |
| TRAINING MATERIALS |
| 1.1, 1.3, 4.9 |
| A018 |
| B018 |
| C018 |
| TM-86-01Q CONTACT TOMA |
| AF TECHNICAL MANUAL CONTRACT REQUIREMENTS |
| 1.1, 1.3, 2.1, 4.3, 4.4, 4.9, 4.13 |
| A021 |
| B021 |
| C021 |
| DI-AVCS-80700A/T |
| COMPUTER SOFTWARE PRODUCT END ITEMS (Executables and Source Code) |
| 4.1, 4.3, 4.3.1, 4.6, 4.7 |
| A022 |
| B022 |
| C022 |
| DI-NDTI-80566A |
| TEST PLANS / TEST PROCEDURES |
| 4.1, 4.3, 4.3.1, 4.4, 4.6, 4.7, 4.8 |
| A023 |
| B023 |
| C023 |
| DI-NDTI-80809B/T |
| TEST/INSPECTION REPORT |
| 1.1, 4.3, 4.4, 4.9 |
| A024 |
| B024 |
| C024 |
| DI-TMSS-81352/T |
| TRUSTED FACILITY MANUAL (TFM) |
| 4.7 |
| A027 |
| B027 |
| C027 |
| DI-MISC-80508B/T |
| TECHNICAL REPORT-STUDY/SERVICES |
| 1.1, 4.3, 4.4, 4.9 |
| A032 |
| B032 |
| C032 |
| DI-IPSC-81441A/T |
| SOFTWARE PRODUCT SPECIFICATION (SPS) |
| 4.14.2 |
| A040 |
| B040 |
| C040 |
| DI-CMAN80858C |
| Contractor's Configuration Management Plan |
| 4.14 |
| A048 |
| B048 |
| C048 |
| DI-MGMT81580 |
| Contractor’s Standard Operating Procedures (SOP) |
| 4.7 |
4.11.1 Quality of CDRL Deliverable: There shall be no more than one (1) rejection of any deliverable. There shall be no more than two (2) total rejection(s) of deliverables per contract year. The Government will reject a deliverable if one (1) or more technical errors or two (2) or more minor errors are found within the deliverable. A technical error is defined as the format not being in accordance with the CDRL or the content not being accurate and complete in accordance with the CDRL, PWS or contract. A minor error is exemplified by a typographical error, a grammatical error, etc. The rejected deliverable shall be corrected and resubmitted within ten (10) business days of notification of Government rejection. (A021)
4.11.2 Receipt of CDRL Deliverable: CDRL deliverables shall be submitted via Wide Area WorkFlow (WAWF) and/or Platform One, as applicable, with notification to the MFT member identified on the CDRL. There shall be no more than one (1) late submission(s) of deliverables per contract year. The Contractor shall notify the Government if the delivery of any data/document will not meet the scheduled delivery date and negotiate a revised delivery date. The data/document shall be delivered by the revised delivery date acceptable to the Government. (A021)
4.12 Holidays and Facility Closings: Contractor/subcontractor personnel shall observe holidays and facility closings as authorized for government personnel. Contractor/subcontractor personnel shall only be permitted access to Government facilities when Government personnel are present.
4.13 The Contractor shall travel, as required, authorized and funded, to the Government or other facilities as directed by the Customer to attend project reviews and meetings. The Contractor shall travel to specified Contractor and operational sites to conduct TEMs, site surveys, installations, tests and both formal and informal training support events as well as Technical Order and Time Compliance Technical Order in Process Reviews and TO/TCTO Verification/Validation events. Travel requests for contractor/subcontractor personnel shall be submitted for approval to the Contracting Officer prior to costs being incurred and a minimum of ten (10) business days in advance of departure. Receipts must be presented with the invoice for reimbursement of actual travel costs.
4.14 Configuration and Data Management
The Contractor shall conduct CM in accordance with SAE EIA-649. The Contractor shall comply with CM requirements listed below and in accordance with the Contractor’s CM Plan. The contractor shall levy these same CM requirements to any tier of subcontractor. The Contractor shall use a CM process to control and tie, trace, and link all configuration information representing or comprising the system/configuration item. The contractor shall use Digital Engineering (DE) tools for configuration and data management processes, activities, and artifacts. The Contractor shall implement CM addressing Configuration Planning and Management, Configuration Identification, Configuration Change Management, Configuration Status Accounting (CSA), Configuration Verification and Audits, Data Management, and Deficiency Reporting. The Contractor shall generate updates to the CM Plan for Government approval. The Contractor shall measure the CM performance metrics identified in the CM Plan. (A040), DI-SESS-80858, Supplier’s Configuration Management Plan).
4.14.1 Configuration Identification.
The Contractor shall use a documented process for configuration identification IAW the CMP and the following paragraphs. The Contractor shall recommend potential CIs/CSCIs for Government review and selection concurrence utilizing the criteria in the CMP. The Contractor shall mark or label items and information with their applicable identifiers.
The Contractor shall establish and generate a CI and CSCI structure and hierarchy (A097). In addition, the Contractor shall ensure configuration information and artifacts tie, trace, and link from top-level/end item to the lowest component.
The Contractor shall develop Eracent custom software signatures IAW DCGS-PRCD-ENT-0003_Rev-7, Eracent Custom Software Integration Guide.
The link to the CI Listing is: https://intelshare.intelink.gov/sites/isrdcgsaf/DCGS/library/PPPP/04_Configuration_Data_Management/Policy%20Letters/DCGS-BRF-ENT-0001_Rev-2_Configuration_Item_Listing_20211115.pdf?Web=1
The link to the CI ID and Naming Schema is: https://intelshare.intelink.gov/sites/isrdcgsaf/DCGS/library/PPPP/04_Configuration_Data_Management/Policy%20Letters/DCGS-PLC-CDM-0008_Rev-1_Configuration_Item_(CI)_ID_and_Naming_Schema.pdf?Web=1
4.14.2 Configuration Baselines.
The Contractor shall generate the configuration information required for the configuration baselines being established by the Government IAW MIL-STD-961 and shall tie, trace and link all configuration information and artifacts to the lowest component that makes up a configuration baseline(s). The Contractor shall maintain the current approved configuration information creating a new revision to configuration information after a change approval. (A013, DI-IPSC-81442A/T, Software Version Description (SVD) using the government provided template; A032, DI-IPSC-81441A/T, Software Product Specification (SPS))
4.14.3 Configuration Change Management
The Contractor shall apply configuration control to each CI/CSCI and its components and configuration information. The Contractor shall confirm configuration baselines are maintained and controlled, configuration identification control of all CIs/CSCIs and their associated configuration information is maintained, all configuration information and artifacts are tied, traced and linked, and the ASoT is updated. The Contractor shall support a joint Government/Contractor Configuration Control Board(s) chaired by the Government and IAW the CM
4.14.4 Data Management
The Contractor shall establish a data management program for identifying, generating/acquiring, and controlling technical and management product data and related information. The Contractor shall implement and maintain data management procedures for preparation, quality control, administration and delivery of data required by the CDRL IAW Exhibits found in the contract and tie, trace and link the data to build the digital thread. The contractor shall utilize the AFLCMC approved data repository and management tool to deliver CDRL data to the Government in accordance with the CDRLs and the CDRL Instructions that are part of the CDRL package and contract. The Contractor shall maintain data status and delivery schedules for all CDRL items. The Contractor shall provide a central point of contact for data management.
4.14.5 Technical Data
The Contractor shall provide material and labor necessary to maintain engineering drawings (A015, DI-SESS-81000F/T), technical manuals (A018, TM-86-01R), Operation and Maintenance (O&M) manuals (A018, TM-86-01R), and other system documents as it applies to the baseline system and software. All documentation provided shall be prepared and administered IAW the CDRLs.
4.14.6 Eracent Signature Requirement
The Contractor shall develop Eracent custom software signatures IAW DCGS-PRCD-ENT-0003_Rev-7, Eracent Custom Software Integration Guide.
5.0 General Information
5.1 The Continuation of Mission-Essential Services During a Crisis: The Functional Service Manager (FSM) has determined these services are not mission-essential and will not continue in the event of a crisis.
5.2 Security Requirements
5.2.1 Security Regulations: The Contractor shall ensure personnel, information, system, property, facility and, if applicable, international security requirements are met. The Contractor shall ensure contractor/subcontractor personnel who perform work on a Government facility comply with the security requirements of the facility. The Contractor shall comply with the following security regulations: 32 CFR Part 117 DoD 5220.22-M, National Industrial Security Program Operating Manual (NISPOM); DoDM 5200.01 AFMAN 16-1404, Vol 1-3.
5.2.2 Operations Security (OPSEC): The purpose of OPSEC is to reduce the vulnerability of USAF missions to adversary collection and exploitation of critical information. DoDD 5205.02E and DoD Manual 5205.02-M require contractors supporting DoD activities use OPSEC to protect critical information for specified contracts, subcontracts, and information used in the performance of duties in support of Air Force requirements/missions. The Contractor shall ensure Contractor personnel who perform work on (or in) a Government facility comply with the OPSEC procedures and training requirements of the facility as specified in AFI 10-701.
5.2.3 Communications Security (COMSEC): The Contractor shall use only secure communications methods and/or equipment to transmit or otherwise transfer classified information and/or Controlled Unclassified Information (CUI) in accordance with 32 CFR Part 117, National Industrial Security Program Operating Manual (NISPOM), § 117.7(a).
5.2.3.1 Protection of Information: CUI is any information that law, regulation, or government wide policy requires to have safeguarding or disseminating controls, excluding information that is classified under Executive Order 13526, Classified National Security Information, December 29, 2009, or any predecessor or successor order, or the Atomic Energy Act of 1954, as amended. The National Archives and Records Administration (NARA) CUI Registry (http://www.archives.gov/cui/registry/category-list.html) identifies approved CUI categories and subcategories, provides general descriptions for each, identifies the basis for controls, and sets out procedures for the use of CUI.
5.2.3.2 The contractor shall comply with DoDI 5200.48, Controlled Unclassified Information, DoDM 5200.01 AFMAN 16-1404, Vol 1-3, and Air Force Guidance Memorandum 2020-16-01, Air Force Guidance Memorandum for CUI, 23 July 2020. The contractor will consult the applicable security classification guide to monitor CUI aggregation for potentially generating classified information by compilation. The Contractor shall comply with DoDM 5400.07/Air Force Manual 33‑302, DoD Freedom of Information Act (FOIA) Program, requirements.
5.2.3.3 Protection of CUI and unclassified DoD information not approved for public release on non-DoD Information Systems will be protected IAW DoDI 8582.01, Security of Non-DoD Information Systems Processing Unclassified Nonpublic DoD Information. Unless specific categories of CUI require more stringent controls, non-DoD Information Systems must be protected using the guidelines set forth in NIST Special Publication 800-171, Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations.
5.2.3.4 Covered Defense Information: The Contractor shall comply with DFARS 252.204-7012 Safeguard Covered Defense Information and Cyber Incident Reporting (Dec 2019) This subpart applies to contracts and subcontracts requiring contractors and subcontractors to safeguard covered defense information that resides in or transits through covered contractor information systems by applying specified network security controls. It also requires reporting of cyber incidents. The subpart does not abrogate any existing contractor physical, personnel, or general administrative security operations governing the protection of unclassified DoD information, nor does it impact requirements of the National Industrial Security Program.
5.2.4 The Contractor shall ensure applicable contractor/subcontractor personnel have security clearance(s) at the TS-SCI level for proper accomplishment of contract/order requirements. The security clearance(s) shall be obtained in accordance with the Department of Defense (DD) Form 254, Department of Defense Contract Security Classification Specification.
5.2.5 Security Incident or Violation: The Contractor shall immediately notify the Government Security Office of any potential or actual security incident or violation.
5.2.6 Access to Government System(s): The Government will provide contractor/subcontractor personnel access to system(s) necessary to perform tasks under the contract/order. The Contractor shall ensure contractor/subcontractor personnel who require access to an unclassified or classified Government Automated Information System (AIS) have the respective background check or security investigation conducted. At a minimum, the Contractor shall ensure contractor/subcontractor personnel who require access to an unclassified AIS have a National Agency Check with Inquiries (NACI) conducted. Upon completion/termination of the contract/order or transfer/termination of contractor/subcontractor personnel, the Contractor shall ensure the system account(s) are closed.
5.2.7 Access to Government Facility or Military Installation: The Contractor shall ensure contractor/subcontractor personnel who require access to a Government facility or military installation comply with the security requirements of the facility or installation.
5.2.8 Common Access Card (CAC)
5.2.8.1 The Contractor shall ensure a CAC is obtained by all contractor/subcontractor personnel who require access to DoD computer networks/systems, for DoD facility entry control and/or for physical access to facilities and buildings to perform tasks under the contract/order. The Contractor shall provide a list of contractor/subcontractor personnel who require a CAC to the COR. The Government will provide the Contractor instruction on how to complete a Trusted Associate Sponsorship System (TASS) application and notify the Contractor of approval/disapproval of contractor/subcontractor personnel application. Contractor/subcontractor personnel shall obtain the CAC from the local Real Time Automated Personnel Identification Documentation System (RAPIDS) issuing facility [usually the Military Personnel Flight (MPF)].
5.2.8.2 The Contractor shall immediately report a lost or stolen CAC as directed by local Government policy. The Contractor shall notify the COR of any change to the list of contractor/subcontractor personnel who require a CAC and provide an updated list within five business days. The Contractor shall return a CAC within five business days once contractor/subcontractor personnel no longer require computer network/system access and/or facility access. The Contractor shall return an expired CAC within five business days after the expiration date. The Contractor shall return any and all CACs within five business days after completion/termination of the contract as directed by local Government policy.
5.3 Environmental Management System (EMS): Contractor/subcontractor personnel who perform work on any Government facility shall comply with the EMS requirements established by the facility. Contractor/subcontractor personnel may be required to complete EMS training prior to beginning work.
5.4 Agency Affirmative Procurement Programs: This acquisition does not require the purchase of Environmental Protection Agency (EPA)-designated products or United States Department of Agriculture (USDA)-designated products; therefore, the requirement does not apply.
5.5 Safety Requirements
5.5.1 Contractor Compliance: The Contractor shall comply with Government Safety and Health regulations including, Public Law 91-596 as amended by Public Law 101-552 [Occupational Safety and Health Act of 1970 (OSHA)] and DoDD 4715.1E, Environment, Safety, and Occupational Health (ESOH).
5.5.2 Mishap Notification/Investigation: The Contractor shall report mishaps including damage to DoD property; occupational illness to DoD military or civilian personnel; injury to on- or off-duty DoD military personnel; injury to on-duty DoD civilian personnel; and damage to public or private property or injury or illness to non-DoD personnel caused by Government operations. In the event of a mishap, the Contractor shall ensure the USAF is notified of the mishap. The Contractor shall contact the organizations listed below within four business hours. The Contractor shall immediately secure the mishap scene (and damaged property) and impound pertinent maintenance and training records until released by the Government’s Safety Office (AFLCMC/SE). Such release shall be accomplished through the Contracting Officer. The Contractor shall cooperate and assist Government personnel in the investigation of the mishap and submit an Accident/Incident Report within 24 hours of the mishap. No more than one (1) instance of late mishap notification per year.
5.5.3 Voluntary Protection Programs (VPP): Contractor personnel performing work on a USAF installation shall participate in the local VPP.
5.5.4 VPP Description: In 1982, OSHA created the Voluntary Protection Programs (VPP) to recognize and partner with worksites that implement exemplary systems to manage worker’s safety and…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .