On December 12, 2017, President Trump signed the $700 billion 2018 National Defense Authorization Act (“NDAA”) into law. Following negotiations between the House and Senate Armed Services Committees, the NDAA includes new provisions relating to software acquisition within Title VIII — Acquisition Policy, Acquisition Management, and Related Matters, Subtitle H, and the following five sections:

    SEC. 871. Noncommercial Computer Software Acquisition Considerations. 

    SEC. 872. Defense Innovation Board Analysis of Software Acquisition Regulations. 

    SEC. 873. Pilot Program to Use Agile or Iterative Development Methods to Tailor Major 
    Software-Intensive Warfighting Systems and Defense Business Systems. 

    SEC. 874. Software Development Pilot Program Using Agile Best Practices. 

    SEC. 875. Pilot Program for Open Source Software.

Subtitle H has three main themes. First, there is a push to import certain requirements on the delivery of software to the government, with a focus on ensuring that the government will have a robust capability to maintain such software after delivery. Second, there is a rethinking of the traditional processes by which U.S. Department of Defense (“DoD”) software programs have been developed, and a likely redirection under which developers will adopt “agile” development processes reflecting commercial trends. Lastly, the overall software acquisition program will be examined to streamline its processes and to tie these processes more closely to agile development paradigms.

Software Delivery Requirements

SEC 871 requires that negotiations for any acquisition of developed “Noncommercial Computer Software” must consider delivery of a complete package to enable the government to build, test, and deploy such software. The term Noncommercial Computer Software refers to software that is licensed to or developed for the government but that is not also licensed to the public. Given that the DoD has been in the business of acquiring and maintaining Noncommercial Computer Software for many decades, one would think that such a requirement would already be firmly in place. Thus, the negative implication of the new requirement is that some past deliveries must have been incomplete with regard to the government’s ability to build, test, and deploy the software. This seems to contradict the fact that virtually all DoD contracts require software to be delivered and licensed to the government with legal rights designed to permit government maintenance under Defense Federal Acquisition Regulation Supplement (“DFARS”) 252.227-7014. In short, DFARS 252.227-7014 requires that software developed for the DoD must be licensed with “Unlimited Rights,” “Government Purpose Rights,” or “Restricted Rights” — all of which require the government to have access to and the ability to modify the software source code (although title and ownership of the software always remain with the licensor).

In reviewing SEC 871, however, it seems clear that merely guaranteeing government rights to receive and modify source code is insufficient to meet practical needs. Indeed, in looking at an earlier version of the NDAA, the approach was to revise 10 U.S.C. §2320(a)(2), Rights in Technical Data, to mandate completeness of software deliveries. The final law is somewhat softer than the earlier version because it only requires negotiation of the complete package deliveries. From a technical standpoint, simply having access to the source code does not ensure that one can produce a maintainable, testable, and usable software product. Therefore, SEC 871 reflects the need for deliveries to include all “related material necessary” to i) compile and build the source code in executable form, ii) conduct required testing, and iii) deploy a product that actually works on the target hardware and operating system. Such a requirement may well increase contractor proposal costs to account for the inclusion of build scripts, libraries, test programs and platforms, and installation/deployment tools.

Another impact on software deliveries is reflected in SEC 875, which requires that DoD initiate an Open Source Software (“OSS”) pilot program in accordance with the U.S. Office of Management and Budget (“OMB”) Memorandum for the Heads of Departments and Agencies, M-16-21 (the “OMB Memorandum”), August 8, 2016. The high-level purposes of the OMB Memorandum are to promote reuse of federal contractor and employee custom-developed code, and to improve the quality of such software through public participation. To these ends, the OMB Memorandum has two major requirements: (1) all custom-developed code must be broadly available for reuse across the federal government subject to limited exceptions (e.g., for national security and defense) and (2) under a three-year pilot program, federal agencies are required to release at least 20 percent of their custom-developed code to the public as OSS. The intent here is to enable continual quality improvements to the code as a result of broader public community efforts. Thus, SEC 875 may both impact a licensor’s delivery of DoD software as well as expand the rights that are granted to the government. We have previously discussed the IP issues of the OMB Memorandum here. That article concludes that the requirement to release custom-developed code as OSS may effectively reduce the creator’s ownership rights, and have economic impacts both on the value of ownership and on pricing when bidding on government contracts. Thus, DoD software developers will need to factor in this loss of value in created software in their bidding and proposal strategies when OSS deliveries are mandated.

Agile or Iterative Development Methods

