Home » SyEN Newsjournal » PPI SyEN 55

PPI SyEN 55

Read monthly Project Performance International's Systems Engineering Newsjournal, named "PPI SyEN". PPI SyEN presents for the engineering professional 30-60 pages of valuable technical articles on topical subjects, shorter technical pieces, in-depth coverage of the month's news in systems engineering and directly related fields, pointers to useful resources and relevant industry events, plus limited information on PPI's activities.

Welcome to PPI SyEN 55

In This Edition

Quotations to Open On

Feature Article

Systems Engineering Decision Analysis can benefit from Added Consideration of Cognitive Sciences by Scott Jackson and Avi Harel

Article

Getting at the Rest of the Communication Iceberg by Ronald G. Ross
Integrating Program Management and Systems Engineering by Ralph Young

Systems Engineering News

Norway Planning the World’s First Ship Tunnel
IEEE Systems Council
Can Frontline Workers Stay on the Frontline and Still Make Systems Change?
Aerospace Looks to Robotic Systems as Orders Backlog Grows
Outdated Operating Systems, Browsers Correlate with Real Data Breaches
The Composable Systems Wave Is Rising
INCOSE: Call for Nominations – 2017 INCOSE Elections

Featured Organizations

Society for Engineering and Management Systems (SEMS)
INCOSE Requirements Working Group

Conferences and Meetings

Some Systems Engineering-Relevant Websites

Systems Engineering Publications

Leading Change by John P. Kotter
The International Journal of Project Management – “Systems Engineering to Improve Governance in Complex Project Environments”
The International Journal of Project Management by Giorgio Locatelli, Mauro Mancini and Erika Romano
Agile Systems Engineering by Bruce Powel Douglass
Overcomplicated: Technology at the Limits of Comprehension by Samuel Arbesman
Technology vs. Humanity: The Coming Clash between Man and Machine by Gerd Leonhard

Systems Engineering Tools News

Innoslate by SPEC Innovations by Alwyn Smit
What is a RACI Matrix and Why Use this Technique?
Semantic Interoperability of Engineering Tools for Automation Systems Engineering

Education and Academia

Industrial Engineering and Systems Engineering at Florida Tech
Southeast Missouri State University Launching New Engineering Program in fall 2017
Volgenau School of Engineering
Oakland University to offer Master’s in Systems Engineering Degree

Standards and Guides

Systems Engineering Body of Knowledge (SEBoK) Application of Systems Engineering Standards

Some Definitions to Close On

Improving Governance in Complex Project Environments

PPI and CTI News

Upcoming PPI/CTI Participation in Professional Conferences

PPI and CTI Events

QuotationS to Open On

“We have forgotten that someone must be in control and must exercise personal management, knowledge, and understanding to create a system … Systems, even very large systems are not developed by the tools of systems engineering, but only by the engineers using tools.”

Robert Frosch, Administrator, U. S. National Aeronautics and Space Administration (NASA)

“A higher rate of urgency does not imply ever-present panic, anxiety, or fear. It means a state in which complacency is virtually absent.”

John P. Kotter

Feature Article

Systems Engineering Decisions Analysis can benefit from Added Consideration of Cognitive Sciences

Scott Jackson, PhD

Burnham Systems

Los Angeles USA

Avi Harel

Ergolight,

Haifa, Israel

Abstract

Systems engineering is conventionally defined as a multidisciplinary approach to the realization of successful systems. There is opportunity to further strengthen and improve the practice of systems engineering by increasing the use of cognitive sciences analysis in the practice of systems engineering. The goal of this paper is to facilitate this improvement by providing a framework for incorporating additional cognitive sciences analysis in systems engineering decisions. Case studies show that imperfect decisions with cognitive roots have contributed to notable accidents. Ironically, most sources limit their disciplines to technological and managerial processes, mentioning cognitive sciences only in a benign context. Cognitive science is a sub-discipline of psychology, focusing on mental processing. In this paper, we focus on two sub domains of cognitive sciences, cognitive bias and social constructionism. Existing sources discuss cognitive aspects of systems engineering but in general devote little attention to those aspects that may have catastrophic consequences. This paper suggests that these disciplines play a larger role than is generally recognized, particularly with respect to decision-making which is a standard part of systems engineering. The decisions discussed in this paper pertain both to those made by executives and by operators in the operational phase of a system. Decision- making is one area that may have such consequences; this is the area that will be emphasized in this paper. In addition, case studies show that, in addition to design decisions, imperfect decisions with cognitive roots have contributed to notable accidents. Two major approaches suggested by other sources for improving the decision-making process are improved leadership and independent review. This paper suggests that both of these approaches offer promise if rigorously implemented but have their own flaws that need to be overcome. However, the need for improved decision-making and a study into the conditions that lead to the flawed decisions suggest that a deeper look into these and other approaches is desirable. This paper examines barriers to safe operation due to decision errors, and proposes a framework for remedies.

Email: jackson@burnhamsystems.net; avi@gmail.com

Introduction

The INCOSE Handbook (Version 4) (2015, p. 11) defines systems engineering as an “interdisciplinary approach and means to enable the realization of successful systems.” Other authorities, for example, Crowder et al (2016, p. 27) list the following disciplines: “Business Intelligence, Human Factors, Technology Integration, and Science, Technology, Engineering, and Math (STEM)” skills [capitalization from source]. Psychology can only be indirectly inferred from, for example, Human Factors. There is opportunity to further strengthen and improve the practice of systems engineering by increasing the use of cognitive sciences analysis in the practice of systems engineering. The goal of this paper is to facilitate this improvement by providing a framework for incorporating additional cognitive sciences analysis in systems engineering decisions.

Current approach to assuring safe decisions

There are standard ways to mitigate human factors problems. These include teamwork, safety climate, and safety culture. But little has been proposed to address the potential catastrophic effects of cognitive bias. There have been two primary solutions proposed by other sources concerning the issue of cognitive bias. One is to select good leaders. The other is to use an independent review process. Both solutions will increase the likelihood of successful systems if obstacles can be overcome. This section discusses both solutions, the obstacles, and the path to making them work. We have concluded that both solutions have their flaws which need to be overcome if rational decisions are ever to be made.

Patterson (2009, p. 67) correctly identifies “inadequate decision-making” as one of the shortfalls of leadership. He states, “Leadership over human beings is exercised when persons with certain motives and purposes mobilize in competition or conflict with others, institutional, political, psychological, and other resources to arouse, engage, and satisfy the motives of followers.” Patterson does a competent job of describing the problem. However, the unanswered question is: how does an organization select leaders to address these problems?

Many ill-informed decisions are made by leaders themselves. So, having good leaders is the goal of organizations designing and deploying high-consequence systems. Jackson (2010, pp. 114-118) provides a list of leadership qualities with a focus on system success:

Place safety first
Trust metrics and early signs of trouble
Take responsibility for the management aspects of safety and resilience
Strive for commonality of interest with technical personnel

With respect to these qualities, the organization itself can supply much support to the leaders in helping them achieve their goals. First, most organizations assign risk management to the systems engineering organization. In this role, the systems engineering organization can provide the leader with essential information regarding “signs of trouble”.

An entire book devoted to teaching decision-makers how to make good decisions is Weick and Sutcliffe (2001, p. 16). Among rules recommended by the authors is “deference to expertise”. But, once again, the basic flaw of this philosophy is that it is the decision-makers themselves who suffer from cognitive bias and are therefore unlikely to follow these rules.

Regarding organizational structure the leader can fall to the SEIT (systems engineering and integration team) to be both functionally and physically available to help the leader.

The basic flaw in the leadership approach is that the leaders themselves would need to approve the process to limit their own ability to make decisions. If the leaders themselves suffer from the cognitive biases, then they are unlikely to approve this process.

The second approach, the one recommended by the Columbia Accident Investigation Report (2003, p. 193), has some degree of legitimacy. This approach does not address the decision-making process; it only seeks to overturn bad decisions. The report recommends an Independent Technical Authority (ITA) review of all decisions and overturn them if necessary. NASA has instituted this approach. Even within this approach, the one unanswered question is: how do you define independent? The NASA report does not answer this question. The simple answer to this question is that independent means having no organizational or financial ties to program management. If this can be achieved, then there is independence.

Leveson et al (2006, p. 121) also endorse the independent authority approach. One of the duties of the ITA according to Leveson et al would be to track the increased risk due to the “increased power and authority of safety decision-makers.”

The power of this approach can be found in the word Independent. That is, it is assumed that persons outside the organizational and financial constraints of the program will be better able to address potential problems objectively and recommend better decisions. Within the current governmental structure there are already two mechanisms that are designed to meet this goal. Within the military aviation context, the airworthiness board is designed to accomplish this objective. For potential governmental problems in general the General Accountability Office (GAO) is designed to achieve this level of independence.

Within commercial aviation the Federal Aviation Administration (FAA) serves this role to a certain extent. However, even within this domain, the organizational leadership is responsible for accepting the oversight of the IPT.

The factor which lends legitimacy to the ITA concept is that it has been endorsed by recognized authorities. One is the Columbia Accident Investigation Board (CAIB). The other is MIT professor Leveson whose expertise in safety is well known. In contrast to widespread assumptions, experts did not make fewer errors than novices (except in knowledge errors) according to Prumper et al (2007).

In short, both of these approaches have flaws; and both have the potential for reducing the consequences of imperfect decisions if rigorously implemented. This is not to argue that these are the only approaches; if researchers can identify other approaches, an open mind is encouraged. This paper argues that this is an issue that needs to be studied deliberately.

In addition to these two approaches, one solution is to look to the emergent science of resilience engineering to assure that the entire system, the aircraft for example, has employed sufficient design features to assure that it achieves a sufficient level of functionality following a major disruption. Pilot error is only one of many types of threats that have been studied. Pariès (2011, pp. 9-27), for example, shows how a combination of aircraft design and pilot action resulted in the safe ditching of US Airways Flight 1549 following a bird strike. All 155 occupants of the aircraft were saved.

Cognitive Sciences

In general use, cognitive science is the interdisciplinary, scientific study of the mind and its processes. In this paper, we focus on the application of cognitive sciences on any mental factor that may distort the meaning of risk and lead to irrational decisions. The following paragraphs describe related concepts:

Psychology – According to the Oxford on-line dictionary (Oxford 2017), psychology is the “scientific study of the human mind and its functions, especially those affecting human behavior in a given context.” Hence, psychology is an overlying concept affecting all of the cognitive sciences discussed in this paper.

Cognitive engineering – is the application of cognitive sciences to system development. Shneiderman (1980) proposed guidelines for software design, to ensure that the computer is friendly. Norman (1981) coined this term, proposing guidelines for designing operating systems.

Human System Integration (HSI) – is an interdisciplinary technical and management process for integrating human considerations with and across all system elements, an essential enabler to systems engineering practice. Human activity considered by HSI includes operating, maintaining, and supporting the system. HSI also considers training and training devices, as well as the infrastructure used for operations and support according to the Defense Acquisition University (2010).

Social Constructionism – Tierney (2014, p. 29) states that “while risks are obdurate [unyielding], facts, societal and group perceptions of and responses to various risks, including ideas about reducing them, are shaped by socially derived knowledge and understanding.” Although psychology may play a role in social constructionism, the latter pertains to groups of people and not just individuals.

Behavioral Economics – According to Huettel (2014, p. 1) “behavioral economics . . . integrates economics and psychology . . . towards the goal of explaining real-world decision-making.” Cognitive bias, described below is part of behavioral economics. This field received a major boost when Daniel Kahneman and Amos Tversky published findings related to it. Kahneman received the Nobel Prize for his work (Tversky had already passed away). Kahneman’s Nobel citation (2002) is as follows: “for having integrated insights from psychological research into economic science, especially concerning human judgment and decision-making under uncertainty”.

Cognitive Bias – According to Chegg (2015), a cognitive bias “is a mistake in reasoning, evaluating, remembering, or other cognitive process, often occurring as a result of holding onto one’s preferences and beliefs regardless of contrary information.” Cognitive bias is also called cognitive distortion. Cognitive bias is a much narrower and more specific phenomenon than behavior economics or social constructionism. However, like all the cognitive sciences discussed here, it has a fundamental foundation in psychology.

