DIB_SOW_Draft.pdf

FA8730-17-R-0024, Attachment 1, Page 1

ATTACHMENT 1 - STATEMENT OF WORK

FOR THE

DISTRIBUTED COMMON GROUND/SURFACE SYSTEM (DCGS)

INTEGRATION BACKBONE (DIB)

FIFTH EDITION CONTRACT

6 June 2017

Version: Original

FA8730-17-R-0024, Attachment 1, Page 2

1.0 Introduction

1.1 The Distributed Common Ground / Surface System (DCGS) Integration Backbone

(DIB) is a common set of enterprise services that provide the necessary functionality to interface information services such that the DCGS Enterprise has the capability to exchange data and information. The DIB provides the DCGS systems with data discovery and retrieval services that identify what information is available, where the information is located, and will transmit specific data selected. Lastly, the DIB provides enterprise-wide software services for security, web access, knowledge management and other basic features. The DIB 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 DIB services as required by the Government.

1.2 The DIB is developed and managed by the DCGS Multi-Service Execution Team

(MET) Office (DMO) located at Hanscom AFB in Massachusetts. The DIB and the information services implemented in the DoD DCGS Enterprise improve the interoperability that is the key to the collaborative and distributed requirements of the vision described in the Initial Capabilities Document (ICD) for the DCGS Enterprise and the Technical Requirements Document for the DIB. Open and documented standards (commercial and government) are critical to this effort. The intent is to reduce the proliferation of proprietary solutions and interfaces for the DCGS

Enterprise. The DIB provides the tools, architecture, standards, and documentation to support interfaces for the Department of Defense (DoD) DCGS community to achieve a Multi-INT (e.g., Imagrey Intellegence (IMINT), Signals Intellegence

(SIGINT), Measure and Signature Intellegence (MASINT), Counter

Intellegence/Human Intellegence (CI/HUMINT)), network centric environment with interoperability to allow individual DCGS systems and users access to the information needed to execute their respective missions.

1.3 The contractor shall participate in DIB Agile methodology development as directed by the DMO. The DMO’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.

1.4 DIB development activity is expected to include efforts focused on architecture design, architecture framework development, feature development and enhancement, development testing, and release activity.

1.5 DIB development activities may also include providing support to the DCGS community. This support may include, but is not limited to DIB integration support, system integration support, training, problem debug and issue resolution, Deficiency

Report (DR) fixes and operations and exercise support.

1.6 Definitions:

FA8730-17-R-0024, Attachment 1, Page 3

1.6.1 Agile software development: A software development methodology based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

It promotes adaptive planning, evolutionary software development, testing and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

1.6.2 Use Case: Description of overall an objective capability or application. Use cases are driven by operational requirements. A use case can also be called a theme in the terminology of the Scrum method of Agile development.

1.6.3 Use Case Champion: A DCGS Program of Record (PoR)Stakeholder or any other community stakeholder with a high degree of interest in the development of a given objective capability. The champion may act as or provide access to subject matter experts to provide guidance and users’ perspective to the development effort.

1.6.4 Product backlog: An ordered list of everything that might be needed in the product and is the single source of requirements for any change to be made to the product. The Product Owner is responsible for the Product Backlog (The

Scrum Guide).

1.6.5 Sprint Backlog: The set of Product Backlog Items selected for the Sprint (The

Scrum Guide).

1.6.6 Product Backlog Item: Requirement in the backlog (epic, user story, bug, technical debt, improvement, test ticket etc.) Each product backlog item (PBI) should have acceptance criteria.

1.6.7 Epic: High level functionality, written from a user’s perspective addressing

Use Case requirements; too large to be implemented in a single sprint cycle or user story; typically decomposed into multiple user stories. Implements specific capabilities of a use case. Defined by agreed-to exit criteria representing approved requirements for the epic development period.

1.6.8 User Story: A short description of a requirement written from the users’ perspective and typically follows the following template:

As a <type of user>, I want <some goal> so that <some reason> (e.g. as a system administrator, I want a User Interface so that I can view system utilization).

1.6.9 Definition of Done: The satisfaction of the Government agreed-to exit criteria, representing approved requirements, of each sprint (User Story/Epic/Use Case capability/Use Case) to determine whether a completed product backlog item is sufficient for delivery.

