Environmental Concerns

This week’s lecture was addressed by Dr. Lorrae Van Kerkhoff from the Fenner School of Environment and Society, with the underlying aim of highlighting notions of sustainability in engineering and computer system solutions.

The concept of sustainable development has been around for a while, we are all taught about it in schools, but do we really understand it? The textbook definition would define it as: development that meets the needs of the present, without compromising the ability of future generations to meet their own needs (Pooley et al., 2013). Nevertheless, despite of all the hullabaloo that surrounds everything that out to be green, why does all the data, from all the scientific investigations, exhibit a massive lack in the incorporation of such notions in the way that we do things?

While the concept of sustainable development has far reaching implications in seemingly everything industry, and human activity, we shall use an endogenous approach to investigate it within the ICT domain — for the sake of not getting embroiled in the complexity of the whole picture.

The Short-Sightedness of Current Development Models


The systems in place that we, today, use for development lack the incorporation of one very critical factors: the long-term implications of current activities. The capitalism-driven machine of the ICT domain — for the most part — is motivated with profit-generation and value addition to the industry (Reinhardt, Stavins, & Vietor, 2008); as a consequence, these developmental models become focused on short-term profit-generations with a complete disregard for what would happen 20 years from now, or 50 years from now, or 100 years from now. This does not paint a bright picture for the future of the industry.

In our lecture, the prospect of a safe and just space for humanity was discussed. This encompasses addressing climate change, land-use change, biodiversity loss, freshwater use, and human-influence amongst several other factors. It wa also discussed how the levels of commitment towards actually implementing sustainable development strategies have not met even the simplest of expected benchmarks. And it was proposed, that this inability to bring about substantial change is due to an indifference that has established itself at the core of the way in which we conduct our business.

A desperate need for a paradigm shift

Considering the nature of our conduct, and taking into consideration the fact that most of all of the scientific data from most of all of credible scientific sources states that the dangers of continuing on the current development paths shall inevitably result in the manifestation of grave consequences for the world as we know it, a paradigm shift of immense significance needs to be brought about in most, if not all, processes across the industrial domain.

Big changes do not occur overnight though; it can take years for change of any significance to occur. The right time to act is, therefore, not today, it was yesterday.

How can the Software Industry add value to a sustainable model?

Softwares, being at the core of almost all engineering systems across the entire industrial spectrum, have the potential to become the most significant enabling solution to drive digitization, dematerialization, optimization and integration of cross-platform and cross-institutional solutions for sustainable modes of conduct (United States, 2011).

The hazard mitigation or subsidizing potential of a systems engineering approach to create software systems may be manifested in the following sectors:

  • Energy

Smart Grids


A smart grid (Commission, 2008) is an electrical grid which incorporates several smart measures such as smart meters, smart appliances, renewable energy resources, and energy efficiency resources. At the moment, most of these platforms are hardware dependent, but as the cost of manufacturing of electrical and electrical grid components goes down, and computational power goes up, a more software intensive focus can be applied. This creates room for cross-platform optimization on a scale never before imagined.

Virtual Power Plants

Virtual Power Plants (VPPs) use concepts of distributed generation systems that use cross-platform, high-throughput computations across the constituents of its network to create and supply reliable power supply across the grid (Nezamabadi, Hossein, & Vahid, 2015). VPPs logically connect cogenerative micro combined heat and power (Landsbergen, 2009), photovoltaics (Loria, Dennis, Robert, & Edward, 2004), small-scale wind turbines and hydro-electricity plants etc. This virtual internetwork opens new avenues for power storage in large reserves, and changes the way in which optimization of power supply networks can be perceived

  • Transportation


Given a significant improvement in telecommuting technologies and platforms, a significant decrease in carbon pollution  could be observed due to elimination of the need to travel to the office (Gerard, David, & Lave, 2005). Additionally, it has the potential to have a considerable effect on driving down organizational operational costs, thereby increasing the profits (Sagner, 2011).