Sources of Decision Errors

Among systems engineering sub-processes, decision-making is a major part; it is not the only part that demands further attention from a cognitive science perspective, but it is the part that that has the potential for catastrophic consequences. Blanchard and Fabrycky (2006, pp. 161-288) devote a considerable portion of their book to decision-making. However, there is an implied assumption that decision-making processes are rational, that is, based on the evidence available. The decisions discussed by Blanchard and Fabrycky are, however, design decisions, which are not to be neglected. Irrational decisions can include design decisions, operational decisions, or launch decisions, as in the case of space vehicles.

Studies about the sources of critical accidents indicate that most of them are commonly attributed ad-hoc to human errors:

In the air (60%) – PlaneCrashInfo (2014)
On the sea (80%) – Baker et al (2004)
In driving (90%) – AlertDriving (2017)
In the industry (60-80%) – Kariuki and Löwe (2004)

Among sources with an extensive discussion of cognitive science in a systems engineering context is Orasanu and Shafto (2009, pp. 691-721). These authors correctly state that “people make poor decisions because they misclassify or misdiagnose a situation, underestimate risk, fail to consider options, or fail to take relevant factors into account.” Their focus is on the design of a system to avoid or mitigate the effects of these errors. However, other sources, for example, Chegg (2015), focus on the humans themselves and why they make these errors, not just design errors but operator errors as well. This is the question that needs further attention.

One authority who demonstrates a knowledge of how psychology influences decisions is Tierney (2014, p. 5). Tierney says that the idea that disasters are socially produced represents a departure from current and historical ways in which disasters have been characterized.” Tierney (2014, p. 29) does admit that “risks actually do exist in the physical world.” However, Tierney contends that risk takes on a social, or psychological construction. She states that “like other social constructions, risk-relevant social constructs have their roots in a variety of sources, including scientific knowledge, mass media, folklore, and popular culture, and positions advanced by interest groups and opinion leaders”.

Shenhar and Sauser (2009, p. 146) list knowledge of behavioral sciences and organization theory. However, the knowledge advocated by these authors is limited to motivation, leadership, and communication. There is no mention of decision analysis requiring knowledge of behavioral sciences. Reason (1997) presents an extensive study of accidents and concludes that a large percentage of accidents is not the result of technological errors but rather by human and organizational causes.

Although many sources, including Orasanu and Shafto, above, identify cognitive sciences as a legitimate discipline to address within a system engineering context, the most catastrophic phenomena are generally underemphasized or completely ignored. Furthermore, solutions for this problem are not well stated. This paper addresses that concern.

Attributing the failure to the operator offers some advantage to the stakeholders in terms of accountability, and to the public, but is destructive in terms of the need to learn from the accidents as discussed by Dekker (2007, pp. 91-103). Hollnagel (2003) suggested that the term error is commonly used to refer to instances of costly results of normal operation. Reason (1997, pp. 191-220) pointed at the role of safety culture, and claimed that the organization should be responsible for preventing human faults. Norman (1983, pp. 254-258) coined the principle that systems should protect themselves from mishaps by design, and demonstrated methods to implement this principle. Zonnenshain & Harel (2015) proposed to justify this approach by adopting the human-factors variant of Murphy’s Law, stating the “if the system enables the operators to fail, eventually they will”. Accordingly, this paper focuses on ways to prevent human faults.

Modeling irrational behavior

Traditionally, engineers expect human beings to think and behavior rationally, according to logical rules and conventions. In particular, systems engineers expect the stakeholders, including operators, users and executives, to consider safety and risks rationally. The problem is that all people, including engineers, behave according to implicit rules that do not seem rational in terms of common practices. A main challenge in systems engineering is to identify and specify the factors affecting real thinking and behavior, and to design the system such that they fit these implicit rules.

Cognitive bias

Cognitive bias is defined as a systematic pattern of deviation from norm or rationality in judgment, whereby inferences about other people and situations may be drawn in an illogical fashion as discussed by Haselton et al (2005). Individuals create their own “subjective social reality” from their perception of the circumstances. An individual’s construction of social reality, not the objective input, may dictate their behavior in the social world as discussed by Bless et al (2004).

Confirmation bias

According to Chegg, one of the more well-known cognitive biases is called the ‘confirmation bias’, which is defined as “the tendency to seek only information that matches what one already believes.” Bainbridge (1983) uses the term “irony of automation” to explain why in emergency operators suffer from the “tunnel vision” effect regarding perception of new information.

According to confirmation bias, when the decision-maker acts according to prior perception of the problem, disregarding contradicting evidence. This is the tendency to search for, interpret, favor, and recall information in a way that confirms one’s preexisting beliefs or hypotheses as discussed by Plouse (1993).

In the study of risk management, Conrow (2003) provides an extensive list of cognitive biases often found among decision-makers. Among these is the view that risk management is a “waste of time”.

Risk assessment

A common practice in risk management is based on the expected value of the costs, namely, the integral of cost estimates times the probability of the events ending up in these costs. However, as Taleb (2010, pp. 9, 38-44, 100-119, 135-164) explains, this method is useless, because we never have the data required to estimate the costs and their probabilities. This means that we cannot get values for the risks that may be useful for decision-making.

Cost assessment

Of particular concern is the assessment of accidents involving casualties. The “rational” way to compare the costs of such risks is linear: for example, the costs of 1000 people being killed is 1000 the costs of one person being killed. However, subjective evaluation of casualties is by a psychophysical scale, which is logarithmic according to Smidts (1990).

Post-traumatic risk assessment

The cost estimates change drastically following an accident. This is the black swan effect as described by Taleb (2010, pp. 86-94, 171-173, 281-285). Failure modes not considered in the original design are now in the focus. People are willing to pay for safety much more than before the accident. For example, before the Al-Qaeda attack on the United States on Sept. 11, 2001, it was unlikely that people would agree to the security means in airports applied today as described by Taleb (2010, pp. 215-222).

Safety price

The price that people are willing to pay for safety is not fixed. It depends on expectations, on prestige, and the public awareness of the risks. It is affected by the relevance to the people, by campaigns of solution providers, and other factors. For example, the price of a space shuttle accident is much higher than the sum of the prices of the shuttle and the insurance payment, when the whole world is watching the performance on TV. Practically, we do not have a formula for calculating a reliable, stable cost estimates.

Ego-centric design

Designers often fail to predict the way the operators will eventually behave. The way they work around this limitation is by applying their own preferences. For example, designers define shortcut key combinations in order to facilitate their own interaction with their program, disregarding the implications on unintentional key substitution as noted by Harel (2017b).

Weinberg (1971) noted that the source for barriers to understanding the system behavior is a cognitive bias of the programmers, due to arrogance. Subconsciously, the designers punish the users for thinking differently, by hindering fluent operation.

The hindsight effect

In the accident investigation, the investigators assume that the operators can learn how to behave in no time. This is the hindsight effect described by Dekker (2007, pp. 65-73). An example of the hindsight effect is the investigation of the US Airways 1549 miracle on the Hudson River.

The NTSB used flight simulators to test the possibility that the plane could have returned safely to LaGuardia or diverted to Teterboro; only eight of the fifteen runs succeeded, although all four attempts to reach the nearest LaGuardia runway, Runway 22, were successful. https://en.wikipedia.org/wiki/US_Airways_Flight_1549 – cite_note-90 But the NTSB report called these simulations unrealistic: “The immediate turn made by the pilots during the simulations did not reflect or account for real-world considerations.” A further simulation, conducted with the pilot delayed by 35 seconds, crashed according to the NTSB (2010).

In testimony before the NTSB, the pilot, Sullenberger, maintained that there was no time for the maneuvers needed to bring the plane to any airport; such any attempt would likely have killed those onboard and more on the ground.

Responsibility

What happens when a leader makes the wrong decision? Often, the subordinates do not notice the mistake; they believe that the decision is right. For example, in 1923 the whole Squadron 11 crashed on the coast of Santa Barbara, California, because the commander relied on the wrong interpretation of the navigation data, and nobody checked to verify if the interpretation was correct according to Casey (1998).

When the subordinates notice a mistake, they might hesitate, and they might avoid commenting about what they see or acting. For example, this was the case for Asiana Flight 214 in 2014.

Self-awareness

People believe that they do their best for the company, and for safety. However, unconsciously, they always do things to promote their position, overlooking the company’s interests. This applies to all stakeholders, including executives and operators.

Accountability

A far more difficult question to ask beyond how to make good decisions is: to whom should the decision-maker be accountable? In today’s world, there are various systems of limited accountability. It is not clear that any of them truly address the risks of cognitive biases. Here are a few examples.

“This is an unfair thing about war: victory is claimed by all, failure to one alone” according to Tacitus, Agricola 27:1 (98 AD) (2007).

When admitting responsibility, one can take the actions to prevent repeating an accident. The problem is that responsibility is associated with accountability. Therefore, nobody wants to admit responsibility. The common practice is to look for somebody else’s accountability. The result is that the persons who can prevent the next accident are busy blaming people, typically the operators, instead of learning from the accident.

In the Tenerife case the pilot was obviously accountable to the airline. The airline presumably trained the pilot in basic rules, such as “do not take off until given the clearance.” But how does the airline deal with cognitive bias? This is not known and is a challenge.

For executive decision-makers, such as in the Deepwater Horizon and Space Shuttle disasters, to whom does the executive report? In the Deepwater Horizon case the entire BP Company was held liable in the US courts. Will this approach prevent similar disasters from happening in the future? Time will tell.

In the Space Shuttle cases the US congress made NASA subject to the CAIB judgment. But as in the Deepwater Horizon experience, this accountability was established after the disasters. There is no known remedy for these decisions before the fact.

The US government has a unit called the GAO (General Accountability Office) that reports directly to congress. This office has a reputation for objectivity and honestly. Whether its recommendations are heeded is another topic for study. It is not known whether this office has ever tackled the question of the impact of cognitive biases.

Probably the most comprehensive discussion of accountability is by Dekker (2007). Among the various aspects of accountability, following are three:

Legal accountability. Dekker (2007, pp. 20-23) cites the legal aspect as a major factor in accountability. This not an easy or definitive answer to the question of accountability. He cites the difficulty of lawyers and courts to understand the difference between individual responsibility and system responsibility.

Public accountability. Dekker cites the role the media play in informing the public about accountability issues. He cites cases in which publicized incidents led to improved safety.

Learning. It is, to some extent, satisfying to know that organizations are making changes in procedures and policies when mistakes are made. It is usually impossible, however, to know whether the decision-makers were truly contrite.

In summary, it is not clear at this time whether there is a fool-proof solution for accountability. This is a topic that needs to be addressed. Most importantly, whatever accountability system is adopted, likely a multiplicity of systems, it should hold decision-makers to account at all levels: executive, designer, and operator.

Safety climate

Safety climate is the perceived value placed on safety in an organization at a particular point in time. These perceptions and beliefs can be influenced by the attitudes, values, opinions and actions of other workers in an organization, and can change with time and circumstance according to WorkCover Queensland (2017).

Safety climate is a term used to describe an ideal situation, in which the stakeholders and the employees share common interests. The problem is that the employees know that in case of a crisis such as an accident, their interests conflict those of the stakeholder.

Case Studies

Case studies of note consist of those that discuss decisions both by senior managers, designers, and operators of systems. These case studies represent only a small percentage of the number of accidents in which flawed decisions contributed to the events. However, these are among the most familiar to the public.

Design Decisions

Another factor in the study of accidents is the design decision process. The Columbia Accident Investigation Report (2003, pp. 125-126) concludes that even the method of presentation of decisions options can be a source of error. But even this can be considered a cognitive aspect since it is the human interpretation of the decision presentation that was a factor in the flawed decision,

Decisions by Executives

The two most notable failures of the Space Shuttle program were Challenger and Columbia. Cognitive factors played a role in both failures. This is not to say that design problems did not also play a role, but the intent here is to point out the cognitive factors in both cases. Both of these cases illustrate decision errors made by executives. Operators of systems also make decision errors. We will discuss those below.