FA8730-17-R-0024, Attachment 1, Page 4

1.6.10 Sprint: A time period (usually 2 to 4 weeks, determined by the government, in which development occurs on a set of product backlog items that the team has committed to completing.

1.6.11 Increment: the sum of all product backlog items completed during a

Sprint and the value of the increments of all previous Sprints. The new increment must meet the government approved definition of done. The increments must be working software.

1.7 References

1.7.1 MET Configuration Management (CM) Plan*

1.7.2 DoD/IC Content Discovery & Retrieval Specifications

1.7.3 Reserved

1.7.4 Distributed Common Ground System (DCGS) Integrated Backbone (DIB)

Technical Requirements Document

1.7.5 The Scrum Guide by Ken Schwaber and Jeff Sutherland

*For access to the above reference documents will be provided at a later date.

FA8730-17-R-0024, Attachment 1, Page 5

2.0 Scope

2.1 This SOW describes the contractor’s required tasks in conducting DIB software development and associated DIB software, DCGS and Defense Intelligence

Information Enterprise (DI2E) 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 DIB development effort encompasses but is not limited to technical assessments, architectural design, software engineering, new feature development, improvement to existing functionality, configuration management, system test, Information Assurance (IA) artifacts development, IA testing and support, and DIB 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 and 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. DIB support currently also includes interfaces to open source communities/organizations (e.g. Codice, Apache, etc.) for things such as

DDF and Alliance support, development and other activities including recommended changes to the DDF or other DIB subcomponents. Similarly the Contractor must demonstrate understanding of Government off the shelf (GOTS), commercial off the shelf (COTS) or other government community designated components. DIB community support may also include providing technical support, exercise support, deficiency fixes to previous versions of the DIB, DIB training, or system integration support to Government services and agencies and their integration contractors.

3.0 Software Development

The contractor shall perform Agile Software Development in support of DIB and DIB related capability development. Unless directed by the Government, the contractor shall perform all

DIB architecture, development and community support efforts on the latest version of the

DIB software and subcomponents (currently current version of the DDF and Alliance). The

DIB 5th Edition contractor shall provide the necessary support as a key member of an integrated development team consisting of the DMO, DIB capability contractors, other designated support development and integration contractors, and Government agencies. The

DIB 5th Edition contractor will also serve key roles on the Product Owner Team or other process/support organizations as directed by the DMO. The organizations will work as part of an integrated development team (IDT) to design, develop, test, package, release, integrate and support the execution of DIB functionality. The DIB 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

FA8730-17-R-0024, Attachment 1, Page 6 requirements, designing, coding, unit/acceptance testing and functional Use Case and DIB 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 DMO Test Team will utilize Agile processes to develop tests and test scripts to perform Sprint and Use Case functional and performance tests on software deliveries to meet Government approved criteria. The contractor shall synchronize its efforts with the Government, DIB Product Owner, and DMO test team including the DCGS Test and Community Support team and any other third party government provided components (contractor and/or Government). The key activities to accomplish DIB architecture, development, and community support are specified below and directed by the Government.

3.1 Product Owner

3.1.1 This position will be filled by the Government.

3.1.2 The Government Product Owner is the head of the Product Owner Team

3.1.3 The Government Product Owner directs the development effort and is responsible for prioritization of the backlog.

3.2 The Product Owner Team (POT)

3.2.1 The Product Owner Team is composed of the government product owner, software architects, test subject matter experts, stakeholders, subject matter experts, and anyone that the government determines would be useful to accomplishing the DMO mission. Not every member participates full time;

the government will coordinate participation.

3.2.2 The contractor shall provide members and or support to the Product Owner

Team as directed by the government.

3.3 Scrum Master

3.3.1 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.

3.3.2 Scrum Masters assist the Product Owner, the DIB IDT and the organization in facilitating understanding and practice of Agile.

3.3.3 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.

3.3.4 Scrum Masters will serve as support to the Product Owner Team as directed by the government product owner.

3.4 Software Architecture

3.4.1 The contractor shall perform software engineering and architectural design.

3.4.2 The contractor shall provide the DMO with architectural and design engineering as directed by the Government and support technical evaluations/analysis with the DCGS Enterprise and DI2E with the following:

FA8730-17-R-0024, Attachment 1, Page 7

3.4.2.1 Recommendations regarding the establishment and composition of

DCGS Enterprise and DI2E services and capabilities,

3.4.2.2 Assessment and recommendations of new technologies impacting and supporting the DIB and DIB capabilities both internally and externally,

3.4.2.3 Recommendations to align the DIB with industry and Government technology best practices, standards and specifications,

3.4.2.4 Recommendations to the government to align the DIB development effort with industry best Agile practices,

3.4.2.5 Coordination with DIB development IPT members, Government engineers, test representatives, and all stakeholders.

3.4.2.6 Analysis of enterprise design implementation details and recommendations to DMO,

3.4.2.7 Assessment of changes to the DDF and Alliance from outside contributions (ex. Codice, Aphache, etc.) and recommendations for

DDF and Alliance changes impacting the DIB for Government review and approval,

3.4.2.8 Providing the above for Government review and approval and as potential presentation products in industry, other public and

Government forums as directed by the Government.

3.4.3 The contractor shall conduct architectural and software engineering support for all activities, including DIB development, integration, test and documentation.

3.4.3.1 The contractor shall provide engineering support to continually assess impacts of design and implementation.

3.4.3.2 The contractor shall ensure that the development activities will implement the functionality accepted into Use Case and overall DIB

Backlogs by the integrated development team as part of the Agile development process.

3.4.3.3 The contractor shall provide recommendations regarding DDF updates and potential configuration changes, DIB application packaging, and delivery.

3.4.3.4 The contractor shall ensure that new development will not impair or disable the existing functionality without DMO approval.

3.4.3.5 The contractor shall ensure the DIB consists of independent applications that are separately packaged and released to a Catalog

Framework. Applications can be easily replaced in the DIB without changing other applications’ features and/or bundles.

3.4.4 The contractor shall conduct technical exchange sessions as directed, supporting architecture and design of the DIB, including:

3.4.4.1 Provide engineering support to the DMO DIB team for technical exchanges with DIB community stakeholders.

FA8730-17-R-0024, Attachment 1, Page 8

3.4.4.2 Conduct user site visits, telecons, and other venues of direct and indirect support for DIB integration, test and fielding, and other tasks as required by the government.

3.4.4.3 Support all software architecture and software engineering as required by the government to fulfill the work identified in the rest of section 3.

3.4.4.4 The contractor shall provide architectural engineering support to the

Product Owner Team meetings on request of the government.

3.5 DIB Software and Capability Development

3.5.1 The contractor shall develop secure, reliable, resilient, and assured software.

The contractor shall support ‘flex force’ team concept which responds to changes and provides the Government with the flexibility to decrease or increase development velocity. The ‘flex force’ team concept allows the government to right size the development team size in response to development priority and workload changes.

3.5.1.1 The contractor shall develop, utilize, and maintain a secure coding guide for the program which specifies language, required constructs/practices/patterns, prohibited constructs/practices/patterns, and software comment requirements.

3.5.1.2 The contractor shall implement formal code inspection using commercial best practices to identify potential functionality flaws and security vulnerabilities.

3.5.1.3 The contractor shall assess all code against the Common Weakness

Enumeration (CWE), Common Vulnerabilities and Exposures

(CVE), and Open Web Application Security Project (OWASP) throughout the development effort and provide reports to the

Government summarizing the vulnerabilities and types of vulnerabilities found in terms of the specific CWE, CVE, and

OWASP identifiers found during each analysis and for the final delivery [DI-MISC-80508B].

3.5.1.4 The contractor shall test all software with a variety of simulated patterns of common attacks using security testing methodologies, including, but not limited to, fuzz testing, vulnerability testing, penetration testing, and misuse and abuse testing throughout the development effort and provide reports to the Government summarizing the patterns of attacks used, in terms of the CAPEC identifiers during each test activity and for the tests of the final delivery [DI-MISC-80508B].

3.5.1.5 The contractor shall ensure all developers (including subcontractors) are trained and held accountable for development of secure code.

3.5.1.6 The methodology to be used in performing security-related and software assurance activities for software shall be documented in the

Software Development Plan and Authorization to Operate (ATO) documentation as necessary.

FA8730-17-R-0024, Attachment 1, Page 9

3.5.2 Software Interfaces: Software interfaces (internal and external) shall be documented defining interface type and range to support DIB application or change development by a 3rd party contractor.

3.5.3 Software Tools: The contractor shall utilize DI2E software development and collaboration tools (Ref Para 7.0) and/or other government directed/provisioned tools/processes to maximize efficiency and effectiveness:

3.5.3.1 The contractor shall use automated tools to support software configuration control.

3.5.3.2 The contractor shall use static analysis tools to measure statement coverage, decision coverage, and modified decision coverage.

3.5.3.3 The contractor shall use Government-approved and directed, commercial tools to measure software quality, and assess vulnerabilities.

3.5.3.4 The contractor shall not disable, or mute, any software compiler warnings without express permission granted through a formal waiver request to the Government.

3.5.3.5 Software tools, if available as a shared resource, may be provided as

GFE to the contractor by the Government.

3.5.4 DMO Test Team and Test Process: The Contractor shall coordinate and integrate directly with the DMO Test Team (contractor and/or Government and/or other directed resources).

3.5.4.1 The DMO Test Team including third party government directed components (contractor and/or Government) provides independent verification & validation of DIB development. The contractor shall support the DMO Test Team as required by the government which could include

3.5.4.1.1 Developing tests and test scripts (when necessary) to agreed to test criteria for verifying acceptance criteria on product backlog items.

3.5.4.1.2 Working alongside and in sync with the government

and/or third party government directed contractor test team

3.5.4.1.3 Execution Test Script development in parallel with the development Sprint schedule

3.5.4.1.4 Participating in DIB IDT Sprint events (Daily Scrum, Planning, Sprint Review and Retrospectives) with the rest of the DIB IDT.

3.5.4.1.5 The Government Product Owner prioritizes the test

development tasks based on prioritized developer work

3.6 Information Transition: Upon award of next development contract, new contractor on the DCGS Test and Community Support contract, and/or new personnel in the DMO;

FA8730-17-R-0024, Attachment 1, Page 10 the contractor shall transfer DIB technical knowledge to the Government, including the DMO DIB engineer, DMO test manager, DCGS Test and Community Support

Enterprise Engineer (if applicable),DMO engineering and programmatic staff, and other Government organizations and PoR contractors. This effort shall include:

3.6.1 The knowledge transfer shall encompass all relevant technical information necessary for maintaining and updating the DIB.

3.6.2 The transition of this information shall be sufficient to mitigate risk associated with the transition of contractor developed capabilities to the

DMO, DCGS-I Test Lab (DTL), and other DoD organizations and contractors.

3.6.3 The contractor’s knowledge transfer efforts shall support the integration, testing, and packaging of contractor developed DIB capabilities and its use by stakeholders and DIB users.

3.6.4 The contractor’s technical knowledge transition efforts shall support a

Government open source environment.

3.7 Research: The contractor shall, if directed by the Government, conduct research on new feature requests or architectural changes that require long lead time.

3.8 Software development: At a minimum, the contractor shall develop each capability to include consideration of the following DIB architecture concepts and address each concept during requirement refinement:

3.4.1 Information Assurance/Cybersecurity – to support a secure, software development life-cycle and maintain the DIB ATO.

3.4.2 End User Support – to provide Analyst User Interface reference implementation, provide Administrative Support and System Administrator User

Interface and necessary tools

3.4.3 Federation Architecture Tools and Services – to support exercise and operational interoperation with other capabilities and dependencies

3.4.4 Web Service Security - Define the impact the capability has on the security architecture.

3.4.5 Documentation - Insure each capability is sufficiently documented to support

DCGS PoR integration, test, exercise and operational activities

3.4.6 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)

