Each year, INCOSE's technical team recognizes the best papers of the symposium. The following are abstracts from the six award winners from 2004. The complete text of each of these papers can be found on the symposium proceedings CD.
Isoperformance: Analysis and Design of Complex Systems with Known or Desired Outcomes
Paper 2.1.1 by Olivier L. de Weck and Marshall B. Jones
Tradeoffs between performance, cost and risk frequently arise during analysis and design of complex systems. Many such systems have both human and technological components and can be described by mathematical input-output models. Oftentimes such systems have known or desired outcomes or behaviors. This paper proposes “isoperformance” as an alternative approach for analyzing and designing systems by working backwards from a set of desired performance targets to a set of acceptable solutions. This is in contrast to the traditional “forward” process, which starts first in the design space and attempts to predict performance in objective space. Isoperformance can quantify and visualize the tradeoffs between determinants (independent design variables) of a known or desired outcome. For deterministic systems, performance invariant contours can be computed using sensitivity analysis and contour following. In the case of stochastic systems, the isoperformance curves can be obtained by regression analysis, given a statistically representative data set. Examples from optomechanical systems design and human factors are presented to illustrate specific applications of the method.
The Seven Samurai of Systems Engineering: Dealing with the Complexity of 7 Interrelated Systems
Paper 3.1.2 by James N. Martin
There are seven different systems that must be acknowledged and understood by those who purport to do systems engineering. The main system to be engineered is the intervention system that will be designed to solve a real or perceived problem. The intervention system will be placed in a context system and must be developed and deployed using a realization system. The intervention, when installed in the context, becomes the deployed system which is often different in substantial ways from the original intent of the intervention. This deployed system will interact with collaborating systems to accomplish its own functions. A sustainment system provides services and materials to keep the deployed system operational. Finally, there are one or more competing systems that may also solve the original problem and will compete for resources with your deployed system. All seven systems must be properly reckoned with when engineering a system.
Complex System Classification
Paper 3.1.3 by Christopher L. Magee and Olivier de Weck
The use of terms such as “engineering systems,” “system of systems” and others have been coming into greater use over the past decade to denote systems of importance but with implied higher complexity than for the term “systems” alone. This paper searches for a useful taxonomy or classification scheme for complex systems. There are two aspects to this problem: (1) distinguishing between engineering systems (the term we use) and other systems, and (2) differentiating among engineering systems. Engineering systems are found to be differentiating from other complex system by being human-designed and having both significant human complexity as well as significant technical complexity. As far as differentiating among various engineering systems, it is suggested that functional type is the most useful attribute for classification differentiation. Information, energy, value and mass acted upon by various processes are the foundation concept underlying the technical types.
An Approach to Design for Safety in Complex Systems
Paper 3.2.3 by Nicolas Dulac and Nancy Leveson
Most traditional hazard analysis techniques rely on discrete failure events that do not adequately handle software intensive systems or system accidents resulting from dysfunctional interactions between system components. This paper demonstrates a methodolody where a hazard analysis based on the STAMP accident model is performed together with the system development process to design for safety in a complex system. Unlike traditional hazard analyses, this approach considers system accidents, organizational factors, and the dynamics of complex systems. The analysis is refined as the system design progresses and produces safety-related information to help systems engineers in making design decisions for complex safety-critical systems. The preliminary design of a Space Shuttle Thermal Tile Processing System is used to demonstrate the approach.
Can Systems Engineering be taught at the Undergraduate Level?
Paper 5.2.1 by Sue Goodlass
Everyone knows that systems engineering is complicated and difficult. It takes a long time to become sufficiently experienced to be a good practitioner and people need to make mistakes in order to learn from them. How successfully then, can such a difficult topic be taught at undergraduate level? In the early 1990s, BAE SYSTEMS engaged Loughborough University to develop and deliver an undergraduate systems engineering program and has recruited engineers from it since the first cohort graduated in 1997. This paper describes how the program was designed and developed and compares systems engineers graduating from this program with other engineers in BAE SYSTEMS.
Assessing the Impact of Requirements Volatility on the SE Process using Bayesian Analysis
Paper 7.1.1 by Michael Russell
There are many factors that affect the level of requirements volatility a system experiences over its lifecycle. Improper requirements generation, undocumented user expectations, conflicting design decisions, and anticipated/unanticipated world states are representative of these volatility factors. Combined, these volatility factors adversely affect successful system development. This paper proposes that a Bayesian Network can be used to support reasonable judgments concerning the most likely sources and types of requirements volatility a developing system will experience prior to starting development; and by doing so it is possible to predict the level of requirements volatility the system will experience over its lifecycle. This assessment offers valuable insight to the system’s developers, particularly by providing a starting point for risk mitigation planning and execution.