Discussing the Challenger accident, Vaughn (1997, p. 82), for example, states that the policy towards risk on that program were “normative”, that is to say, risks that were normal did not require any special attention. Possibly, it was this inattention to risks that contributed to the Challenger accident.

The second major event in which cognitive factors played a role in decision-making was the Columbia accident. The Columbia Accident Investigation Report (2003, pp. 184-192) stated that NASA had a “broken safety culture”.

The decision-makers in both cases above were, of course, executives. Therefore, the lessons to be learned from this paper will apply to that category of person. Of course, there were technical causes of this accident; but the report concludes that the cultural aspects were at least as important.

Decisions by Operators

It is notable that the worst commercial aircraft disaster in history on the Spanish island of Tenerife in the Atlantic in 1977 was marked by cognitive bias factors. According to McCreary et al (1998, pp. 23-32) “the [KLM] pilot responded to the stresses of time and weather by literally shutting all other players, including the ATC [air traffic control] officers, out of his decision-making loop.” In the end, 583 people died. It is safe to say that although there were many other stress-inducing factors, the responsibility for this disaster rests with the pilot and his cognitive biases.

This latter incident comes under the heading of errors by operators rather than executives. Hence, cognitive bias can be experienced at any level of the organization. One may ask whether the Tenerife accident could have been avoided by design changes in the aircraft. It is possible that design changes could have been made, but for the accident at the time the primary responsibility for the accident lay with the pilot and his psychological condition. So, the focus of future work should be on the human rather than the design. However, design improvement should not be taken off the table. Whenever safety can be enhanced by design changes those changes should be the preferred approach. However, the more difficult and important task is to focus on the human.

A Comparison of the Impacts of Decision Errors

The consequences of a decision error can be either wide-spread or focused. An example of a wide-spread consequence is the Deepwater Horizon case. The source of this error was an executive error which is widely known.

The Tenerife accident is an example of a focused consequence in which two aircraft were total destroyed. As noted above, this accident was caused by operator error, that is, the pilot.

Hence, it is not possible to say that executive-caused errors are more serious than operator errors. Both can be wide-spread. But in general, it can be said that the consequences of a decision error depend on the circumstances and not the source of the error.

Remedies

Systems engineers should be aware of cognitive biases of the stakeholders, as well as of their own. They should be aware of the fact that rational arguments are irrelevant to real decision-making and that the decisions are influenced by interests of the stakeholders. When considering management or design options, they should look for interests and situations that might result in sub-optimal decisions.

The Guide to Resilience-oriented Systems Engineering

This paper proposes the emergent science of resilience engineering as a framework to assure that the entire system has employed sufficient design features to assure that it achieves a sufficient level of functionality following a major disruption. The framework is about integrating concepts and practices of cognitive sciences in methodologies of systems engineering. It consists of stages corresponding to those of a system life cycle: system analysis, specification, design, testing, project management, project development, training and learning from incidences (safety culture).

A way to implement this framework is by a guide to Resilience-oriented Systems Engineering (ROSE), developed by Ergolight with the collaboration of the Gordon Center for Systems Engineering at the Haifa Technion in Israel.

The guide to ROSE is based on a model of resilient operation, describing common ways of preventing failures. The resilience model, in turn, relies on a failure model, describing typical ways of system failure. The resilience model describes how a fault triggers a hazard, and how a hazard escalates to an actual threat and eventually leads to an incidence. Hazards are associated with exceptional situations, and threats are associated with unexpected situations. Therefore, the primary goal of resilience assurance is to protect the system from unexpected events and situations.

The guide focuses on defining what we mean by exceptional situations and unexpected situations, and on methods for preventing, detecting and dealing with them. Situations are unexpected if they are could be expected, namely, if they are exceptional, and the system could handle them, if designed properly. Events are unexpected if they occur in exceptional situations, and the system is not designed to handle them in the exceptional situations. Based on these characteristics, the primary goal is restated as handling the system operation in exceptional situations.

Protection layers

In this paper we apply the Swiss Cheese model by Reason (Reason 1997, pp. 11-12), proposing that incidence rate can be reduced by adding defense layers, and reducing the holes that enable threats end up in incidences. The model applies to any source of hazard. However, in this paper we focus on human faults.

Validation

A preliminary version of the guide was validated using a database of 67 events, developed by a working group of the Israeli chapter of INCOSE. 96% of the events were assigned by at least one of the remedies in the guide.

Summary and Conclusions

The primary purpose of the article is to argue that systems engineering should include considerations of operational risks and means to mitigate these risks. The cognitive sciences should be among the disciplines included within the interdisciplinary nature of systems engineering and in particular within the study of decision-making and risk analysis. This article also argues that the examination of the consequences of past events and the causes should provide support for examination into the solution of these problems.

A recommended first step is the incorporation of cognitive bias as a factor in both decision analysis and risk management in systems engineering practices. The INCOSE handbook (2015, p. 115) already mentions culture as a factor in risk management.

A concise description of the framework for resilience assurance, extracted from the guide to Resilience-oriented Systems Engineering (ROSE) (2017a) is provided above. It is recommended that this concept be expanded to incorporate both the phenomenon of cognitive bias and the remedies suggested in this paper.

List of Acronyms Used in this Paper

Acronym Explanation

ATC Air Traffic Control

CAIB Columbia Accident Investigation Board

KLM Royal Dutch Airlines [translated]

STEM Science, Technology, Engineering, and Mathematics

INCOSE International Council on Systems Engineering

ITA Independent Technical Authority

NASA National Aeronautics and Space Administration

NTSB National Transportation Safety Board

ROSE Resilience-Oriented Systems Engineering

SEIT Systems Engineering and Integration Team

GAO General Accountability Office

FAA Federal Aviation Administration

IPT Integrated Product Team

MIT Massachusetts Institute of Technology

References

AlertDriving. 2017. “Human Error Accoounts for 90% of Road Accidents.” http://channel.staging.alertdriving.com/home/fleet-alert-magazine/international/human-error-accounts-90-road-accidents.

Asiana. 2017. “Asiana Airlines Flight 214.” Wikimedia Foundation, accessed 26 April.

Bainbridge, L. 1983. “Ironies of automation.” University College, accessed 26 April. http://www.bainbrdg.demon.co.uk/Papers/Ironies.html.

Baker, C. C., and A. K. Seah. 2004. “Maritime Accidents and Human Performance: the Statistical Trail.” MARTECH 2004, Singapore, September.

Blanchard, Benjamin, and Wolter J. Fabrycky. 2006. Systems Engineering and Analysis. Edited by Wolter J. Fabrycky and J. H. Mize. 4th ed, Prentise Hall International Series in Industrial and Systems Engineering. Upper Saddle River, NJ: Prentise Hall. Original edition, 1981.

Bless, H., K. Fiedler, and F Strack. 2004. Social cognition: How individuals construct social reality. Hove and New York: Psychology Press.

Casey, S. M. 1998. Set Phasers on Stun: And Other True Tales of Design, Technology, and Human Error. Santa Barbara: Aegean.

Chegg. 2015. “Definition of Cognitive Bias.” Last Modified 2015, accessed 18 October. http://www.chegg.com/homework-help/definitions/cognitive-bias-13

Conrow, Edmund H. 2003. Effective Risk Management: Some Keys to Success. Seconds ed. Reston, VA: American Institute of Aeronautics and Astronautics.

Crowder, J. A., et al,. 2016. Multidisciplinary Systems Engineering. Switzerland: Springer International Publishing.

Defense Acquisition University. 2010. Defense Acquisition Guidebook (DAG). Ft. Belvoir, VA: Department of Defense (DoD).

Dekker, Sidney. 2007. Just Culture: Balancing Safety and Accountability. Farnham, Surrey, UK: Ashgate.

Harel, A. 2017a. “Guide to Resilience-Oriented Systems Engineering (ROSE).” Ergolight, accessed 26 April. http://resilience.har-el.com/Guide/index.htm.

Harel, Avi. 2017b. “The Risk of Shortcuts.” Ergolight, accessed 26 April. http://resilience.har-el.com/Guide/Terms/Shortcut/index.htm.

Haselton, Martie G., Daniel Nettle, and Paul w. Andrews. 2005. “The Evolution of Cognitive Bias.” In Handbook of Psychology.

Hollnagel, Erik. 2003. “Position Paper.” Conference on Human Error, Bellagio, Italy.

Huettel, Scott. 2014. Behavioral Economics: When Psychology and Economics Collide: Course Guidebook, Business and Economics. Chantilly, Virginia: The Teaching Company.

INCOSE. 2015. Systems Engineering Handbook. edited by SE Handbook WG. Seattle, CA: International Council on Systems Engineering.

Jackson, Scott. 2010. Architecting Resilient Systems: Accident Avoidance and Survival and Recovery from Disruptions. Edited by Andrew P. Sage, Wiley Series in Systems Engineering and Management. Hoboken, NJ, USA: John Wiley & Sons.

Kariuki, Gitahi, and Katherina Löwe. 2004. Incorporation of Human Factors in the Design Process. Berlin: Institute for Plant and Process Technology, Process Safety and Plant Technology.

Leveson, Nancy, Nicolas Dulac, David Zipkin, Cutcher-Gershenfeld, John Carroll, and Berry Barrett. 2006. “Engineering Resilience into Safety-Critical Systems.” In Resilience Engineering: Concepts and Precepts, edited by Erik Hollnagel, David D. Woods and Nancy Leveson. Aldershot, UK: Ashgate Publishing Limited.

McCreary, John, Michael Pollard, Kenneth Stevenson, and Mark B Wilson. 1998. “Human Factors: Tenerife Revisited.” Journal of Air Transportation World Wide 3 (1).

NASA. 2003. Columbia Accident Investigation Report. edited by Robert Godwin. Washington, DC: National Aeronautics and Space Administration (NASA).

Nobel Prize. 2002. “The Sveriges Riksbank Prize in Economic Sciences in Memory of Alfred Nobel 2002.” The Nobel Foundatino, accessed 20 February.

Norman, D. A. 1981. The truth about Unix: The user interface is horrid. Charlottesville, VA: Datamation.

Norman, D. A. . 1983. Design rules based on analyses of human error. . In Communications of the ACM: ACM.

NTSB. 2010. “CREW Actions and Safety Equipment Credited with Saving Lives in US Airways 1549 Hudson River Ditching, NTSB Says.” National Transportation Safety Board (NTSB), accessed 26 April. https://www.ntsb.gov/news/press-releases/Pages/CREW_Actions_and_Safety_Equipment_Credited_with_Saving_Lives_in_US_Airways_1549_Hudson_River_Ditching_NTSB_Says.aspx.

Orasanu, Judith M., and Michael G. Shafto. 2009. “Designing for Cognitive Task Performance.” In Handbook of Systems Engineering and Management, edited by Andrew Sage and William B. Rouse, 691-721. Hoboken, NJ: Wiley.

Oxford. 2017. “Definition of Psychology.” Oxford University Press, accessed 19 February. https://en.oxforddictionaries.com/definition/psychology.

Pariès, Jean. 2011. “Lessons from the Hudson.” In Resilience Engineering in Practice: A Guidebook, edited by Erik Hollnagel, Jean Pariès, David D. Woods and John Wreathhall. Farnham, Surrey: Ashgate Publishing Limited.

Patterson, F. G., Jr. 2009. “Systems Engineering Life Cycles: Life Cycles for Research, Development, Test, and Evaluation; Acquisition; and Planning and Marketing.” In Handbook of Systems Engineering and Management, edited by Andrew Sage and William B. Rouse. Hoboken, NJ: Wiley.

PlaneCreashInfo. 2014. “Statistics of Fatal Aircraft Accidents.” PlaneCrashInfo, accessed 25 April. http://www.planecrashinfo.com/cause.htm.

Plouse, Scott. 1993. “The Psychology of Judgment and Decision-Making, Series in Social Psychology.” New Aster: McGraw-Hill.

