There are a number of pitfalls to be avoided when contracting for software-intensive systems. For example, the failure of Government Furnished Software (GFS) could render the Government responsible for subsequent failures on the part of the contractor. Another example is applying an improper type of contract for software development. Yet another is the establishment of contract incentives that do not emphasize desired aspects of contractor performance, such as emphasizing speed of delivery at the expense of software quality. These and other contracting issues related to software are addressed here to ensure contracts are structured to avoid the undue risk associated with Government-furnished software and to provide incentives for the software developer to achieve performance, cost, schedule, and life-cycle support goals. 
Software Contracting Related Topics include: 
- Government Furnishes Software (GFS): Acquisition organizations must exercise extreme caution when providing software as GFE/GFP/GFI to the development contractor. This includes software tools to support the development process. The preferred approach is to specify the requirements in performance terms, and then require the development contractor to select his own tools based upon his analysis of those tools and software available in the marketplace. This approach places the responsibility on the development contractor to assess the maturity and product quality of candidate software packages, and to arrange for life cycle support, as required, to satisfy contract requirements.
- Software Co-Developed by the Government: In this case, the Government entity is treated as a subcontractor during the source selection, and personnel working for the Government entity are prohibited from participating in the source selection except through contractor discussions. Strengths, weaknesses, and risks associated with the Government entity‘s software development capabilities must be assessed just as for any other proposed software developer.
- Steps for Dealing with GFS: See FAR 52.245-1, Government Property Clause and USAF Weapons System Software Guidebook – Appendix E.2.2
- Intellectual Property (IP): Deals with the rights associated with the products produced by contractors, including the various software products. The establishment of IP terms and conditions is a critical aspect of any software-intensive systems acquisition activity.
- Assessment of Planned Work – Data Rights Requirements Analysis (DRPA): It is the responsibility of the contracting officer to put the proper data rights clauses into the contract, but it is the responsibility of the program office team to provide the contracting officer with a complete assessment of the planned work effort. This assessment, called Data Rights Requirements Analysis (DRRA), should include a determination of the contemplated present uses of the software or other deliverables as well as an assessment of any future uses of the software products or tools used in their production.
- DRRA Principles and Considerations: The results of this analysis should guide the program office in determining the intellectual property and intellectual property rights that it requires the contractor to deliver.
- Commercial-Off-The-Shelf (COTS) and Open Source Software (OSS): Currently, the DFARS require the identification of noncommercial software to which the Government has less than unlimited rights. It is also necessary for acquisitions to require identification of any commercial software (such as Commercial off-the-Shelf (COTS), open source, Freeware) that are or have the potential to be a part of the software items to be delivered in fulfillment of contract requirements.
- Contract Types for Software Development: Contract type is an important consideration in the acquisition of software-intensive systems, and is normally determined during the formation of the acquisition strategy. The two major contract types typically used for weapon system acquisition are cost reimbursement and fixed price.
- Fixed Price: Contracts are best applied in situations where development risk is small and requirements are stable and well understood. Limited development risk allows the contractor to cover the risk at a reasonable price. Requirements should be well understood so the Government does not have to constantly modify the contract to meet the needs of the user. Weapon system software development does not typically fit this scenario.
- Cost Reimbursement: Contacts are much more common for software-intensive weapon system development.
- Software Contract Line Items (CLINs): Separate CLINs can be established for software if it is a separate deliverable under the contract. Identifying software as a contract line item in the model contract included in the RFP ensures that software has appropriate visibility and accountability, and aids in the reporting of software cost.
- Critical Processes: The Government ensures its rights to expect the contractor to perform to his critical processes by placing essential development processes on contract. The Integrated Master Plan (IMP) is the vehicle to accomplish this, together with the contractor’s Software Development Plan (SDP), which contains descriptions of these processes.
- Coordination with Defense Contract Management Agency (DCMA): DCMA can play a vital role in monitoring the execution of the development processes through Memorandum of Agreements (MOA) or similar instruments. The program office and DCMA
AcqLinks and References:
-  USAF Weapon Systems Software Management Guidebook – Appendix E
- Mil-STD-498 “Software Development and Documentation” – 5 Dec 1994
- MIL-STD-498 “Application and Reference Guidebook” – 3 Jan 1996
- Software Development Plan Information Outline
- Template: Software Development Plan – SPAWAR
- Website: MIL-STD-498 Software Documentation