3.8.7 Sustainability – Consideration should be given to best development practices that reduces the amount of or prevents creation of additional technical debt.

3.9 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.

3.9.1 Software Code Drops: The contractor shall support nightly source code drops for testing in the DMO Continuous Integration Environment

3.10 Software documentation: The contractor shall deliver all developed software, software capabilities, and respective product documentation IAW DIB documentation

FA8730-17-R-0024, Attachment 1, Page 11 requirements which provides a detail level consistent with existing DIB documentation for incorporation into the documentation set maintained by the test and integration members of the product team, including but not limited to:

3.10.1 Software (source code including all associated files such as properties files and scripts, executables, and Open Source Gateway initiative (OSGi) bundles)

3.10.2 Software Development Kit

3.10.3 Source Code Build Guide, and build and unit test tools, if necessary

3.10.4 Installation Guides that result in the installation of a DIB with a

Government-specified set of capabilities

3.10.5 Administration/Configuration Guide

3.10.6 Security Hardening Guide, if necessary

3.10.7 Software Version Description Document

3.10.8 Release Notes

3.10.9 Test Scripts

3.10.10Test Results

3.10.11Analysis Reports (i.e., Performance, technology assessments)

3.10.12Programmer’s Guide

3.10.13Integration Guide

3.10.14Database Design Document (DBDD)