Prümper, Jochen, Dieter Zapf, Felix C. Broadbeck, and Michael Frese. 2007. “Some surprising differences between novice and expert errors in computerized office work.” Giessen, Germany: University of Giessen.

Reason, James. 1997. “Managing the Risks of Organisational Accidents.” Aldershot, UK: Ashgate Publishing Limited.

Shenhar, Aaron J., and Brian Sauser. 2009. “Systems Engineering Management: The Multidiscipline Discipline.” In Handbook of Systems Engineering and Management, edited by Andrew Sage and William B. Rouse. Hoboken, NJ: Wiley.

Shneiderman, B. 1980. “Software Psychology: Human factors in computer and information systems, Winthrop computer systems.” New York: Springer.

Smidts, A. 1990. “Decision-Making Under Risk: A Study of Models and Measurement Procedures with Special Reference to the Farmer’s Marketing Behaviour.” (Wageningen Econ) Wageningen Econ. Canberra: Unipub.

Tacitus. 2007. “Tacitus Histories II.” Edited by Rhiannon Ash. Vol. 2. Cambridge: Cambridge University.

Taleb, Nassim Nicolas. 2010. “The Black Swan: The Impact of the Highly Improbable.” Random House.

Tierney, Kathleen J. 2014. “Social Roots of Risk: Producing Disasters, Promoting Resilience.” Stanford, California: Stanford University Press.

Vaughn, Diane 1997. “The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA.” Chicago: University of Chicago Press. Original edition, 1996.

Weick, Karl E., and Kathleen M. Sutcliffe. 2001. “Managing the Unexpected: Assuring High Performance in an Age of Complexity.” San Francisco: Jossey-Bass.

Weinberg, G. 1971. “The psychology of computer programming.” London: Dorset House.

WorkCover Queensland. 2017. “Safety climate and safety culture.” Government of Queensland, accessed 26 April. https://www.worksafe.qld.gov.au/safety-leadership-at-work/tools-and-resources/safety-climate-and-safety-culture.

Zonnenshain, A., and A. Harel. 2015. “A practical guide to assuring the system resilience to operational errors.” IS 2015.

Article

Getting at the Rest of the Communication Iceberg

Ronald G. Ross

$C:\Users\Ralph\Pictures\INCOSE and SyEN\Iceberg.jpg$

Image Credit

In many respects professionals in our field have a very a limited view of communication. Yes, of course we need to close communication gaps on every project, and among all stakeholders, and with IT. Though never easy, working to close those kinds of communication gaps should be a given.

Instead, we need to talk about a broader kind of communication – the communication of operational business knowledge over time and space. That requires some engineering. Let me put this challenge into perspective.

I recently read an interesting post in social media by Angela Wick about user stories and their role in agile and other requirements methodologies. The post depicted the role of user stories in creating shared understanding as addressing only the tip of an iceberg.^[1] Most of the iceberg of lies in all the hidden detail below the waterline.

Many agile gurus describe a user story as a placeholder for a conversation, or a promise of a future conversation. That’s a great characterization because it highlights the crucial point that user stories address only the 10% that you can ‘see’ above the requirements waterline. Over time, each user story must be fully explored and all the hidden detail, the submerged 90%, filled in.

The crucial question is what does all that hidden detail represent? A very sizable portion, certainly far more than half, is operational business knowledge – in other words, business rules.

Once you get that point, a next question naturally arises. Do you really want business analysts and system developers to re-invent and re-specify and re-design all that knowledge from scratch on each new project?! No! There’s nothing agile about that whatsoever (!). That’s simply re-inventing the wheel – over and over and over again.

We have clients telling us that they have achieved proven savings of 75% or more by having relevant business rules available before a project starts.

Pre-existing business rules allows project sponsors to launch projects on the basis of known facts rather than guesswork. It can reduce the difficulty of a project by an order of magnitude and improve the chances of success dramatically.

You should want – actually you should demand – ready-to-reuse, fingertip business rules for projects.

That’s where over-time-and-space communication comes to play. Ready-to-reuse, fingertip business rules represent communication of operational business knowledge across organizational boundaries and through the passage of time.

User Stories: You Don’t Have to Be Agile to Use Them! by Angela Wick, http://www.batimes.com/angela-wick/user-stories-you-don-t-have-to-be-agile-to-use-them.html

©Business Rule Solutions, LLC. 2017. Reprinted with permission by Systems Engineering Newsletter.

ARTICLE

Integrating Program Management

and

Systems Engineering

Ralph Young

In the April 2017 issue of SyEN, we reported on the publication of a new book, Integrating Program Management and Systems Engineering, a collaboration of the Project Management Institute (PMI), INCOSE, and the Consortium for Engineering Program Excellence (CEPE) at the Massachusetts Institute of Technology (MIT), that was five years in research, preparation, and writing. We indicated that “the book” is exceptionally well done and that it has the potential to enable a great leap forward in the performance of program management and systems engineering.

In the June issue of SyEN, we provided a detailed description of the book. We also provided a link to a table that identifies 32 factors and describes how they differ between Less Successful Approaches and a Superior Approach. We indicated that we plan to provide a series of articles to be provided in the next several issues of SyEN. Our intent in doing this is to support the systems engineering profession, especially subscribers of SyEN, in taking advantage of the opportunities available to further strengthen and improve the professions of program management and systems engineering. We hope that some will become strong advocates of an integrated approach and participate actively in various efforts to provide advocacy.

One of the many contributions of the book is the rich set of references identified during the research as well as studies made by the collaboration of PMI, INCOSE, and CEPE to investigate the questions posed by the research. This collaboration was called the PMI/INCOSE/MIT Alliance Team. This group helped to design the vision for the book, helped organize and enable the research activities that supported the knowledge base for the book, organized the dissemination of findings at conferences and other venues, and assisted with development and publication.

The challenge that was identified by PMI and INCOSE in 2011 was:

While program management has overall program accountability and systems engineering has accountability for the technical and systems elements of programs, some systems engineers and program managers have developed the mindset that their work activities are separate from each other rather than part of the organic whole.^[2]

The collaboration conducted a series of studies over three years, exploring the following questions:^[3]

How integrated were the practices, tools, and approaches used by chief systems engineers and program managers? Did critical links exist where they were needed? Were common practices, such as risk management, managed in intersecting or parallel paths? Were practices, tools, and approaches evaluated and benchmarked to identify opportunities for improvement?
How formalized were the roles, responsibilities, and competencies of each discipline? Did each discipline perform unique functions or were there functions that both disciplines performed?
How well did the chief systems engineer and program manager collaborate with each other? Did any tension exist in their relationship and, if so, how did that tension affect their ability to work together?
In organizations with strongly integrated practices and low levels of interdisciplinary tension, what distinguishing characteristics could be identified? How did the disciplines achieve integration and collaboration?
In organizations with weakly integrated practices and high levels of tension that affected collaboration, what distinguishing characteristics could be identified? What were the barriers to achieving integration and collaboration?
Does integration and collaboration demonstrably impact program performance?

It is our fervent hope that this series of articles will help keep this initiative alive in your mind and actions. The bottom line is that the current performance of program management and systems engineering is not sustainable; we must pursue concerted efforts toward vastly improved integration. Each of us must make changes in our daily work.

References of interest:

Oehmen, J. (Ed.). The Guide to Lean Enablers for Managing Engineering Programs. Cambridge, MA: Joint MIT-PMI-INCOSE Community of Practice on Lean in Program Management, 2012. See http://hdl.handle.net/1721.1/70495
Project Management Institute (PMI). Pulse of the Profession: The High Cost of Low Performance: How Will You Improve Business Results? See www.pmi.org/learning/pulse.aspx
International Council on Systems Engineering (INCOSE). A World in Motion: Systems Engineering Vision 2025. See http://www.incose.org/AboutSE/sevision

Next month: Summary of Chapter 1 – Toward a New Mindset

Systems Engineering News

Norway Planning the World’s First Ship Tunnel

Norway has unveiled plans to build the world’s first ship tunnel by smashing through a solid rock peninsula. The mile-long, 118-feet-wide tunnel will pass through the narrowest part of the Stad peninsula in western Norway, allowing freight and passenger ships to bypass the stormy, exposed Stadhavet Sea and avoid a highly treacherous part of the Scandinavian nation’s coastline. “The Kråkenes lighthouse, just south of Stad, is the meteorological weather station with the stormiest days, which can be anything from 45 to 106 days per year,” says the Norwegian Coastal Administration. The very high waves coming from different directions create complex and perilous sailing conditions, even after the wind has died down. “The combination of wind, currents and waves around this part of the coastline make this section a particularly demanding part of the Norwegian coast,” the administration says. It says it hopes the tunnel will improve safety and stop ships from having to wait for bad weather to pass. The team anticipates it will take three to four years to build the tunnel and cost an estimated $315 million. To create it engineers will have to blast out a huge eight million tons of rock. Passages and canals for boats have been built elsewhere in the world, but this will be the first tunnel allowing cruise and freight ships that weigh up to 16,000 tons to pass through solid rock. The team anticipates that up to five ships will be able to pass through the tunnel every hour. If you’re wondering what might happen if two ships come nose-to-nose, it’s unlikely, because there will be traffic lights. “We are going to follow the usual standard with red and white lights to show when it is safe to pass,” the team says. The tunnel is due to open in 2023.

More information

IEEE Systems Council: Call for Interest, Human System Integration Technical Committee

The IEEE Systems Council is considering forming a new committee on Human System Integration (HSI). This committee would focus on identifying and improving methods to integrate human concerns into the conceptualization and design of systems. HSI encourages early understanding of human roles and responsibilities, along with limitations and constraints that may impact system design.

The importance of this topic is apparent from notable design errors, i.e., the placement of the iPhone 4 antenna resulting in poor performance when holding the phone, to design successes, for example, the Xbox Kinect that allowed users to interact with the game system without a hand-held interface.

One of the goals of the committee is to improve communication between the human factors and engineering communities to provide better integration of human and systems and early resolution of issues based on human constraints and limitations.

Interested in finding out more? Or participating on the committee? Please contact: Holly A. H. Handley (hhandley@odu.edu)

Can Frontline Workers Stay on the Frontline and Still Make Systems Change?

$C:\Users\Ralph\Pictures\For SyEN\Systems Picture.png$

Frontline workers can make systems change because they are a vital part of the system. If frontline workers were listened to more often, alongside other excluded voices, the strength of the sector’s collaboration and creativity in innovation would improve. Frontline workers hold a part of the solution to the challenges in our clunky and at times ineffective systems, therefore if we create solutions without them, we end up with a solution that addresses only the part, not the whole. But, let’s be real. This is going to be hard because it takes time and necessitates the creation of new work-cultures across sectors. I was told once that it wouldn’t be possible – I disagree. It is possible, and it is systems changing, but it is hard work that has to be intentionally done and embedded in current practices. It will then continue naturally and with increasing ease. More than a year on from the completion of my systems changers experience, I am still as convinced as ever of its promise of change and would encourage everyone to get stuck in to doing things differently and to not be afraid to try things. I think you will be surprised at the change that happens.

More information

Aerospace Looks to Robotic Systems as Orders Backlog Grows

The trade body Aerospace, Defense, Security and Space (ADS) announced on May 30, 2017 that the worldwide backlog of aircraft orders stands at over 13,300, which is the fifth highest level recorded. A report from Markets and Markets shows that the aerospace robotics market is projected to grow from $1.81bn in 2016 to $4.54bn by 2022, at a compound annual growth rate of 16.55 per cent. Increasing use of robots for efficient aircraft production, growing use of robotics to handle aircraft order backlogs, and increasing labor costs are factors identified in the report as driving the aerospace robotics market. According to Professor Guang-Zhong Yang, Chair of the Engineering and Physical Sciences Research Council (EPSRC) UK, Robotics and Autonomous Systems (RAS) Network, Robotics Week will feature four Challenges:

