Software Engineering is a relatively young and continually changing discipline. It was born out of the conferences organised by NATO in 1968 and 1969 which were held to discuss the emerging 'software crisis'. Throughout the 1970s and 1980s computers rapidly decreased in physical size and cost while simultaneously increasing in capability and processing power, resulting in their adoption in all fields of engineering. During the 1990s and 2000s organisations acquiring systems often did not know if the system contained software and, in most cases, relied on the supply chain to manage software elements of system design and development.
Software Engineering has produced specific methods and life-cycles that support ever faster software design, development and verification. The software industry has, and is increasingly transitioning away from, prescriptive sequential project lifecycles (e.g. waterfall and V) to evolving agile approaches (e.g. Spiral, SCRUM and prototyping hybrids) that are adaptive and collaborative. In addition, over the past decade hardware has reduced its restrictions on software and there has been a significant drive and progress towards standardisation of interconnections between systems.
System acquirers today normally follow the sequential project lifecycles, relying on the supply chain to specify, design, develop and verify the software. This often results in systems that do not meet the user’s intent, have requirements that are inflexible, are delivered late, are over budget, or are difficult to maintain and update in-service. Suppliers are not currently incentivised to architect systems that allow rapid and simple software change ‘through life’.
Typically, acquiring organisations do not engage software engineers/acquisition specialists as part of the acquisition process. This can result in a number of risks being introduced, including:
- Requirements that are only specified at the highest system level, with software quality attributes and derived software child requirements, missed. Due to a lack of software and architecture understanding, metrics which have little value (e.g. Software Lines of Code–how large the programme is) are specified in the contract and viable exit strategies are not included (e.g. crash early and don’t continue crippled programs ).
- Selecting the supplier on promises and price remains a problem, particularly when acquiring organisations do not follow the established industry agile practice of not investing more than you are willing to throw away. This can also result in contract milestones and reviews (e.g. Preliminary Design Reviews, Critical Design Reviews and Test Readiness Reviews) that are either too early or late in the design and development to properly manage software design and development risks.
- Failing to introduce specialists that can advise on software architectures, security, safety, etc. during the design and development phase can introduce unnecessary issues. If you are forced to rely on test and evaluation at the end of the contract, rather than throughout the life cycle, key user requirements may not be addressed. Corrective action costs also increase considerably as the programme progresses, which is only exacerbated as programme budgets dry up.
- Acceptance of software systems that fall short of the user’s original intent without having factored this into the overall programme costs and program.
- Typically in-service software systems architectures do not support agile capability upgrades.
In order to address these risks, as well as the drive towards greater software engineering agility, software acquisition needs to be supported and influenced by a more responsive acquisition and contracting framework.
Suppliers want to have an intelligent conversation about software systems with acquirers. They want to agree contracts that support agile concepts and make best use of enterprise/system-of-systems capability. Clearly organisations cannot continue with an acquisition model based on “only specifying the system based on their current understanding of need” as this will always be subject to inadequacies and errors, as well as relying on “the supplier solving the ambiguity in relation to the software element of the system having the users’ best interests at heart”.
There is no quick solution to this problem. It takes time to develop an “in-house” software acquisition capability that follows good practice such as IEEE 1062 (2015) – Recommended Practice for Software Acquisition. In the interim, organisations will need to “buy in” specialist software acquisition support.