The Department of Defense (DoD) and Department of Homeland Security (DHS) need “justifiable evidence and high confidence that acquired systems perform as expected, when expected, are safe, and are secure” [1]. However, the DoD/DHS Software Assurance (SwA) Acquisition Working Group states that “acquisition officials continue to accept software riddled with errors and other security vulnerabilities” [2]. From these statements, it is clear that the U.S. government’s acquisition process for software must change!
This article shows how the U.S government’s software acquisition process can be changed – today – to deliver high quality software satisfying the needs of these government communities.
A critical component of the acquisition process is to ensure that any supplier’s bid for new or maintenance work must conclusively demonstrate, in its ‘pre-award’ proposal, its current ability to perform Inspections compliant with the 2008 IEEE Inspection Standard 1028™-2008 (Section 6) [3] and in accordance with the Federal Acquisition Regulation (FAR) Part 46.2 for Quality Assurance [4].
The current delivered state of software-driven systems must end! The US Taxpayer deserves quality products delivered on-time to meet our nation’s critical needs.
Figure 1: Potential Software Supply Chain Paths [2]
As shown in Figure 1, the supply chains in today’s software acquisition world consist of a wide variety of suppliers spread across the world. Each of these suppliers may have their own standards for development and quality assurance. “Therefore, the responsibility for SwA [software assurance] must be shared not only by software suppliers in the supply chain but also by the acquirer in the supply chain who purchase the software” [2]. Additionally, the SwA Acquisition Working Group identified five different acquisition processes – each with their own planning, contracting, monitoring & acceptance [criteria], and follow-on [maintenance] approaches. It is no wonder there are operational problems with delivered software!
The software assurance need begs for an auditable outcome-based acquisition process that, in addition to ensuring high quality, can provide warning of quality and security problems early in the development process – for example when defining contract terms, interface specifications between suppliers, and product requirements.
Since 1991, acquisition professionals have been discussing the concepts, training, roles, and responsibilities that support Performance Based Acquisition (PBA) [5]. Missing is the unity of a coherent acquisition process and availability of relevant standards and tools that tie together all the elements necessary to implement PBA. Outcome-Based Acquisition (OBA) is a specific implementation of PBA and all the elements needed to implement OBA are available today!