Robotics for Social Care and Independent Living – showcasing how robots can be integrated into the healthcare services of the future in order to help address the predicted steeply rising costs and strain of healthcare provision and services in the UK.
Robotics for Surgery and Global Health: from Macro to Micro – the aim of this challenge is to create new concepts for affordable systems especially with potential for applications in the developing world.
Robotics for Emergency Response, Disaster Relief and Resilience – this challenge is to build robust emergency response systems that can be exploited in extreme environments, such as in collapsed buildings following an earthquake or terrorist attacks, and in Polar Regions for monitoring indicators of climate change.
Robotics for Resilient Infrastructure – demonstrating RAS capabilities in scenarios for inspection, repair and maintenance of critical infrastructures, including nuclear, offshore energy, space, civil infrastructure, transport (rail, road, sea).

More information

Outdated Operating Systems, Browsers Correlate with Real Data Breaches

Organizations that run more than half of their computers on outdated operating systems are three times more likely to suffer a data breach, while those running more than half of their browsers on old versions are twice as likely to get hit with a breach.

More information

The Composable Systems Wave Is Rising

Hardware is, by its very nature, physical, and therefore, unlike software or virtual hardware and software routines, encoded by Field-Programmable Gate Arrays (FPGA), it is the one thing that cannot be easily changed. The dream of composable systems, is something that has been swirling around in the heads of system architects for more than a decade. (Composable infrastructure means breaking apart the key components of the system – CPU, memory, I/O, and storage – from each other so they can be changed independently of each other). We are without question getting closer to realizing the dream of making the components of systems and the clusters that are created from them programmable like software.

The hyperscalers have been on the bleeding edge of trying to make hardware composable and malleable. (Hyperscale computing is a distributed computing environment in which the volume of data and the demand for certain types of workloads can increase exponentially yet still be accommodated quickly in a cost-effective manner). But the advent of fast Peripheral Component Interconnect (PCI) -Express switching and fast and affordable silicon photonics links between system components is going to smash the server to put it back together again. Cisco Systems was way out front with composable systems with its UCS M-Series, which it discontinued last year, and Hewlett Packard Enterprise is banking on its “Project Thunderbird” Synergy composable infrastructure to give it an edge in systems that it needs to revitalize its IT business and provide some differentiation. A3Cube came up with an extension to PCI-Express that allowed it to create a compute and storage fabric that was somewhat malleable, and PLX Technologies, now part of Broadcom, had some extensions as well. But with the CCIX and Gen z protocols and updated PCI-Express 4.0 and then 5.0 coming out, we should expect to see row-scale clusters of systems that are less rigid than the systems and clusters we are used to.

More information

Call for Nominations – 2017 INCOSE Elections

As the 2017 International Symposium approaches, the INCOSE Nominations & Elections Committee continues to identify candidates for this year’s election. Nominations remain open until September 15, but solidifying candidates before the symposium provides additional time and opportunity to learn about those interested in helping to lead our organization forward.

They need your help identifying the right individuals to serve on INCOSE’s Board of Directors – individuals with energy, insight, and commitment to serve at the international level. This year, INCOSE members will be electing the next President-Elect, Treasurer, Chief Information Officer, and Director for Outreach. In addition, chapter presidents in the Asia Oceania sector will nominate candidates and elect the Director for Asia Oceania.

Nominations – including self-nominations – may be made by any INCOSE member. For more information on these positions, nominating a candidate, or the 2017 elections, please visit the nominations page.

Featured Organizations

Society for Engineering and Management Systems (SEMS)

The Society for Engineering and Management Systems (SEMS) is the society within the Institute of Industrial and Systems Engineers (IISE) that particularly supports IISE members as they seek to advance the state of engineering management practice and research. Besides advanced engineering skills, SEMS stimulates discussion and knowledge exchange related to management domains that are critical to advance your career, whether as an academic or a practitioner.

Mission

Research, develop, and promote engineering and management systems that support organizational transformation, increase competitiveness, and improve sustainability and social responsibility.

Tools and Resources

Search by Category

Find material related to your interests by choosing among numerous engineering management topics:

Strategy

Decision-Making

Resource Management

Systems Thinking

Organization Development & Change

Improvement Strategies

Product Development & Project Management

Special Topics

Simulation

Simulation

Emerging Topics

Green and Sustainability

More information

INCOSE Requirements Working Group

Louis S. Wheatcraft

louw@reqexperts.com

Requirements Experts, Inc.

www.reqexperts.com

Purpose: The purpose of the Requirements Working Group (RWG) is to advance the practices, education, and theory of requirements development and management and the relationship of requirements to other systems engineering functions.

Goal: Expand and promote the body of knowledge of requirements and its benefits within the systems engineering community.

Scope: Activities relating to best practices for requirements development and management throughout the product lifecycle including:

Elicitation
Elaboration
Expression
Analysis
Management
Verification and Validation

Working Group Officers (as of 1 August):

Chair: Lou Wheatcraft, Requirements Experts, USA
Co-Chair: Mike Ryan, University of New South Wales in Canberra, Australia
Co-Chair: Kathy Baksa, Pratt & Whitney, USA
Co-Chair: Rick Zinni, Harris Corporation, USA
Co-Chair: Jeremy Dick, Synthesys, UK
Co-Chair: Jason Baker, Transocean, Deepwater, USA

Membership:

The RWG is the largest WG in INCOSE with over 370 members.

Major Products:

“INCOSE Guide to Writing Requirements”
Contributions to the requirement-related portions of the INCOSE SE Handbook and Systems Engineering Book of Knowledge (SEBoK)
INCOSE document (new draft) “Integrated Data as the Foundation of Systems Engineering”
RWG Connect website: https://connect.incose.org/WorkingGroups/Requirements/Pages/Home.aspx
Web tutorials (recorded webinars) on the “INCOSE Guide to Writing Requirements”

Upcoming Events:

Members will be attending IS2017 in Australia in July
Members will be presenting several papers at IS2017
An update to “INCOSE Guide to Writing Requirements” is through final review and will be released in time for IS2017
A draft of “Integrated Data as the Foundation of Systems Engineering” is in the INCOSE review cycle for release prior to IW2018
A new product, “Model-based Requirement Development and Management” is being planned. Several papers on the basic concepts are in development for presentation at IS2018. A draft of the document will be available in time for IW2018 and will be a focus of the RWG meetings at IW2018.
The RWG is working with the Oil & Gas WG to address specific requirement development and management issues within the Oil & Gas industry. As part of these efforts a general “State of RDM” questionnaire has been developed. The questionnaire is available at: https://www.surveymonkey.com/r/INCOSE-OandG-Survey

Requirement Working Group on-going activities:

Meet at International Workshop
Meet virtually via telecom
Maintain its work products
Recruit champions to lead activities
Carry out assignments outside of meetings
Use INCOSE RWG discussion groups to achieve working group consensus
Promote RWG membership collaboration with other INCOSE working groups, other professional societies, commercial and industry committees, government organizations, and academic institutions
Communicate to RWG members and interested INCOSE members via
- RWG website
- RWG threaded discussions
Provide INCOSE tutorials and webinars

RWG sessions at INCOSE IW 2017 in Torrance, CA

The RWG had a full agenda for the INCOSE International Workshop (IW) 2017 that was held in January 28-31, 2017 in Torrance, CA. Our focus was on two topics. First, an update to the “INCOSE Guide to Writing Requirements.” The second topic was to walk through a draft of a new document we are proposing: “Integrated Data as the Foundation of Systems Engineering”. Below is a summary of each document. Members of INCOSE RWG may view drafts of the following documents on the INCOSE CONNECT Requirements website under IW2017 document heading.

Guide to Writing Requirements

The Guide to Writing Requirements was first released in 2012, with a major update in 2015. Since then our thinking has matured so we have made updates to the Guide based on new work we have done, discussions at IW2016, and comments received. Prior to IW2017 we developed a list of suggestions for future improvement for the Guide. During IW2017 we discussed the changes made and decided on which of the suggestions we plan to pursue in the next update and which ones we will address in a subsequent update. The current version of the Guide to Writing Requirements is available to all INCOSE members via the INCOSE store. It is the RWG goal to have the revised Guide available for the International Symposium (IS2017) held in Australia in July 2017.

Purpose: The Guide is specifically about how to express textual requirements in the context of systems engineering. The aim is to draw together advice from existing standards such as ISO 29148 and the authors and reviewers into a single, comprehensive set of characteristics, rules, and attributes.

The Guide focuses on the characteristics that must be possessed by well-formed requirement statements and sets of requirements, and a set of rules for writing requirement statements that, if followed, will result in the requirements having these characteristics. The guide includes a set of attributes that can be included with the requirement statements to form a complete requirement expression (the distinction between a requirement statement and a requirement expression is discussed in Section 1.6). Finally, the guide also addresses the concept of boilerplates, templates, or patterns for requirement statements. (Dick, J. and Llorens, J., “Using Statement-level Templates to Improve the Quality of Requirements”, International Conference on Software and Systems Engineering and Applications. ICSSEA 2012, Paris, France).

Audience: The Guide is intended for those whose role it is to write, review, and manage textual requirements throughout the system development life cycle processes, and as well as those who read, implement, and verify that the developed system meets the requirements.

Definitions: The Guide includes several key definitions:

An entity is a single thing to which a need or requirement refers: an enterprise, business unit, system, or system element (which could be a product, process, human, or organization).

A need is the result of a formal transformation of one or more concepts into an agreed-to expectation for an entity to perform some function or possess some quality (within specified constraints).

A requirement statement is the result of a formal transformation of one or more needs into an agreed-to obligation for an entity to perform some function or possess some quality (within specified constraints).

A requirement expression includes a requirement statement and a set of associated attributes.

An attribute is additional information included with a requirement statement, which is used to aid in the management of that requirement.

A set of requirements is a structured set of agreed-to requirement expressions for the entity and its external interfaces documented in an Entity (Enterprise/Business Unit/System/System Element/Process) Requirements Specification (Document).

The following diagram shows the relationship of each of the terms defied in the Guide.

Based on the above definitions, characteristics of well-formed requirements and requirement sets were defined.

Well-formed requirements have the following characteristics:

Formal Transformation. Including this term in the definition makes it clear that a requirement is the result of engineering analysis using one or more of the methods discussed earlier. For each “need” the Requirements Engineer (RE) or Business Analyst (BA) asks: What does the entity have to do or what characteristic must it possess in order for the need to be realized? Engineering analysis results in one or more requirements. Given the requirement is a result of a formal transformation, the following characteristics of a well-formed requirement have been derived:

o Necessary

o Singular

o Conforming

o Appropriate

o Correct

Agreed-to Obligation. Including this aspect in the definition makes it clear that, before a requirement is valid, both the customer and provider must agree with the requirement statement. Note: we are using the term “customer” to refer to the entity requesting a work product. The customer may be internal or external to the enterprise. Many people may want to levy requirements on a system, but until that requirement is formally agreed-to and is part of a contract (in this Guide, “contract” refers to the acquirer-supplier relationship, as discussed at the end of this section), it is not a valid system requirement. Since the requirement is to be a part of a fair agreement to meet an obligation, the following characteristics of a requirement have been derived.
- Unambiguous
- Complete
- Feasible
- Verifiable

A well-formed set of requirements has the following characteristics:

Formal Transformation. As the set of requirements is the result of a formal transformation, the following characteristics of the requirement set have been derived:
- Complete
- Consistent
Agreed-to Obligation. Since the set of requirements is to be a result of a fair agreement to meet an obligation, the following characteristics of the set have been derived:
- Feasible
- Comprehensible
- Able to be validated

Organization: The guide is organized as follows:

Section 1.0 describes key concepts, includes the above definitions, and discusses what the terms verification and validation mean.

Section 2.0 defines the characteristics of individual requirement statements, provides rationale for the characteristics, and provides guidance for helping understand the characteristics.

Section 3.0 defines the characteristics of sets of requirements, provides rationale for the characteristics, and provides guidance for helping understand the characteristics. Each characteristic is traced to the rules that, when met, help the writer ensure the requirement has that characteristic.

Section 4.0 defines the rules for individual requirement statements and sets of requirements that help to formulate requirement statements and sets of requirements. Included with each rule is an explanation of the rule and examples of the application of the rule. Each rule traces to the characteristics it helps to achieve.

