Systems Engineering encompasses the ‘big picture’ approach towards developing new products and technologies. It borrows fundamentals from various science, engineering and management perspectives in order to create successful products and technologies that can apply theory to practice (praxis) (Ramsey & Miller, 2012) in order to attain successful satisfaction of all stakeholders. In combination with Agile development, Systems Engineering has the potential to manage complexities inherent in large-scale Software Engineering initiatives and significantly increase the quality of the end-product.
In order to apply, analyse and connect the concepts studied in this week’s topics, we will take a look at some famously infamous failures of software systems, and investigate what truly went on behind the scenes.
Scapegoating softwares: an easy way out?
When large projects fail, and they do so quite often, someone or something needs to take the blame; something needs to be chastised to bring ease to those higher up the food chains, to those who may be stakeholders of the system. Softwares, often become easy targets for such scrutinisation due to a whole barrage of issues. Let us consider some such examples…
The Denver Airport Baggage Handling System
(The Denver Airport Baggage Handling System, image courtesy: http://calleam.com/WTPF/?page_id=2086)
In order to illustrate the significance of the critical importance of Systems Engineering in the success or failure of large-scale and ultra large-scale problem situations, it would perhaps be beneficial to consider a real-world example such as the Denver Airport Baggage Handling System (DABHS) (“Malfunctioning baggage system delays Denver airport,” 1994) — as studied as part of our week-1 readings. DABHS was intended to be an automated system that would move baggage from aircrafts to terminals. However, due to unforeseen circumstances, the completion of the project was significantly delayed and there were considerable financial setbacks as a result. The root cause of all this apparent evil was deemed to be software failures. This was, nevertheless, far from accurate.
The DABHS, was an immensely complex systems, and comprised of thousands of constituents, all of which were expected to work in flawless synchrony, and produce strategic goal-oriented results. Software was an integral component of this immensely complex system, but was far from solely responsible for the project delays. Several other structural, dynamic, and socio-political complexities (Company, 1996) emerged during the course of the project development, all of which, in equal part, were responsible for this high-profile systems failure.
For instance, despite of a consultancy report deeming the use of a one-bag-per-cart system strongly ill advised instead of a tested-safe multi-bag cart system, the airport authorities decided to acquire the former anyway. Furthermore, halfway through the project development, the airport and city authorities mandated a major revision of the system underway construction. Not to mention the prolonged infighting between different contractors working on-site that continued for almost a whole year during the project development lifecycle. Moreover, there were major incidents of hardware malfunctions — which had nothing to do with the software.
The software was not doing what it was expected to do, but the real issue in this case was that between scope creep and other unforeseen issues associated with and around the DABHS, the expectation from the software kept changing and getting affected by issues that were not in control of the software developers. A close study of the case clearly reveals that the failure of project being blamed upon poor Software, and poor software development was a misrepresentation of truth (Montealegre, R., & M., 1998). There was, au contraire, a systemic failure. The system, right off the bat, seemed to have been set up for failure.
Softwares are expected to change, morph, evolve and be malleable. It is expected of softwares to be developed in an unstably defined environment. However, there is an extent to which risks associated with the project can be managed, and associated with the software itself. Typically, it is common for software engineering projects to be over budget because of such uncontrollable factors. And it is at points such as this when it must be asked,”Is the expectation for the project to be finished in budget, and time, or is it for the project to be capable?”.
The Joint Strike Fighter
(F-35C, Image courtesy: http://www.lockheedmartin.com/us/news/features/2014/5-unique-f35c-carrier-variant-features.html)
The Joint Strike Fighter program (Bevilaqua, 2009; Haley & John, n.d.; Sweetman, 2004) is a development and acquisition project that is intended to replace a number of current ground attack, fighter and strike aircrafts for the U.S., U.K., Turkey, Italy, Canada, Australia, Netherlands and several other allied nations. This is a multi-billion dollar development project, and has a multi-trillion dollar estimate for its operational life-cycle costs. And this project has been plagued with delays, overspending and an array of failure. And the alleged culprit is, you guessed it, bad software. However, a close examination of the case reveals a systemic problem on a scale larger than solely the software development.
Firstly, the project begun on a bad note. There were four major competitors for the bid to the U.S. Department of Defense: McDonnell Douglas, Northrop Grumman, Lockheed Martin, and Boeing. Contracts were subsequently awarded to Lockheed Martin and Boeing to develop operational prototypes — they had better designs. The aim of these contracts was to prevent these immensely large corporations from bankrupting themselves in competition to develop a winning prototype (Ahern, 2009).
The full story is too long to describe — both Lockheed Martin and Boeing had good designs, each had their own flaws, and points of excellence. The gist of it is that despite of Boeing having an overall better prototype, Lockheed Martin was awarded the contract for a full-scale development. The reason? It was more political than anything else (“Dimensions of Peace and Security,” n.d.). Boeing had invested so much money into developing the prototype, and incurred such a debt, that had it not won the contract, it would have gone bankrupt. This would mean that the U.S. would have a company — Boeing — with inherent monopoly over the aircraft manufacturing industry (they did pretty well in the commercial market as well). So, it was decided that Lockheed Martin should not be allowed to go under, and ruin the spirit of fair competition in the market.
Suffice to say, this did not turn out well in the long run. There were far too many modification in the scope of the project made along the way, and the Congress (and the U.S. DoD) were too meddlesome during the entire course of project development. New features were constantly requested to be added to what was already a far too complex project (Charette, 2014). This was also followed by a series of budget cuts, reschedules, and a number of other factors on which the development team had no control. Not to mention, that while the JSF was being developed based upon the presumption of incorporating certain radar, ballistics, aerial refuelling, and SatNav technologies, these technologies were changed during the course of the project development (Axe, 2011), which meant that tremendous amounts of rework had to be performed on the initial project scope.
A decade of wars and conflicts, economic disasters, changing politicians, and emergence of new geopolitical powers led to the JSF being subjected to a wide array of issues. The JSF was supposed to be a technological advancement, but given the high-profile of the project, turned out to be an easy target for much controversy. And because the poor old software development process never can seem to keep up with this seeming pandamonium of changing requirements, expectations, and standards, it becomes an easy target to blame the failures upon when in fact the issue is a larger systemic failure. The project was, so to speak, set up to fail from the beginning.
The truth is rarely pure and never simple
Systems engineering intends to help the exploration of the scope of software engineering projects so as to help develop an evolution towards a broader scope with a holistic perspective of the project. It works with several disciplines (mechanical, electrical, financial, political, computer systems etc) to help manage complexity and create quality end-products. Software is a part of a larger system of systems. As software developers, we must ensure that the products we create fit into this larger picture, and enable the system to do what it is supposed to do. Enough caution cannot be advertised in regards to elements fatal to the project such as scope creep, and sometimes just plain bad luck. But as professional software engineers, it is expected of us to minimize such issues in the manner best possible.
Charette, R. N. (2014, March 27). Software Testing Problems Continue to Plague F-35 Joint Strike Fighter Program. Retrieved March 31, 2016, from http://spectrum.ieee.org/riskfactor/aerospace/aviation/software-testing-problems-continue-to-plague-f35-joint-strike-fighter-program
Montealegre, R., R., M., & M., K. (1998). Denver International Airport’s Automated Baggage Handling System:A Case Study of De-escalation of Commitment. Academy of Management Proceedings, 1998(1), D1–D9.