Through the use of advanced vehicular systems, a sustainable mobility culture could yield positive effects for climate protection, in addition to improving road safety. Eco-driving, at the moment, is largely dependent on users to make a set of smart decision, but as softwares becomes integral to operating system of vehicles, these decisions could be hard-wired into the vehicles, thus reaching new definitions of success (Barkenbus, 2010).

Logistic-Networks Optimization

Not only does this aid in achieving great value-return on investments, optimization of logistic networks can prove to have dramatic improvements in approaching service-level specifications, achieving mission-critical objectives, improving road-security, and most importantly driving down carbon emissions (Wang, Fan, Xiaofan, & Ning, 2011).

  • Agriculture and Land-Use

Livestock Management

Through the use of a barrage of RFID sensors, data analysis and information generation systems and improvements in wireless communications platforms, livestock management could become progressively automated (M. J. Darr et al., n.d.), and with time (as knowledge gets coupled with experience in decision support systems) significant improvements can be made on the environmental impact of livestock farming (May, Kenneth, & Bill, 1995; Sørensen, 1997).

A New Hope

We have barely touched the full potential of the use of a systems engineering approach towards creating green softwares systems and sustainable development policy initiatives. It can be reasonably observed that as the production and manufacturing costs of electrical and electronic components decreases, and as the availability of high-computational power becomes more conventionally available, we can tap into new definitions of sustainable engineering systems and policies.

However, it must be noted that change can only occur when it is at the centre of the movement that drive it. A softwares engineers, we are morally and ethically bound to take into consideration the fact that the products we create impact real lives, that each extra bit used while allocating memory space adds up and leads to more stress on the processor, that it leads to the processor suking in more power, that when it is scaled up for large scale and ultra-large scale systems, the cumulative impact of our work has a different level of impact on everything that it touches.



Barkenbus, J. N. (2010). Eco-driving: An overlooked climate change initiative. Energy Policy, 38(2), 762–769.

Commission, F. E. R. (2008, December). [Assessment of Demand Response and Advanced Metering]. Retrieved April 1, 2016, from http://www.ferc.gov/legal/staff-reports/12-08-demand-response.pdf

Gerard, D., David, G., & Lave, L. B. (2005). Implementing technology-forcing policies: The 1970 Clean Air Act Amendments and the introduction of advanced automotive emissions controls in the United States. Technological Forecasting and Social Change, 72(7), 761–778.

Landsbergen, P. (2009, June 30). Feasibility, beneficiality, and institutional compatibility of a micro-CHP virtual power plant in the Netherlands. TU Delft, Delft University of Technology. Retrieved from http://repository.tudelft.nl/assets/uuid:ee01fc77-2d91-43bb-83d3-847e787494af/Master_thesis_Landsbergen.pdf

Loria, D., Dennis, L., Robert, N., & Edward, S. (2004). The First Commercial Ocean Thermal Energy Conversion Power Plant: Taking a Renewable Energy Technology Project From Concept to Commercial Operation. In ASME 2004 Power Conference. http://doi.org/10.1115/power2004-52114

May, G. A., Kenneth, G., & Bill, H. (1995). Commercial use of space technologies for precision farming. In AIP Conference Proceedings. http://doi.org/10.1063/1.47247

  1. J. Darr, Darr, M. J., Zhao, L., Ehsani, M. R., Ward, J. K., & Stombaugh, A. T. S. (n.d.). EVALUATION OF CONTROLLER AREA NETWORK DATA COLLECTION SYSTEM IN CONFINED ANIMAL FEEDING OPERATIONS. In Livestock Environment VII, 18-20 May 2005, Beijing, China. http://doi.org/10.13031/2013.18363

Nezamabadi, H., Hossein, N., & Vahid, V. (2015). Two stage decision making of technical virtual power plants in electricity market via Nash-SFE equilibrium. In 2015 3rd International Istanbul Smart Grid Congress and Fair (ICSG). http://doi.org/10.1109/sgcf.2015.7354932

Pooley, R., Coady, J., Schneider, C., Linger, H., Barry, C., & Lang, M. (2013). Information Systems Development: Reflections, Challenges and New Directions. Springer Science & Business Media.