Section 5.0 defines attributes that can be attached to requirement statements to form requirement expressions. Also included is guidance on the use of attributes. Where applicable, the attributes trace to the characteristic or rule it helps to achieve.

Appendix A lists acronyms and abbreviations used in this document.

Appendix B defines the concept of requirement patterns and lists examples of patterns that can be used for different types of requirement statements.

Integrated Data as a Foundation to Systems Engineering

“Integrated Data as the Foundation to Systems Engineering” is a new document developed by the RWG. This document is an outgrowth from discussions concerning the integration of the Model-Based Systems Engineering (MBSE) Initiative into RWG activities that occurred within the Requirements Working Group (RWG) sessions during INCOSE IW 2016 and IW2017 and subsequent communications between the authors, members of the RWG, and members of other INCOSE Working Groups. This document is currently in draft form and has been submitted to the INCOSE review and approval process. We are not sure how long this process will take. Our goal is to have it published in time for INCOSE IW 2018, in January 2018.

The RWG is producing this Guide from the perspective that requirements, along with all artifacts (including models) generated during the performance of System Engineering (SE) process activities are represented by datasets that must be linked together and integrated across all SE life cycle processes in to a common dataset. When this linking and integration is done, there are many key benefits that will aid organizations in successfully meeting the challenges associated with today’s ever increasingly complex systems, meeting the intent of the MBSE Initiative, and achieving INCOSE’s Vision 2015. Using this perspective, the common, integrated dataset is the foundation for Systems Engineering.

The basic premise of this document is that Systems Engineering (SE) is based on models, models are represented by data and information, and other Systems Engineering (SE) artifacts are either projections of the same data and information or represented by data and information generated from other SE life cycle process activities. To effectively manage ever increasing complex systems of the future, this underlying data and information must be integrated into a common, project dataset. This dataset not only represents an integrated architectural model of the system under development, but also a model of the SE life cycle process activities and resulting work products that can be used to more effectively manage the system development efforts across all SE life cycle stages.

The SE tools used to generate and manage the various SE work products and underlying data and information provide context. This context results in information. This information represents an information model of the system being developed as well as provides valuable rationale and insights developed while executing the SE life cycle processes involved in engineering the system. In practicing SE, the systems engineer’s emphasis needs to be on the data and information shared across life cycle processes rather than on the individual life cycle process activities themselves. Combining the systems engineer’s experience and knowledge with the information contained in the integrated dataset enables the systems engineer to use their wisdom to successfully deliver winning products – products that deliver what is needed, within cost and schedule, with the desired quality. Accepting this premise, it is useful to view SE from a data-centric perspective.

The practice of SE is often viewed from many perspectives. Similar to the old story of the blind men and the elephant, SE cannot be effectively practiced when viewed from just one perspective (requirements, models, patterns, standards, industry specific application, etc.). To successfully practice SE, wise systems engineers recognize and use each perspective as appropriate to the activity they are performing. The perspective of this document addresses the intent of the MBSE Initiative by presenting a broader, data-centric view of SE. From this perspective, modeling and other activities and SE are not synonymous. There are many work products, including models, which are generated during the execution of the SE life cycle process activities.

The authors feel this data-centric perspective of SE provides a better lens through which to acquire a complete understanding of the SE life cycle process activities and resulting work products and underlying data and information needed to manage the development of increasingly complex systems of the future. This perspective aids in acquiring a practical understanding of the SE life cycle processes from the perspective of not only models, but all work products that are generated from activities conducted during each of the SE life cycle processes and the underlying data and information used to represent these work products.

Expanding on the concept of SE from a data-centric perspective, the goals of this document are to:

Present a broader data-centric perspective of SE that meets the intent the MBSE initiative and helps organizations move towards INCOSE’s Vision 2025
Provide organizations an understanding that the integrated dataset is the foundation of SE
Provide organizations guidance that can be used to successfully implement SE from a data-centric perspective

The overall goal is to make this document a useful product to help organizations implement the level of SE capability that best fits their needs.

Audience: The intended audience of this document includes project and product managers and systems engineers who are stakeholders in activities defined by the SE discipline and are thinking about, or are in the process of, implementing SE within their organization. This guide will help those who are wondering how to successfully implement the intent of the MBSE Initiative within their organization and those that are interested in maturing their current SE capabilities toward a more data-centric implementation of SE – irrespective of the size and complexity of the system under development and the size and culture of the organization developing the system.

From a requirements perspective, this guide is also targeted to those who have been, or are currently, focused on defining, documenting, and managing requirements as a distinct and separate, stove-piped activity from other SE life cycle processes. From a tool vendor perspective, this guide is targeted towards those whose tools do not provide the capability to integrate requirements and the other work products and their underlying data and information across all SE life cycle process activities. While these approaches may have worked in the past and may work for some present system development efforts, it is doubtful these approaches will allow organizations to meet the future challenges of increasingly complex systems and move towards INCOSE’s Vision 2025.

Organization: This Document Is Organized as follows:

Section 1.0 discusses the purpose and scope of the document, the intended audience, and organization of the document.

Section 2.0 addresses the need for SE and the benefits of adopting SE from a data-centric perspective. A list of challenges that need to be addressed due to the increasingly complex systems is presented followed by a list of benefits organizations can realize by practicing SE from a data-centric perspective. Another advantage to practicing SE from a data-centric perspective is that it enables the use of measures to help better manage the system develop activities.

Section 3.0 introduces and defines the concept of integrated data as the foundation of SE. The section starts out discussing the SE artifacts that are generated as part of each of the SE life cycle activities. Next the questions: What is a model? And what is model-based SE (MBSE0), are addressed from a data-centric perspective. The concept of integrated data as a foundation for SE is discussed along with a definition of SE from a data-centric perspective.

Section 4.0 provides guidance that can be used to understand and successfully create and manage the integrated data set within an organization. This section starts out with a discussion concerning the need for corporate buy in and support to transition the organization to practicing SE from a data-centric perspective. The key concepts from big data are introduced including: data governance, information technology, and data management. Next, a description is given concerning the current state of most organizations concerning forming an integrated dataset for the project, and the path of moving from the current state to an integrated dataset state. To aid in this journey, SE Capability Levels (SCLs) were presented to help organizations access what their current SE capability is from an integrated dataset perspective and provide a roadmap to get to their desired level of capability based on their organizations specific needs. The final topic in this section provides advice to help sell the idea of moving toward an integrated dataset practice of SE. Questionnaires are provided to help organizations assess their current capability level and identify issues they may be having which can be addressed be practicing SE from a data-centric perspective.

The following diagram was developed by the RWG at IW2017 to summarize the end state envisioned once an organization has transformed their practice to SE from a data-centric perspective with all SE life cycle activities managed via a common, integrated dataset.

About the author:

Lou Wheatcraft is a senior instructor/consultant for Requirements Experts (RE) which educates organizations on the importance of writing good requirements and helps them implement Requirement Development and Management (RD&M) processes based on industry best practices. Lou has taught over 190 requirements seminars over the last 17 years. Lou works with both government and industry clients. Lou has spoken at Project Management Institute (PMI) chapter meetings, INCOSE conferences and chapter meetings. Lou has had published and presented a multitude of papers on requirement RD&M topics for NASA’s PM Challenge, INCOSE, INCOSE INSIGHT Magazine, and Crosstalk Magazine. Lou is a member of INCOSE, co-chair of the INCOSE Requirements Working Group, a member of PMI, the Software Engineering Institute (SEI), the World Futures Society, and the National Honor Society of Pi Alpha Alpha. Lou has a BS degree in Electrical Engineering from Oklahoma State University, an MA degree in Computer Information Systems from the University of Houston – Clear Lake, an MS degree in Environmental Management from the University of Houston – Clear Lake, and has completed the course work for an MS degree in Studies of the Future from the University of Houston – Clear Lake. Lou is the primary contributor to RE’s blog on requirements best practices. The blog can be assessed at: http://www.reqexperts.com/blog.

Conferences and Meetings

For more information on systems engineering-related conferences and meetings, please proceed to www.ppi-int.com

Some Systems Engineering-Relevant Websites

Requirements Techniques

Know what requirements techniques to use

www.requirementstechniques.com/

Facilitating Projects

Appearances, Resources and Links, Tools and Templates

www.facilitatingprojects.com/

Systems Engineering Publications

Leading Change

$C:\Users\Ralph\Pictures\For SyEN\Kotter_LeadingChange_.jpg$

Image source

by John P. Kotter

Book Description (from the Amazon website):

Harvard Business School professor Kotter (A Force for Change) breaks from the mold of M.B.A. jargon-filled texts to produce a truly accessible, clear and visionary guide to the business world’s buzzword: change. In this excellent business manual, Kotter emphasizes a comprehensive eight-step framework that can be followed by executives at all levels. Kotter advises those who would implement change to foster a sense of urgency within the organization. “A higher rate of urgency does not imply ever-present panic, anxiety, or fear. It means a state in which complacency is virtually absent.” Twenty-first century business change must overcome over-managed and under-led cultures. “Because management deals mostly with the status quo and leadership deals mostly with change, we are going to have to become much more skilled at creating leaders.” Kotter also identifies pitfalls to be avoided, like “big egos and snakes” or personalities that can undermine a successful change effort. Kotter convincingly argues for the promotion and recognition of teams rather than individuals. He aptly concludes with an emphasis on lifelong learning. “In an ever-changing world, you never learn it all, even if you keep growing into your ’90s.” Leading Change is a useful tool for everyone from business students preparing to enter the work force to middle and senior executives faced with the widespread transformation in the corporate world.

More information

The International Journal of Project Management

“Systems Engineering to Improve Governance in Complex Project Environments”

Volume 32, Issue 8, November 2014, Pages 1395–1410

$C:\Users\Ralph\Pictures\For SyEN\International Journal of .gif$

Image source

by Giorgio Locatelli, Mauro Mancini, and Erika Romano

Book Description (from the Amazon website):

The International Journal of Project Management offers wide ranging and comprehensive coverage of all facets of project management. Published eight times per year, it provides a focus for worldwide expertise in the required techniques, practices and areas of research; presents a forum for its readers to share common experiences across the full range of industries and technologies in which project management is used; covers all areas of project management from systems to human aspects; links theory with practice by publishing case studies and covering the latest important issues. Application areas include: information systems, strategic planning, research and development, system design and implementation, engineering and construction projects, finance, leisure projects, communications, defense, agricultural projects, major re-structuring and new product development. Papers originate from all over the world and are fully peer-reviewed, on the ‘double-blind’ system. In addition, the journal carries conference reports, and book reviews. The journal is published in collaboration with the Association for Project Management (APM) and the International Project Management Association (IPMA) and is their official journal.

This paper presents systems engineering tools and techniques focusing, in particular, on those most relevant for project management, project governance, and stakeholder management. Projects delivered in complex environments are often late, over-budget, and provide fewer benefits than were originally expected. Systems engineering is the emerging paradigm in complex project environments to transform the governance from “project based” to “system based”, thereby increasing the probability of holistic success. Systems engineering is a multidisciplinary approach to enable the successful delivery of systems in complex environments through a comprehensive set of approaches, techniques and tools; it was initially developed in the USA after the Second World War. This paper focuses on how Systems Engineering can transform the governance from “project governance” to “system governance”, improving the performance of projects delivered in a complex environment. At the end, it provides a rich research agenda for further studies.

More information

Editor’s note: This excellent article which provides and explains these terms is available through a service called “ScienceDirect”; there is a charge of $35 US to download the PDF file.

Agile Systems Engineering

$C:\Users\Ralph\Pictures\For SyEN\AgileSE.jpg$

Image source

by Bruce Powel Douglass

Book Description (from the Amazon website):

