Search within Atkins website
More specific search? Try these
Angles publication platform
Create PDF document
Add web pages to PDF bundle for download
How to use PDF generator
Pages in bundle
View / Manage bundle
15 Jun 2016
Insert banner title text here
Andy German looks at why failing to introduce engineering specialists into the acquisition process can result in delayed roll-out, spiraling costs and software that is not ‘fit for purpose’.
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:
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.
Local contacts in our regional offices can be found in the Locations section.
Local language websites exist for Denmark, Sweden, Norway and Asia Pacific. To see a full list of our websites, go to the Our websites page.
In the Sector and Service part of the website, relevant regional contacts have been identified.
Faithful+Gould is a member of the Atkins group of companies.
Register for our news alerts and receive the latest news and events
Connect with us
Most computers will open PDF documents automatically, but you may need to download Adobe Reader.