Reinhardt, F. L., Stavins, R. N., & Vietor, R. H. K. (2008). [Corporate Social Responsibility Through an Economic Lens]. Review of Environmental Economics and Policy, 2(2), 219–239.

Sagner, J. S. (2011). Cut costs using working capital management. Journal of Corporate Accounting & Finance, 22(3), 3–7.

Sørensen, J. T. (1997). Livestock Farming Systems: More Than Food Production : Proceedings of the Fourth International Symposium on Livestock Farming Systems.

United States. (2011). Energy Independence and Security Act of 2007. Books LLC.

Wang, F., Fan, W., Xiaofan, L., & Ning, S. (2011). A multi-objective optimization for green supply chain network design. Decision Support Systems, 51(2), 262–269.


Design Thinking

This week’s lecture was addressed by Steph Mellor, a senior executive designer at ThinkPlace; it was quite insightful in that it introduced to us — in a very approachable manner, and with awesome Captain Planet references — the concepts encompassing a new way of creating solutions: design solutions.

Design Thinking is a way of looking at the world that tolerates ambiguity and manifests itself in the form of processes, methodologies, activities and synergies. Unlike most conventional methods of meeting challenges, design thinking promotes doing so without any assumptions: this is to say, design thinking professes approaching problem situations without prior bias, and to treat each individual situation in the particular context in which it exists. Moreover, a fundamentally unique feature of design thinking is that it is human-centric.

Design Thinking: A Dance of Fire and Nice

Design Thinking differs from most other methodologies of addressing problem situations in that it has, at the core, a human-centric foundation of interest. Additionally, it follows what can only defined as a verisimilar form of the scientific method: it comprises of multiple interrelated processes that define specific manners of meeting specific issues with complete regard for the specific context surrounding the issues in question; it focuses on observation, finding patterns from these observations, formulating educated notions to explain these patterns, creating solid methods to validate said explanations in a repeatable and palpable manner, and then making a final assertion, plan, or course of action.