Agile Systems Engineering presents a vision of systems engineering where precise specification of requirements, structure, and behavior meet larger concerns as such as safety, security, reliability, and performance in an agile engineering context. World-renowned author and speaker Dr. Bruce Powel Douglass incorporates agile methods and model-based systems engineering (MBSE) to define the properties of entire systems while avoiding errors that can occur when using traditional textual specifications. Dr. Douglass covers the life cycle of systems development, including requirements, analysis, design, and the handoff to specific engineering disciplines. Throughout, Dr. Douglass couples agile methods with SysML and MBSE to arm system engineers with the conceptual and methodological tools they need to avoid specification defects and improve system quality while simultaneously reducing the effort and cost of systems engineering. The author:

identifies how the concepts and techniques of agile methods can be effectively applied in systems engineering context;

shows how to perform model-based functional analysis and ties these analyses back to system requirements and stakeholder needs, and forward to system architecture and interface definition;

provides a means by which the quality and correctness of systems engineering data can be assured (before the entire system is built!);

explains agile system architectural specification and allocation of functionality to system components;

details how to transition engineering specification data to downstream engineers with no loss of fidelity; and

includes detailed examples from across industries taken through their stages, including the “Waldo” industrial exoskeleton as a complex system.

Editor’s note:

The following review of this book, published on Amazon, offers insight that will be of interest to practicing systems engineers.

Agile Systems Engineering is both an interesting and useful book for systems engineers. Bruce Douglass makes an excellent case that the combination of agile and model based systems engineering practices can help systems engineers deal with the speed and complexity of the world they face today. A couple of things stood out for me in reading this book: 1) its target audience is systems engineers; he specifically addresses specification and design at the system level with the end products being those key artifacts that are handed to discipline-specific engineers; 2) this is a book for practitioners — the book is chock-full of useful guidance such as how to incrementally define and evaluate requirements; how to develop an executable architecture; and even low level things such as how to organize a model; 3) the chapter on “Agile Systems Architectural Analysis and Trade Studies” is excellent. He clearly articulates a method and then shows its use on increasingly complex problems. In addition, the samples shown in the book are at just the right level to allow the reader to gain an understanding without being swamped in detail. It gets one’s blood flowing wanting to apply the information! This book is not a reference manual on SysML nor on agile methods. Rather it is an excellent resource for how to do systems engineering using the combination of MBSE and agility.

More information

Overcomplicated: Technology at the Limits of Comprehension

$C:\Users\Ralph\Pictures\INCOSE and SyEN\51NqIJem-KL._SX329_BO1,204,203,200_.jpg$

Image source

by Samuel Arbesman

Book Description (from the Amazon website):

In Overcomplicated, complexity scientist Samuel Arbesman offers a fresh, insightful field guide to living with complex technologies that defy human comprehension. As technology grows more complex, Arbesman argues, its behavior mimics the vagaries of the natural world more than it conforms to a mathematical model. If we are to survive and thrive in this new age, we must abandon our need for governing principles and rules and accept the chaos. By embracing and observing the freak accidents and flukes that disrupt our lives, we can gain valuable clues about how our algorithms really work. What’s more, we will become better thinkers, scientists, and innovators as a result. Lucid and energizing, this book is a vital new analysis of the world heralded as “modern” for anyone who wants to live wisely.

More information

Technology vs. Humanity: The Coming Clash between Man and Machine

$C:\Users\Ralph\Pictures\INCOSE and SyEN\41vZ90ClHoL._SX331_BO1,204,203,200_.jpg$

Image source

by Gerd Leonhard

Book Description (from the Amazon website):

Futurist Gerd Leonhard breaks new ground again by bringing together mankind’s urge to upgrade and automate everything – down to human biology itself – with our timeless quest for freedom and happiness. Before it’s too late, we must stop and ask the big questions: How do we embrace technology without becoming it? When it happens – gradually, then suddenly – the machine era will create the greatest watershed in human life on Earth. Technology vs. Humanity is one of the last moral maps we’ll get as humanity enters the Jurassic Park of Big Tech. Artificial intelligence. Cognitive computing. The Singularity. Digital obesity. Printed food. The Internet of Things. The death of privacy. The end of work-as-we-know-it, and radical longevity: The imminent clash between technology and humanity is already rushing towards us. What moral values are you prepared to stand up for – before being human alters its meaning forever? Gerd Leonhard is a new kind of futurist schooled in the humanities as much as in technology. In his most provocative book to date, he explores the exponential changes swamping our societies, providing rich insights and deep wisdom for business leaders, professionals, and anyone with decisions to make in this new era. If you take being human for granted, press reset now with this passionately argued call to create a genuinely braver new world.

More information

Systems Engineering Tools News

Innoslate by SPEC Innovations

by Alwyn Smit

Principal Consultant & Course Presenter

Project Performance International (PPI)

asmit@ppi-int.com

For this second article in our MBSE tool series, I am highlighting Innoslate by SPEC Innovations. The Systems and Proposal Engineering Company (SPEC Innovations) was established in 1993 and its business services include systems engineering services and training, proposal engineering management and training, software development, and DoDAF training and expertise.

The Innoslate MBSE tool offers a number of powerful features, including:

Modelling of complex systems:
- Life cycle Modeling Language (LML).
- Systems Modeling Language (SysML).
- Icam (Integrated Computer Aided Manufacturing) DEFinition for Function Modeling (IDEF0).
- Department of Defense Architecture Framework (DoDAF).

These diagrams are automatically generated from the model and allow for seamless translation between modeling languages.

Requirements management:
- A Requirements View that allows the user to edit and review requirements.
- “Requirements View features automatically suggested numbering on entity creation, automatically generated hierarchical relationships, filtering on entity class and labels, display of hierarchically requirements with collapsable sections, inline entity editing, gap indication, and much more.”^[4]
- Capturing requirements from other tools with an import analyzer.
- Requirements analyses using natural language processing technology.
- Requirements traceability with automatic Hierarchy Charts, Traceability Spider Diagrams, or 3D Traceability Diagrams.
- Meeting and exceeding the requirements of the INCOSE Guide for Writing Requirements.
The tool also offers real time collaboration with your team across multiple views simultaneously.
The verification and validation capability allows you to capture verification methods and test cases.
“Innoslate’s real-time ‘Discrete Event Simulator’ allows you to execute a complex system as discrete sequence of actions in time. This simulator is designed for analyzing a system or project’s cost, schedule, and performance. Innoslate’s simulation technology can be used for:
- Analyzing complex systems behavior and its parts (assets)
- Predicting system performance including time duration, cost, asset utilization, and resource consumption
- Identifying process bottlenecks
- Planning a schedule, allocating cost, asset utilization, and calculating resource performance (Project Management)
- Verifying correct logical design”^[5]
“Innoslate’s ‘Monte Carlo Simulator’ allows for realistic analysis of a system or project’s cost, schedule, and performance. This simulator utilizes the same modeling techniques and technologies of the ‘Discrete Event Simulator’ but removes inherent uncertainty. This is accomplished by running the simulation repeatedly with different, random seeds to achieve a more comprehensive view of the model.”^[6]