3.10.15Feature guides that describe installation, administration, configuration, and integration of those features not installed by using the Installation Guides described in 3.10.4

3.10.16Security Features Installation Guide

3.10.17Security Features Configuration Guide (may be combined with the installation guide)

3.11 Information Assurance: The contractor shall support the Government in information assurance certification processes and testing as directed by the DMO.

3.12 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

DIB, DIB training, or system integration support to Government services and agencies and their integration contractors.

4.0 Program Management: The contractor shall manage DIB software development activities

IAW the agreed to plan established during the Sprint planning process. DIB capabilities or applications will build upon the Distributed Data Framework (DDF) and Alliance software, or as otherwise directed by the DMO. Built on an OSGi framework, the DDF allows independent modular features to be developed and deployed. A Kickoff/Release Planning

Meeting will be held soon after the contract award and repeated as needed by the government. These meetings will establish the development objectives for each sprint and update the capability release schedule. Sprint planning meetings will be held at the beginning of every sprint following completion of the previous sprint review. This modular strategy puts enhanced capabilities into the warfighter’s hands without delays and will result

FA8730-17-R-0024, Attachment 1, Page 12 in a DIB consisting separately released DIB components. This management includes the activities of the Product Owner Team, including all DCGS community interaction and support. The contractor shall develop and manage schedules consistent with the Agile processes, estimating the number of story points or other agile metrics, to identify the effort completed by sprint and capability deliveries. This will be accomplished and provided to the