(Image courtesy: http://www.lifescied.org/content/5/1/7/F6.expansion)

To put it simply, design thinking — being human-centric — aims to create solutions that dance around humans, unlike making humans dance around the solutions. This is a critical factor in the success of engineering and computer systems, especially those intended to provide a service or utility for its users.


(Image courtesy: http://ssir.org/articles/entry/human_centered_design_and_the_last_mile)

Case-in-Point: MetaVision Intensive Care Program

(Image courtesy: http://www.metropolitanmed.com/images/products/lg/iMDsoftMetaVision.jpg)

MetaVision ICU program (Katayama & Katsuyuki, 2011) was a software package developed by a US firm called iMDsoft as a specialist critical care application program. It collects information from an array of medical devices and full patient medical records, and is loaded with a knowledge-management and decision-support system that is intended to support administration of medications to patients in Intensive Care using IV infusion pumps. The Queensland government (McDonald, 2014)(Moore, n.d.) bought this package and planned to use it in over nine hospitals before a major bug was discovered in the package; one patient risked death due to this flaw which caused a large volume of drug-administration for the patient.

Upon the discovery of this fatal bug, investigation revealed that it had increased the likelihood of death for certain patient by 60-90 percent; a staggeringly dangerous figure. Analyses found that despite of the large scale of the knowledge-base and decision support system, there was simply too much data flowing through the ICUs for the system to be able to handle; the methodologies used to titrate specific dosages depending upon specific circumstances required what doctors later described as intuitive knowledge gained through experience. The program ended up being largely scrapped, and manually over-ridden as a result.

There was a gap (Weissman, 1992) in what the system was designed to do, and what it should have been able to do. This gap was that of a subjectively valued intuitive sense that humans seem to develop — a veritable spider sense, if you will. How could it be reasonably expected of the developers of the software package to bridge this gap? This was a rarest of the rare incident; the system worked just fine everywhere else, and even in the same hospital — with the exception of this one incident there were no signs of a malfunction.

The problem lay in the fact that the system was designed with the underlying objective of streamlining workflow in ICU, to drive down operational costs incurred by having to put nurses, doctors and attendants on the payroll, and to drive up profit — from the perspective of a purely administrative point of view, this seems reasonable, however, a system that focuses on the system is setup to fail. Brook’s law talks about the efficacy of adding personnel to a delayed project backfiring: a solution that aims to make stakeholders dance around the solution is not a solution at all. A software project can only be called truly successful if it can cater to the needs of the people who would be affected by the deployment of the project in the real world.

(Image courtesy: https://squatuniversitydotcom.files.wordpress.com/2016/02/systemfailure.jpg)

Designing the bridge for the gap

Design thinking can be seen in software engineering practices such as Agile development: a project is iteratively designed; a comprehensive risk-profile is associated with each iteration; the project is deployed to the market knowing that future iterations will probably be required. With Agile, and its early deployment paradigm, the products can go through the most rigorous forms of testing and feedbacks, that is, human usage. A partial full-scale deployment that is at the core of Agile enables users to really use the product, thereby putting it to real test. Knowing that multiple iterations are probably going to be required, the developers are geared to respond to feedbacks, instead of reacting.

Successful design thinking can be used to push the definition of systems engineering, especially for software engineers. Software is, after all, a part of a whole system, and not the system itself. Therefore, by having a comprehensive understanding of the position and function of the software components of a system, the software can be designed to engage the specific nuances as elicited by the specific requirements of the subsystem scope.

A good approach to bridge these gaps in the way softwares are built, the process encompassing designing softwares should take from some of the abstract concepts that go into making these softwares: a software engineering approach to software engineering, so to speak. Design solutions, and design thinking are enabling drivers for a such approach.


Katayama, K., & Katsuyuki, K. (2011). Development of a Clinical Information Management System for the OR, ICU and ER Using the MetaVision® System. THE JOURNAL OF JAPAN SOCIETY FOR CLINICAL ANESTHESIA, 31(2), 226–234.

McDonald, K. (2014, October 27). Bug in MetaVision ICU system potentially catastrophic. Retrieved March 31, 2016, from http://www.pulseitmagazine.com.au/component/content/article?id=2127:bug-in-metavision-icu-system-potentially-catastrophic

Moore, T. (n.d.). Health software brings risk of death. Retrieved March 31, 2016, from http://www.brisbanetimes.com.au/queensland/health-software-brings-risk-of-death-20141026-11c6nj.html


Systems Thinking

This week’s lecture covered the issues encompassing escaping the complexity dilemma. The complex nature of the complex world in which we live, riddled with different kinds of complexities — detail and dynamic — seem to unravel issues which cannot be addressed using conventional management approaches. Creation of systems, and software systems, to address such issues thus calls for the use of unfamiliar forms of reasoning, analyses and engineering solutions.

Let’s consider a few key elements associated with systems thinking…

Causal Diagrams

(Image courtesy: https://sites.google.com/site/protractedlearning/systems-thinking/causal-loop-diagram)

Causal diagrams were introduced as one of the tools that can be used to address dynamically complex problem situations by addressing the various subtle intermingling underlying causative factors. Through the use of feedback loops, resilience alliance and a broad application of systems dynamics two critical issues which software systems sometimes fail to address are brought into the spectrum of cross-dimensional causation: runaway growth; runaway collapse.

Policy Surprise

(Image courtesy: http://lifestyle-leadership.com/wp-content/uploads/2014/03/paradigm-shift-e1395608377248.jpg)

The concept of Policy Surprise was introduced to explain the reason why engineering and computer system solutions need to keep pace with the changing operational environment if they mean to keep up with the constantly changing paradigms for the initial scope of these solutions. To put it simply, during the course of software development life-cycles (SDLC) the methods used to requirements analysis, management and resource allocation are still using measurement metrics which are no longer truly representative of the scope of stakeholder spectrum. This tends to lead to surprises in and after the SDLC. It is for this reason, that new approaches must be developed.

Systems Archetypes

The complexity dilemma explains complex systems behaviour as a response to policy initiatives. The whole is too complex to study, the parts are not complex enough. A proven way to address such dilemmas is through the use of systems archetypes: illustrating theories of general systems behaviours using systemic behavioural patterns.

There are, nevertheless, several issues which still remain unaddressed despite of the relative success of such systems archetypes. The most commonly observed issue is that of such software or computer system solutions addressing the symptoms manifested by the problem situations, instead of the problem situation itself. In doing so, while the symptoms seem to get resolved in the short term, the problem persists.

An example of this can be expressed through a problem situation that emerged in the U.S. after the introduction of Obamacare and the consequent restructuring of the medicaid. To put it in a really overly simplistic manner, Obamacare used a series of algorithms to help people from specific demographic and socio-economic backgrounds falling in a specific purview of insurance premiums by making them eligible for Obamacare. Medicaid was historically used for the same objectives for all citizens, notwithstanding this specific purview as deduced by Obamacare. The problem arose as Medicaid was expanded to cover all those who did not get covered by Obamacare as this led to specific people being left in the margins of the overlap between the two programs. These people are deemed to be too rich for medicaid, and not rich enough for Obamacare, leaving them stuck between Scylla and Charybdis. This has been a major case where a system intended to resolve one complex issue, unintentionally, lead to the creation of another.

(Image Courtesy: http://obamacarefacts.com/obamacares-medicaid-expansion/)

Systems Thinking Approaches for Wicked Problems

Wicked problems are their namesake, wicked by nature. These are quagmire like problem situations which engulf one into their own embroiling mess more and more as one tries to get out of them. The key to addressing problems wicked problems is, thus, not to try and solve them, but instead manage them; to pick what we choose elements we deem to have priority over those that we may, at the moment, choose to ignore; a calculated risk, so to speak.

ShiftN Obesity System Influence Diagram

While looking for real-world systems thinking solutions for real-world problems, I came across an initiative by a Belgian design solutions firm called ShiftN (shiftN.com, n.d.). As part of one of their projects concerning obesity in the U.K., shiftN created a UK Obesity System Influence diagram (“Obesity System Influence Diagram,” n.d.) that illustrates a detailed causal loop diagram comprising of the numerous constituents involved in the system. The design comprises of a simple colour-coded layout which highlights specific components from the subsystems in specific manners, and in doing so it becomes easy to visualize how these components of these subsystems affect other components from the same, or different subsystems, and how the subsystems interact with each other.  This work was critical in creating the school-meals policy in the U.K. as enabled the policy makers to make informed decisions using the knowledge base created as a consequence of work done by ShiftN.

(Image Courtesy: http://www.shiftn.com/obesity/Full-Map.html)

Business Intelligence

The use of computer systems, computer science, information systems, engineering solutions etc is critical to a significant proportion of business across the globe today. Converting raw data into information, information into knowledge, and using this knowledge along with experience (gained from analyses of historical knowledge and information)  to make intelligent decisions is a critical application of softwares and software systems today.

However, in order to perfectly utilize systemic components ranging from data sources to data warehouses, from using cloud computing platforms to managing performance optimization and networks security issues, from managing quality of service to compartmentalized constituent tools, all the while managing redundancy and maximizing user experience is quite a tall order. The use of systems thinking allows the systems designers to be able to encapsulate such complex systems through targeted abstraction — analogous to object-oriented programming, if you will; is it any wonder why ICT professionals are so often hired as consultants for business optimization? we have a good handle on how big stuff with a lot of moving parts tend to work.

CMMI for Development

If there is a list of good examples of applied systems thinking revolutionizing the software development industry as we know it, CMMI for Development would surely be on the top the such a list. Developed by Carnegie Mellon’s Software Engineering Institute, funded by the U.S. Department of Defense, CMMI for Development has proven to result in immense improvements in the quality of products, quality of the businesses making these products, and in considerably high profit generation (undefined, n.d.) for the businesses as a direct result of incorporating CMMI of Development at the core of their business processes.

Using systems thinking and design solutions concepts, CMMI creates an abstract framework that defines business processes involved in the software development process. In doing so, causal relations between the process involved are related to each other in meaningful ways so as to maximize not only the products produced, but the processes themselves. As a consequence, valuable resources (time, money etc) can be used for the process of developing products and not having to engage in a separate intellectual exercise to come up with process solutions for each new product.

Revolutionizing the Middle Tier of Software Engineering

Upon the consideration of the positive implications of imbuing systems thinking into a systems engineering approach in software engineering, it becomes fairly clear that a collaborative interdisciplinary approach enables the creation of solutions that interact and address problem situations in a comprehensive manner. Traditionally, software systems have been reactionary, which makes them largely retroactive, thereby considerably inefficient. Software Engineering has, as a result, developed a bad rep. The use of experience, armed with a collaborative approach has the potential to create responsive systems that can remain ahead of the curve, and preemptively respond to unforeseen issues that are, naturally, to be expected in complex problems.



Obesity System Influence Diagram. (n.d.). Retrieved March 31, 2016, from http://www.shiftn.com/obesity/Full-Map.html

shiftN.com. (n.d.). shiftN.com | clarity in complexity. Retrieved from http://www.shiftn.com/

undefined. (n.d.). Bottom-Line Profit and Cost Numbers: Assessments Pay | Why Do CMMI Assessments? | InformIT. Retrieved March 31, 2016, from http://www.informit.com/articles/article.aspx?p=369222&seqNum=9

Systems Engineering

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.


Ahern, D. G. (2009). Joint Strike Fighter: Accelerating Procurement Before Completing Development Increases the Government’s Financial Risk. DIANE Publishing.

Axe, D. (2011, December 13). Trillion-Dollar Jet Has Thirteen Expensive New Flaws. Retrieved March 31, 2016, from http://www.wired.com/2011/12/joint-strike-fighter-13-flaws/

Bevilaqua, P. M. (2009). Genesis of the F-35 Joint Strike Fighter. Journal of Aircraft, 46(6), 1825–1836.

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

Company, D. P. (1996). Denver International Airport: Baggage Handling, Contracting, and Other Issues. DIANE Publishing.

Dimensions of Peace and Security. (n.d.). Retrieved March 31, 2016, from https://books.google.com.au/books/about/Dimensions_of_Peace_and_Security.html?id=JNZTfdg5WCcC

Haley, J., & John, H. (n.d.). Joint Strike Fighter. In Encyclopedia of United States National Security.

Malfunctioning baggage system delays Denver airport. (1994). Computer Audit Update, 1994(11), 16.

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.

Ramsey, R. E., & Miller, D. J. (2012). Experiences between Philosophy and Communication: Engaging the Philosophical Contributions of Calvin O. Schrag. SUNY Press.

Sweetman, B. (2004). Ultimate Fighter: Lockheed Martin F-35 Joint Strike Fighter. Zenith Imprint.

Introduction to Systems Engineering for Software Engineers


Software Engineering is at the heart of almost everything that comprises our daily life nowadays. As technology is progressively becoming integral to our way of life, softwares are becoming progressively complex, and ubiquitous. This has redefined the way in which softwares are used, and the way in which software engineering must now operate.

Nevertheless, softwares, by themselves, seldom are the sole constituents of the systems of which our lives are comprised. Instead, software systems are parts of larger systems and systems of systems each of which comprise of numerous other interrelated and interactive systems. Understanding the way in which systems function is, therefore, at the core of creating good softwares.

This course, Systems Engineering for Software Engineers is centered around this element of software engineering: understanding how softwares work in the context of larger systems. Through the use of multi-disciplinary and collaborative elements, it is expected to develop the skills with which we can develop the skills required to create software systems that solve real-world problems while addressing the complexities of real-world situations.

The Learning Approach

Each week, a unique perspective towards systems engineering, and software engineering forms the topic for the lectures, tutorials, and the readings. The objective is to develop a holistic world view from the perspective of a software engineer in order to truly understand where a developed system would fit in the bigger picture.

The following iterative approach is at the center of the learning methodology for this course:


Expected Learning Outcomes:

At the successful completion of this course, it is expected of the students to be able to:

  • Address a holistic and cross-disciplinary course of action for complex projects
  • Communicate with cross-disciplinary teams and communities at large
  • Uphold professional and ethical obligations expected from software engineers
  • Be a part of, and have the ability to federate cross-disciplinary teams comprised of individuals from varying backgrounds