Two NDAA sections are focused on evaluating agile or iterative software development methods. These sections are a response to late deliveries and budget overruns that have plagued recent government software acquisitions. The U.S. Government Accountability Office (“GAO”) reports that “Congress and DOD have long sought to improve how major weapon systems are acquired, yet many DOD programs fall short of cost, schedule, and performance expectations, meaning DOD pays more than anticipated, can buy less than expected, and, in some cases, delivers less capability to the warfighter.”[1] Agile or iterative software development methodologies attempt to ameliorate these problems by recognizing that the government’s failure to adequately specify software requirements at the beginning of an acquisition is often the source of downstream issues. In reality, at the inception of a software-based project, the detailed software requirements may be unknown or unknowable, and even if the requirements are known, they usually experience significant changes as the development progresses. To address these requirements issues, agile or iterative development promotes enhanced collaboration between program managers, requirements analysts, testers, the end-user community, and, of course, the software developers. This approach develops software iteratively in short cycles (called “sprints,” “spirals,” or “spins”), and involves frequent testing, user feedback, rapid deliveries, and adaptation to changing requirements. While traditional software development was approached via rigorous preplanning to fully specify requirements before building an entire computer program application, agile development breaks the project into discrete cycles and iterates over multiple sprints. This allows program managers to incorporate changed or new requirements for each sprint in accordance with user needs, thus promoting modular IT contracting. The NDAA recognizes the need to be able to anticipate and adapt to evolving requirements.

The NDAA does not mandate the universal use of agile development projects, but rather establishes pilot programs under which the effectiveness of the agile processes may be evaluated. SEC 873 directs the Secretary of Defense to establish a pilot program to simplify software development methods for candidate existing major software-intensive warfighting and defense business systems within 30 days after enactment of the NDAA. The pilot program will select one warfighting system for each armed force, one defense-wide warfighting system, and at least two defense business systems. The candidate systems will be selected from those that are considered to be high risk, that have experienced cost growth and schedule delay, and that did not deliver any operational capability in the prior calendar year. Specifically, the selected systems will be realigned and broken down into smaller increments using agile or iterative development methods. The SEC 873 pilot program will sunset in 2023, and the selected systems will be evaluated with respect to reducing cost or schedule growth.

Similarly, SEC 874 directs the Secretary of Defense to identify four to eight software projects to be developed in a pilot program using agile acquisition methods within 30 days after enactment of the NDAA. Interestingly, this pilot program expressly directs that the projects will eliminate certain traditional contract documentation deliverables to include the integrated master plan, integrated master schedule, technical requirements documents, and use of the software development life cycle. SEC 874 substitutes alternate agile planning concepts, including a product vision, product road map, end user feedback and testing, automated testing, compliance with commercial standards, and use of web browsers and mobile devices. SEC 874 also mandates contract awards within three months of requirements identification, delivery of functional prototypes within three months of award, and iterative development cycles of four weeks or less. Finally, SEC 874 requires the use of agile development metrics to track the effectiveness of the quality and timeliness of the pilot projects. In comparison, SEC 874 goes much deeper into adopting agile techniques for new systems than SEC 873 does for pre-existing systems.

Software Acquisition Streamlining

Congress and the DoD are certainly concerned with the costs and urgency of software development. While the NDAA does not yet mandate particular changes in the acquisition process, SEC 872 points toward acquisitions that are “streamlined” in a manner that may suggest the agile development philosophy. While software could be developed using agile processes independently of the acquisition process, SEC 872 seems to contemplate integrating acquisition and development under an agile regime, pending the recommendations of a study on streamlining software development and acquisition regulations. Clearly, the government has determined that traditional methods are not working well, and that streamlining under agile methods may be the solution. Thus, under Section 872, the Defense Innovation Board is tasked with undertaking a study on streamlining by reviewing existing acquisition regulations, evaluating ongoing DoD programs (including best and worst practices), and producing recommendations for legislation (including the potential repeal of regulations, adopting private sector best practices, and promoting rapid adoption of new technologies).

Observations and Practical Tips

• Software acquisition bidders must be aware of the new NDAA 2018 requirement to deliver all necessary build scripts, libraries, test programs, platforms, and installation/deployment tools, and must price in the costs of delivering all components of complete packages.

• For OSS acquisitions, developers should understand that while they may “own” the software they develop for the government, creators of custom-developed code may need to increase prices to compensate for the loss of actual ownership rights, and may need to take steps to protect proprietary components of such work.

• The NDAA promotes agile development to allow projects to react to shifting warfighter needs. The use of agile development, however, should not supplant careful, up-front requirements analysis. If requirements are poorly defined, in flux, or unknown, then the delivery of rapid increments can waste resources.

• Schedules for agile development should also 1) account for the time needed to perform adequate technical research and architectural design; and 2) plan for scenarios where multiple interoperating systems are developed simultaneously, and where rapid releases for different projects must be carefully synchronized and coordinated.

In lieu of detailed proposal preparation, agile RFPs may request bidders to invest up-front resources to develop initial sprint demonstration prototypes as a basis for award. This will require increased expenditure of internal funds on such proposed prototypes, negatively impacting the risk/reward ratio of the bidding process.

[1] U.S. Government Accountability Office, 2017 High Risk Report, (2017), https://www.gao.gov/highrisk/dod_weapon_systems/why_did_study.