<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE dita
  PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
<dita xmlns:ditaarch="http://dita.oasis-open.org/architecture/2005/"
      domains="(topic task)                            (topic concept)                            (topic concept glossentry)                            (topic concept glossgroup)                            (topic reference)                            (topic troubleshooting++task) (topic task)                            (topic abbrev-d)                            a(props deliveryTarget)                            (topic equation-d)                            (topic hazard-d)                            (topic hi-d)                            (topic indexing-d)                            (topic markup-d)                            (topic mathml-d)                            (topic pr-d)                            (topic relmgmt-d)                            (topic sw-d)                            (topic svg-d)                            (topic ui-d)                            (topic ut-d)                            (topic markup-d xml-d)                            (topic task strictTaskbody-c)   "
      ditaarch:DITAArchVersion="1.3">
   <concept id="DFARS_PGI_227.7203-2"
            ditaarch:DITAArchVersion="1.3"
            class="- topic/topic concept/concept ">
      <title class="- topic/title "> 
         <ph props="autonumber" class="- topic/ph ">PGI 227.7203-2</ph> Acquisition of other than commercial computer software and computer software documentation and associated rights.</title>
      <conbody>
         <p outputclass="List1">(b)(1) To the maximum extent practicable, an assessment of life-cycle needs should consider periodic delivery of computer software and computer software documentation including all executable code, source code, associated scripts, build procedures, automation scripts, tools, databases, libraries, test results, data sets, firmware, training materials, and any other elements necessary to integrate, test and evaluate, debug, deploy, and operate the software application in all relevant environments (e.g., development, staging, production). See DoDI 5010.44, Intellectual Property (IP) Acquisition and Licensing, sections 4.1 and 4.2, when formulating business advice and contract implementation strategies regarding the program manager’s tailoring of software requirements to the needs of the Government.</p>
         <p outputclass="List2"> (2)(i) <i>Procurement planning</i>.</p>
         <p outputclass="List4"> (A) Based on the results of the assessment of life-cycle needs, and to the maximum extent practicable, the source code should be accompanied by all software capability descriptions (e.g., features, story points, use cases) and all as-built architecture and design products, traceability products, interface definitions including interfaces to proprietary software elements, and any other requisite documentation.</p>
         <p outputclass="List4"> (B) The assessment of life-cycle needs should consider delivery timelines to facilitate transition to a different contractor or to the Government. This approach facilitates management of program risk and supports options for flexibility in the transition of software sustainment to another organization.</p>
         <p outputclass="List4"> (C) Contracting officers are responsible for ensuring that, wherever practicable, solicitations and contracts include the requirements for periodic delivery and any delivery timelines for computer software and computer software documentation, based upon the assessment of life-cycle needs.</p>
         <p outputclass="List3"> (ii) <i>Alternatives to delivery of source code and related software design details.</i> 
         </p>
         <p outputclass="List4"> (A)(<i>1</i>)In determining whether the Government should require delivery of computer software source code and related software design details developed exclusively or partially at private expense, data managers and other requirements personnel are responsible for considering whether these alternatives permit the Government to—</p>
         <p outputclass="List7"> (<i>ii</i>) Meet its management, engineering, and logistics needs; and</p>
         <p outputclass="List7"> (<i>iii</i>) Maintain the currency of acquired technical data or software consistent with the assessment of life-cycle needs.</p>
         <p outputclass="List6">(<i>2</i>) To the extent practicable, the Government should also require open interface documentation for any privately developed computer software used in or interoperable with software developed for the Government, to allow for technology insertion on all sides of the interface, as applicable, and to support the use of modular open system approaches.</p>
         <p outputclass="List4"> (B)Access agreements permit the Government to view, print, download, annotate, modify, or make derivatives of technical data or computer software stored within a contractor-controlled repository or facility (e.g., in an online environment or in person). Examples of access arrangements include remote online authorization to access an integrated data environment, product data management system operated by the contractor, or mechanisms authorizing physical entry to a contractor-controlled data repository, or cloud-based or subscription-based software products or services. The negotiated access agreement must stipulate permissions based on the assessment of life-cycle needs, and the access agreement must be made part of the contract.</p>
         <p outputclass="List4"> (C) For each technical data or computer software requirement, the requiring activity must determine whether the Government’s needs can be better satisfied through access or formal delivery of the technical data or software (e.g., physical or electronic transfer of the data into Government custody). The Government should consider access to technical data or software when—</p>
         <p outputclass="List6"> (<i>1</i>) The delivery of technical data or software is not cost-effective or feasible for technical, legal, or contractual reasons; and</p>
         <p outputclass="List6"> (<i>2</i>) Access meets the Government’s needs for such technical data or software throughout the life-cycle of the program.</p>
         <p outputclass="List4">(D) Under a data escrow agreement, the Government and the contractor identify a third-party escrow agent that will keep designated technical data or computer software for safekeeping until a contractually specified condition occurs. If a contractually specified condition occurs, then the Government may obtain delivery of the escrowed technical data or computer software. The contracting officer shall include the data escrow agreement in the contract. The contract shall also include the Government’s license rights in the escrowed technical data or computer software. Use of data escrow agreements is not preferable in all cases but may be useful when formal delivery or access is not feasible or cost-effective during the contract’s period of performance or delivery schedule.</p>
      </conbody>
   </concept>
</dita>