The Innoslate website (https://www.innoslate.com/) includes a host of how-to guides, video tutorials and a user guide where you can find a whole lot of additional detail on this tool.

What is a RACI Matrix and Why

Use this Technique?

The RACI technique focuses on clarifying what stakeholders’ roles and responsibilities are in a context of a specific task or process step. There are a number of alternative names for this technique like ARCI matrix, RACI chart, or Responsibility charting.

It classifies stakeholders according to one of the following roles for specific project activities:

Responsible: The stakeholder performs the project work activities.
Accountable: The stakeholder is accountable to the sponsor or to the customer for the result of the work activities.
Consulted: The stakeholder is asked for opinions on objectives, assumptions, constraints, or methods of planning and developing products or process due to expertise or position in the organization.
Informed: The stakeholder is notified of the outcome of project decisions.

The RACI matrix may be used:

to specify the involvement of various stakeholders in a project;
to indicate the involvement of stakeholders in a business process;
to indicate the persons involved in the creation, sign-off, and distribution of a BA artefact; and
to supplement the stakeholder power/interest analysis.

If you are looking for a template, you can download one here.

More information

Semantic Interoperability of Engineering Tools for Automation Systems Engineering

Automation systems engineering projects depend on contributions from several engineering disciplines. These contributions consist of complex artifacts like mechanical, electrical, and software components and plans. While the software tools are available for each individual engineering discipline, there is very little work on engineering process automation across semantically heterogeneous engineering tool data models. In this paper, we adapt the Engineering Knowledge Base (EKB) concept a semantic model, which extends the Global-as-View concept and explicitly models common engineering concepts and mappings using machine-understandable syntax, for the engineering of automation systems. We evaluate the concept based on a real-world use case for data exchange and consistency checking between software tools involved in automation systems engineering. The major result is that the EKB concept sufficiently supports the semantic interoperability of tools to enable the automation of engineering processes. Furthermore, the EKB provides the capability to efficiently identify defects across engineering models in several tools.

More information

Education and Academia

Industrial Engineering and Systems Engineering at Florida Tech

The mission of the department of engineering systems at the Florida Institute of Technology is to prepare engineers and scientists for leadership roles in business organizations. The educational objectives are to achieve steady enrolment growth and pursue practical funded research; to provide engineers and scientists the skills to expand their areas of responsibility in the workplace; and to update the skills of engineers and scientists in their fields of specialization.

More information

Southeast Missouri State University Launching New Engineering Program in fall 2017

Southeast Missouri State University, USA, will launch a new engineering degree program beginning with the fall 2017 semester to help meet workforce demands and offer access to students seeking STEM education opportunities in southeast Missouri. “Southeast has a long history of delivering engineering-related programs in areas such as Engineering Physics, Engineering Technology, Industrial Technology and Technology Management, in addition to a minor in Engineering Physics and Southeast’s Pre-Engineering Program,” said Dr. Carlos Vargas, president of Southeast Missouri State University. “The ability to offer this degree at Southeast will provide access to a high-skill program in a part of Missouri where some students are more place-bound due to financial constraints or familial responsibilities, and where other students are more likely to leave Missouri to pursue their education at schools in neighboring states that are closer than other institutions in Missouri. Perhaps most importantly, this program will help respond to national, state and local workforce needs.”

More information

Volgenau School of Engineering

What used to be “Northern Virginia’s best-kept secret” is now one of the country’s largest, most comprehensive schools of engineering. George Mason University is on the radar, adding new programs, attracting more top faculty and expanding vital research. Students can obtain both bachelors and master’s degrees in systems engineering in the Systems Engineering and Operations Research Department. Our close relationships with a number of corporate partners also gives students opportunities to apply their classroom learning to real-world situations to help make the world safer, cleaner and healthier.

More information

Oakland University to offer Master’s in Systems Engineering Degree

Oakland University’s Department of Industrial and Systems Engineering is now offering a Master’s in Systems Engineering program with a focus on systems integration. “Our department has a strong history in systems engineering, and with this master’s program we are looking to serve mechanical, electrical and other engineers involved in product design and development,” said Robert Van Til, Ph.D., chair and Pawley professor of lean studies in the Industrial and Systems Engineering (ISE) Department. “There has always been a demand for Systems Engineers in Southeast Michigan, primarily from the automobile and defense industries,” Van Til added. “But with the growing interest in connected vehicles and other connected products, the demand for Systems Engineers is expanding rapidly in all industries.” Systems engineering is the most difficult job for companies to fill with an estimated 1,388 annual job openings in the Southeast Michigan region between 2016 and 2026, according to a Connected Mobility Industry’s Skills Needs Assessment Project (SNAP) report issued by the Oakland County Executive and the Oakland County Workforce Development Board in March 2017.

More information

Standards and Guides

Systems Engineering Body of Knowledge (SEBoK) Application of Systems Engineering Standards

There are many systems engineering standards that have evolved over time. In particular, there are standards that can have an influence on organizations and their projects. Some pitfalls and good practices in utilizing standards are identified in related SEBoK articles. In this article, several additional factors related to the utilization of the standards in systems engineering (SE) are presented. A standard is an agreed upon, repeatable way of doing something. It is a published document that contains a technical specification or other precise criteria designed to be used consistently as a rule, guideline, or definition. Standards help to make life simpler and to increase the reliability and the effectiveness of many goods and services we use. Standards are created by bringing together the experience and expertise of all interested parties, such as the producers, sellers, buyers, users, and regulators of a particular material, product, process, or service. Standards are designed for voluntary use and do not impose any regulations. However, laws and regulations may address certain standards and may make compliance with them compulsory.

Organizations and their enterprises may choose to use standards as a means of providing uniformity in their operations and/or the products and services that they produce. The standard becomes a part of the corporate culture. In this regard, it is interesting to note that the ISO/IEC/15288 15288 (2015) standard has provided such guidance and has provided a strong framework for systems engineers as well as systems engineering and business management. Since the SE standards provide guidelines, they are most often tailored to fit the needs of organizations and their enterprises in their operations and/or for the products and services that they provide, as well as to provide agreement in a contract.

More information

Some Definitions to Close On

Improving Governance in Complex Project Environments

Note: These definitions are provided in the Locatelli et al article described in the SE Publications Section

Project Governance: Project Governance (PG) is the value system, responsibilities, processes, and policies that allow projects to achieve organizational objectives and foster implementation that is in the best interests of all stakeholders, internal and external, and the organization itself (Muller, 2009). Systems Engineering (SE) can improve project performance by transforming the governance from “project governance” to “system governance”.

System Governance: System Governance (SG) requires more effort in the early stages of the project life cycle. It is essential to achieve a clear definition of objectives, roles, responsibilities, and requirements. (SRA, 2003) System Governance requires the strong involvement of all stakeholders during the entire project.

Complex Project: A project that has at least one of the following characteristics:

several key distinct disciplines (such as project management [PM] and SE), methods, or approaches involved in performing the project;
strong legal, social, or environmental implications from performing the project;
usage of most of partner’s resources (both tangible and intangible);
strategic importance of the project to the organization or organizations involved;
stakeholders with conflicting needs regarding the characteristics of the product of the project; and
high number and variety of interfaces between the project and other organizational entities.

Systems Engineering: SE is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs. (INCOSE, 2006) SE is a multidisciplinary approach covering both technical and managerial aspects. SE merges traditional, technical, and managerial disciplines into a holistic systems approach. SE is based on a set of high level approaches and practically implemented with a set of techniques and tools. The first step of SE is to understand the environment, process, and policies of a system problem – this allows the generation of options.

Systems Thinking: Systems Thinking (ST) is the method developed to understand and analyze how different correlated elements, regarded as systems, influence one another within a whole (Jackson, 2003). ST is required, especially in complex environments, since the focus should not be on the sub-system, but on the system, as a whole (Checkland, 2012). ST requires that problem solving is carried out on a multidisciplinary basis to involve SE governance stakeholders with a widely large set of skills and expertise. ST successfully contributes to the governance of innovativeness, complexity, and uncertainty by embedding flexibility in managerial activities (Kapsali, 2011). SE ensures that the system is designed to be compliant with the “soft constraints” of each project environment. The multidisciplinary approach (see below) can transform the governance of projects developed in complex environments by paying specific attention to interactions among different system elements, stakeholders, and the leading organizations involved.

Checkland (2000) identifies two fundamental forms of ST, hard and soft:

Hard Systems Thinking: “Traditional SE” – historically, the SE discipline was primarily aimed at developing, modifying, or supporting well-defined projects with reliable data, clear objectives, and systems that can be optimized by classical engineering methodologies.

Soft Systems Thinking: Soft ST is ideal to cope with problems involving incomplete data, unclear goals, human beings, and cultural considerations. It is based on using a “learning system”, focusing on communication, inter-subjective complexity, and interpretations. It rejects the idea of a single project solution and considers situations as problematic because they contain multiple world-views, with their own perception, experience, and multiple objectives changing over time.

Open Systems Approach: A Methodology that continuously interacts with its environment or surroundings, adapting and evolving requirements throughout the system’s life to cope with changes and new requirements. (DOD, 2002) An open systems approach facilitates project governance by enabling build, upgrade, and support of systems more quickly and efficiently through the use of standard commercial products, available from multiple sources.

Multidisciplinary Approach: The approach that combines all the appropriate disciplines to identify project solutions in complex environments. SE is based on the multidisciplinary approach to ensure customer satisfaction throughout the whole system life cycle. According to multidisciplinary approach principles, System Governance should encompass not only traditional engineering principles and their technical and management domains (Ferris, 2008), but also social, political/legal, and human factors domains, and include disciplines such as operational research, architectures, modeling, simulation, and more (Kossiakoff et al, 2011).

Top Down and Bottom Up Approach (Vee Model): Top down and bottom up approach is an SE methodology to ensure that the system meets the needs and expectations of stakeholders. Top down approach is for systems design and bottom up approach is for systems integration (ANSI/EIA 632, 1999). The so called “Vee model” (Forsberg et al, 2005) represents a clear illustration of this idea. The left leg of the “Vee” represents the top down approach: the definition of system and decomposition of it in subsystems, flowing downwards from requirements to design. The right leg of the Vee represents the bottom up approach: the iterative process of integration and verification from system components to the system level, validating at sub-levels and customer requirements.

SE Techniques and Tools that transform the governance of projects delivered in complex environments include:

Integrated Product Teams (IPTs). IPT is an SE management technique to ensure the integration of different discipliner viewpoints during the entire system life cycle (Pyster et al, 2012). The IPTs include all the stakeholders, end-users, suppliers, and sub-contractors).
Systems Integration Process. Systems Integration Process is the process to ensure that all the elements of the system work together to realize system goals (DOD, 1990). The goal of the Systems Integration Process is to establish and manage internal and external systems interfaces of various kinds including: physical, functional, and logical. It ensures that subsystems are integrated into the system and that the system is fully integrated into the larger program (INCOSE, 2000).
Modeling and Simulation. Modeling is a key tool of SE supporting the decision-making process. Simulation is particularly important for the design of multidisciplinary systems.
Trade-off Analysis. Trade-off Analysis, or a trade study, is an analytical evaluation of alternatives against performance, design-to-cost objectives, and life cycle quality factors (Kossiakoff et al., 2011). It supports decisions throughout SE process solving conflicts and satisfying stakeholder needs, requirements, and constraints (Locatelli and Mancini, 2012).
SE Management Plan. The SE Management Plan (INCOSE, 2000) is the tool that provides to all stakeholders the planned technical effort to accomplish the project. A critical success factor for effective governance is the plan generation and communication. A best practice to do this is through the SE Management Plan (Sage and Armstrong, 2000).
Requirements Management Tools. Requirements Management (RM) is the SE process to capture, analyze, and track system requirements (Cant et al., 2006). A critical activity in RM is to maintain traceability, i.e., the “ability to describe and follow the life of a requirement, in both a forwards and backwards direction” (Gotel and Finkelstein, 1994). The tool of RM provides a rigorous “version control” of documents; establishes relationships between document elements and trace relationships between requirements, design, realization, and tests (Finkelstein and Emmerich, 2000). Linking requirements to other requirements helps to ensure that nothing is overlooked; reveals which are the other system elements that are affected; and tracks the status of each requirements during development. One of the requirements for an RM tool is the possibility for many users to work on the same data at the same time. The networkability of these tools allows the connection of dispersed IPT and enables program managers and systems engineers to better manage the project (Rundlet and Miller, 1994).

Summary

The PM applies tools to manage the project; the SE enlarges the view to the system and its whole life cycle. This holistic approach radically changes the point of view and the result of the analysis.

Source: www.sciencedirect.com/science/journal/02637863/32/8

Editor’s note: This excellent article which provides and explains these terms is available through a service called “ScienceDirect”; there is a charge of $35 US to download the PDF file.

PPI and cti News

CTI Presenting Courses in Wuxi and Nanjing, China

CTI (Certification Training International) delivered two consecutive CSEP preparation courses in Wuxi and Nanjing. In Wuxi, the course was delivered to Chinese Aero Engine Control System Research Institute. This institute manages research, design and production of aero-engine control system and mechanical and electrical products gas turbine set. It is the only professional institute of aero power control system in China. It is part of Aero, Engine (Group), Corporation, of, China (AECC), established in 31st May, 2016 for the development of Chinese made aviation engines.

Wuxi, China

In Nanjing, the course was delivered to AVIC Jingcheng Nanjing Engineering Institute of Aircraft System. Although all the delegates attending were designers for aircraft accessories, they valued the learning from INCOSE SEH and the extensive knowledge gained from our course presenter, David Mason. As they said, “we can’t wait to put all the knowledge into practice”!

Nanjing, China

Upcoming PPI/CTI Participation in Professional Conferences

PPI will be participating in the following upcoming events.

27th Annual INCOSE International Symposium (IS2017)

July 15 – 20, 2017

Adelaide, Australia

13th INCOSE SA Conference 2017

11 – 13 October 2017

Pretoria, South Africa

PPI and CTI Events

Systems Engineering Public 5-Day Courses

Upcoming locations include:

Melbourne, Australia
Las Vegas, N.V., United States of America
Washington, D.C., United States of America

Requirements Analysis and Specification Writing Public Courses

Upcoming locations include:

Adelaide, Australia
Singapore
Pretoria, South Africa

Systems Engineering Management Public 5-Day Courses

Upcoming locations include:

Stellenbosch, South Africa
Melbourne, Australia
London, United Kingdom

Requirements, OCD and CONOPS Public 5-Day Courses

Upcoming locations include:

Amsterdam, the Netherlands
São José dos Campos, Brazil
Melbourne, Australia

Architectural Design 5-Day Course

London, United Kingdom

Software Engineering 5-Day Courses

Adelaide, Australia
Amsterdam, the Netherlands

Human Systems Integration Public 5-Day Courses

Upcoming locations include:

Sydney, Australia

CSEP Preparation 5-Day Courses (Presented by Certification Training International, a PPI company)

Upcoming locations include:

Sydney, Australia
Stellenbosch, South Africa
Laurel, Maryland, United States of America

Kind regards from the SyEN team:

Robert Halligan, Editor-in-Chief, email: rhalligan@ppi-int.com

Ralph Young, Editor, email: ryoung@ppi-int.com

Suja Joseph-Malherbe, Managing Editor, email: smalherbe@ppi-int.com

Project Performance International

2 Parkgate Drive, Ringwood North, Vic 3134 Australia Tel: +61 3 9876 7345 Fax: +61 3 9876 2664

Tel Brasil: +55 11 3958 8064

Tel UK: +44 20 3608 6754

Tel USA: +1 888 772 5174

Website: www.ppi-int.com

Email: contact@ppi-int.com

Tell us what you think of SyEN. Email us at syen@ppi-int.info.

↑
Langley, Robitaille, and Thomas, Toward a New Mindset: Bridging the Gap between Program Management and Systems Engineering, 2011, p. 24. ↑
Eric Rebentisch, Editor-in-Chief, Integrating Program Management and Systems Engineering: Methods, Tools, and organizational Systems for Improving Performance. Hoboken, New Jersey, USA: John Wiley & Sons, 2017, p. xxxix. ↑
https://www.innoslate.com/requirements-management/ ↑
https://help.innoslate.com/users-guide/simulators/discrete-event/ ↑
https://help.innoslate.com/users-guide/simulators/monte-carlo/ ↑

Recent Editions

PPI SyEN 55

Subscribe to PPI SyEN

Abstract

Introduction

Current approach to assuring safe decisions

Cognitive Sciences

Sources of Decision Errors

Modeling irrational behavior

Cognitive bias

Confirmation bias

Risk assessment

Cost assessment

Post-traumatic risk assessment

Safety price

Ego-centric design

The hindsight effect

Responsibility

Self-awareness

Accountability

Safety climate

Case Studies

Design Decisions

Decisions by Executives

Decisions by Operators

A Comparison of the Impacts of Decision Errors

Remedies

The Guide to Resilience-oriented Systems Engineering

Protection layers

Validation

Summary and Conclusions

List of Acronyms Used in this Paper

References

Organization: The guide is organized as follows:

Organization: This Document Is Organized as follows:

PPI SyEN 134

PPI SyEN 133

PPI SyEN 132

PPI SyEN 131

FREE Original SE Articles and Industry News?

MORE About Us