Government for review, discussion and approval IAW the TRN process defined in TRN attachment of the contract. The contractor shall estimate and project costs to support Sprint planning and completion assessment. The contractor shall provide recommendations that reduce timelines or minimize costs of DIB development and community support. The resulting effort will be defined in the TRN. The key activities to accomplish DIB program management are specified below.

4.1 Provide overall program management of contractor’s DIB software (to include documentation) development efforts, community support, and the conduct of the development team, including supporting any government directed partitioning and release plans that are integrated with Government test activities.

4.2 Provide management of contractor’s effort to implement support planning, collaboration, and integration efforts with the DMO, DTL, and other DIB development contractors as part of an integrated product team using an Agile software development methodology, including support of the Product Owner Team wherein the various development, integration, and test teams supporting DIB activities coordinate their on-going design, development, integration, and test activities.

4.3 Provide incremental capability delivery including software, documentation, test scripts, and test reports. Support an integrated capability acceptance test performed to verify all Government directed capabilities with the corresponding version of the

DDF and Alliance.

4.4 A Task Requirement Notification (TRN) will be used to establish a predetermined period (typically 12 months).

4.5 Utilize a management process that can respond to changes in requirements (technical and/or schedule), requirements prioritization, and product implementation. This includes:

4.5.1 Aligning development activities with the Government validated Backlog and any revisions to the Government validated Backlog.

4.5.2 Providing recommended Backlog inputs on prioritization and refinement.

4.5.3 Responding to community support requirements minimizing DIB development efforts in support of DIB integration, test and fielding efforts.

4.6 Use Government-designated/provided tools and repositories that may include, but are not limited to (see section 7.1):

4.6.1 Utilization of a Government designated defect/bug tracking and user story tracking tool

FA8730-17-R-0024, Attachment 1, Page 13

4.6.2 Utilization of a Government designated software source and version control tool

4.6.3 Utilization of a Government designated collaboration, documentation, knowledge sharing tool

4.7 Conduct configuration management consistent with the MET Configuration

Management Plan.

4.8 Develop and maintain a software development schedule that depicts planned use case software development and that describes anticipated and planned sprints, DIB capability incremental (i.e. sprint, epic, and full use case) deliveries. The schedule shall be created using Agile software development estimating practices. This schedule shall be developed for each period of performance awarded as part of this contract and include a kickoff meeting. Schedule status shall be presented and reviewed at DMO Program Management reviews.

4.9 Conduct management weekly teleconference tag-ups addressing current activities and current/potential issues. Conduct twice a year DMO Program Management Reviews that address software development, community support, and test activities, program schedule, Agile software development trends (i.e. velocity, use case completion, etc.), risks, costs, and issues.

4.10 Maintain appropriate security clearances for contractor personnel to access the

DCGS-I Test-bed, DTL, or other Government classified data facilities, sites, and networks as directed by the DMO.

5.0 Location of Contract Performance

5.1 The contractor will conduct management, development, documentation, and test activities at the contractor’s facility.

5.2 Test activities may occur at the contractor’s facility, Hanscom AFB, or other

CONUS/OCONUS Government and/or contractor facilities as directed by the government.

5.3 The contractor shall provide support to the DMO at other contractor and Government

CONUS/OCONUS locations to be determined by the Government for the duration of the contract. Locations may include, but are not limited to: China Lake NAS, CA;

Hanscom AFB, MA; and the Washington D.C. metro area.

6.0 Additional Contract Requirements

6.1 Export Controlled Technical Data

6.1.1 All contractor locations that require export controlled technical data will be registered with the Joint Certification Office (JCO)

(https://www.dlis.dla.mil/jcp/). Registration will include an employee at the location where the work is to be performed as the registered data custodian.

Examples of technical data that are export controlled needed in this contract include but are not limited to DIB software and technical data.

FA8730-17-R-0024, Attachment 1, Page 14

6.1.2 The contractor shall provide proof of registration at proposal submission and/or prior to attendance at an event where export controlled technical data will be shared (e.g. Industry Days, Working Groups). Proof of registration can be provided through completion of the DIB Access Procedures.

6.2 Non-Disclosure Agreement

6.2.1 The contractor shall be subject to DFARS clause 252.227-7025, in its entirety.

6.3 A DD Form 254 will be issued in support of this contract.

6.4 Data rights and markings shall be IAW with the applicable clauses on the basic contract and clauses listed herein. This contract will not deviate from such clauses.

7.0 Government Furnished Information

7.1 The Government will deliver the following GFI through Government portals.

GFI Due

DIB v1.3 Contract award (upon contractor completion of DIB access procedures)

DIB v2.0 Contract award (upon contractor completion of DIB access procedures)

DIB v3.0 Contract award (upon contractor completion of DIB access procedures)

DIB v4.0.X Contract award (upon contractor completion of DIB access procedures)

DIB v4.1.X Contract award (upon contractor completion of DIB access procedures)

DIB v4.2.X Contract award (upon contractor completion of DIB access procedures)

DIB v4.3.X Contract award (upon contractor completion of DIB access procedures)

DIB v4.4.X Contract award (upon contractor completion of DIB access procedures)

DIB v4.5.X Contract award (upon contractor completion of DIB access procedures)

DIB v4.6.X (if applicable) Contract award (upon contractor completion of DIB access procedures)

Software development Backlog Contract award, and with revisions when available

DIB Capability Use Cases Contract award, and with revisions when available

DI2E Software Development and

Collaboration Tools

Contract award (upon contractor completion of DIB access procedures)

FA8730-17-R-0024, Attachment 1, Page 15

8.0 Contract Data Requirement List

8.1 The contractor shall deliver data IAW the Contract Data Requirements Lists (CDRLs)

DCGS Integration Backbone (DIB) Development, located in Exhibit A.