bluuebunny/crossref_metadata_2025_split huggingface dataset:
1.5.4 Time‐Expanded Decision Networks: A Framework for Designing Evolvable Complex Systems
Authors: de Weck Olivier , Silver Matthew 
Published: November 2014

AbstractThis paper describes the concept of Time‐Expanded Decision Networks (TDN), a new methodology to design and analyze flexibility in large‐scale complex systems. This includes a preliminary application of the methodology to the design of Heavy Lift Launch Vehicles for NASA's space exploration initiative. Synthesizing concepts from Decision Theory, Real Options Analysis, Network Optimization, and Scenario Planning, TDN provides a holistic framework to quantify the value of system flexibility, analyze development and operational paths, and identify designs which can allow managers and systems engineers to react more easily to exogenous uncertainty. TDN consists of five principle steps, which can be implemented as a software tool: 1. Design a set of potential system configurations 2. Quantify switching costs to create a “static network” that captures the difficulty of switching among these configurations 3. Create a time‐expanded decision network by expanding the static network in time, including chance and decision nodes 4. Evaluate minimum cost paths through the network under plausible operating scenarios 5. Modify the set of initial design configurations to exploit high‐leverage switches and repeat the process to convergence. Results can inform decisions about how and where to embed flexibility in order to enable system evolution along various development and operational paths.
1.6.3 Managing Dynamic New Product Development Processes
Authors: Karniel Arie , Reich Yoram 
Published: November 2014

AbstractNew Product Development (NPD) processes are considered most challenging, involving major risks due to unknown or unforeseen obstacles, in terms of technology and business risks. The actual process activities which depend on the evolving product knowledge could be determined only during process execution. Thus, process planning is inherently dynamic and requires adaptation to product knowledge changes as well as other changes. Current Workflow tools can support ad‐hoc changes, but do not support the planning of process dynamics and the execution of such dynamic process changes as they unfold.The current article presents a novel system framework for managing dynamic process planning changes resulting from changes in customer requirements, product structure, product parametric dependencies and constraints, as well as ad‐hoc changes. The proposed framework comprises: process planning, incorporating the Design Structure Matrix (DSM) method; business rules for interprating the DSM‐based plan to process plan; dynamic process plan changes; and implementation of changes into Run Time process simulation.
2.1.2 Milestone Driven Systems Engineering Methods
Authors: Wells Brian H. 
Published: November 2014

AbstractMethods are presented that have been used successfully on large programs including a $3B development program that reached the System Requirements Review (SRR), Preliminary Design Review (PDR) and Critical Design Review (CDR) on or ahead of schedule. These methods link the non‐systems engineering activities into the system engineering processes and provides an effective means of communication and coordination between the systems engineers and design engineers to reduce the risk of achieving each milestone successfully. These methods augment the established systems engineering processes for technical reviews and use the milestone events as the impetus to drive the team and the program forward.
2.2.2 Using Stakeholder Analysis to Define the Problem in Systems Engineering
Authors: Trainor Timothy E. , Parnell Gregory S. 
Published: November 2014

AbstractThe first step in most system life cycles is the problem definition. Stakeholder analysis is a key technique to insure the problem has been fully and completely described before we attempt to obtain a solution to the problem. We identify and describe the three most common techniques for stakeholder analysis: interviews, focus groups, and surveys. We compare the three techniques using five criteria: time commitment of participants, ideal stakeholder group, preparation, execution, and analysis. We identify best practices to make stakeholder analysis both effective and efficient. This paper will aid the new practitioner and student of systems engineering as they organize and execute an effective stakeholder analysis, which is critical to the success of any systems engineering project.
2.3.2 Model‐based techniques for intelligent integration and testing in industry*
Authors: Braspenning N.C.W.M. , van der Ploeg D.O. , van de Mortel‐Fronczak J.M. , Rooda J.E. 
Published: November 2014

AbstractThe effort required for integration and testing of high‐tech multi‐disciplinary systems is increasing with each new or upgraded system that is developed. To counter this trend of increasing integration and test lead time and costs, we propose a model‐based integration and testing (MBI&T) method, where formal and executable models of the system components are used to replace the component realizations for early integration and system testing. In this paper, we describe how the integration and testing process currently used in industry can be made more intelligent by applying model‐based techniques from the MBI&T method. We also show how to analyze the necessary trade‐off between the investments needed for model development and the potential effort reduction, using a systematic and automatic integration sequencing method.
2.3.3 HCI Aspects of SysML and Architectural Frameworks
Authors: Hause Matthew , Thom Francis 
Published: November 2014

AbstractThe Human Computer Interface (HCI) is one of the most important aspects of any system. It governs how people perceive the environment in which the system is deployed, and can either enable or hinder their ability to interact with that environment. Specifying the appropriate characteristics of the interface is therefore crucial to the correct implementation of the system. The goals of HCI are to develop or improve the safety, utility, effectiveness, efficiency, and usability of systems that include computers. The challenges for HCI are to keep abreast of technology, and to ensure that their designs offer good HCI, as well as harnessing the potential functionality of the new technology. As SysML becomes more prevalent for modeling systems, integrating HCI aspects into these models has the potential for improving HCI, eliminating duplication of tasks, and making systems more useable. This paper will look at SysML and DoDAF/MoDAF (MAF) and how they contribute towards defining the parameters in which the HCI will take place.
2.4.2 Incorporating Software Cost and Risk Assessment into Early System Development Trade Studies
Authors: Weiss Kathryn Anne , Leveson Nancy G. , Francis James 
Published: November 2014

AbstractThis paper introduces a new method called SOCRATES (Software Cost and Risk Assessment for Trade and Engineering Studies) for incorporating software cost and risk assessment into the early concept development activities and trade studies typically conducted for complex systems. Early conceptual architecture trade studies often omit software cost and risk in architectural comparisons. However, the increasing importance of software in complex system design and its impact on project risk necessitates consideration of the cost and risk associated with developing and fielding software in early engineering architectural trade studies. SOCRATES takes into consideration the allocation of functionality to both software and human controllers and evaluates the utility of assigning control based on development cost, development risk, and mission risk. It also provides input to system engineers about the relative comparison of the cost and risk for a variety of system architecture concepts as well as recommendations based on the results. The technique is demonstrated on the Lunar and Mars Transportation and Surface Operations Architectures developed for the NASA Exploration Initiative Concept Exploration and Refinement Study.
4.5.4 Dialogic design for the intelligent enterprise: Collaborative strategy, process, and action
Authors: Jones Peter H. , Christakis Alexander N. , Flanagan Thomas R. 
Published: November 2014

AbstractDialogic design provides efficient, reliable approaches for organizations to envision and implement cohesive, comprehensive, and compelling roadmaps for enterprise evolution. Using structured dialogue to integrate the collective intelligence of stakeholders, we produce a shared representation of the intelligent enterprise, enabling “organizing around intellect.” Dialogic design is progressive in focus, scaling from strategic vision to business process design to system requirements, mapping each level's priorities to successive requirements. Each focus inquiry iterates from deep problem understanding, to generative solution design, through consensus action planning.We applied Structured Dialogic Design to the transformation of a small consultancy, with findings applicable to any enterprise. The process efficiently enables a democratic, collaborative approach to redesign of socio‐organizational systems and practices, using a software‐supported collaborative process. It efficiently achieves true consensus on organizational and business strategy, resolves multiple conflicts of values and resource decisions, and determines the most effective priorities while preventing groupthink errors.
4.6.2 YADSES: Yet Another Darn Systems Engineering Standard
Authors: Walden David D. 
Published: November 2014

AbstractIt has happened to most everyone – someone releases the “next best” Systems Engineering standard (or method or tool or …) and your organization has decided to use it. How does one incorporate this new standard into the existing set of organizational processes without “breaking” the current processes and negatively impacting compliance to all the “old” standards that do not go away? By the way, expect to repeat this process at least every other year.This paper gives practical advice to help ensure organizations are prepared for these types of situations. Guidance is given on how to establish and maintain organizational processes such that the introduction of Yet Another Darn Systems Engineering Standard (or YADSES as we will refer to it) causes minimal impact.
5.4.2 MV2 Tool Presentation: A management tool for the validation and verification of requirements by Airbus
Authors: Ducamp Christophe , Lagarrigue Alain 
Published: November 2014

SummaryAs the final integrator of the whole of systems and structures, equipments and engines that compose the aircraft, Airbus developed an Information System to manage product requirements and deployed it on a transnational basis. The specification of the tool ‐ labeled MV2 ‐ was based on the process of V&V (Validation & Verification) of requirements applied to a given aircraft program. Apart from the requirements related to its environment of use, and of the interfaces with the existing processes, the tools or databases already in place, the mission of Airbus was to make sure it could control the satisfaction of all the users involved throughout the life cycle of the product in the activities of validation and verification of the requirements. The results obtained by MV2, already applied to the A380 and A400M programs, corroborated the strategy carried out by Airbus, i.e.:
To manage the operational state of a function, system, equipment, structural part, for the whole requirements applied to them.
To challenge the response times between the test results or analyses and the modification of the functional elements, considered at the elementary product level as well as at the comprehensive product level.
6.1.3 System Resilience: Capabilities, Culture and Infrastructure
Authors: Jackson Scott 
Published: November 2014

AbstractSystem resilience is the ability of organizational, hardware and software systems to mitigate the severity and likelihood of failures or losses, to adapt to changing conditions, and to respond appropriately after the fact. Challenger, Columbia, Chernobyl and Bhopal are examples of such failures. System resilience goes beyond traditional disciplines, such as reliability and system safety to achieve its goal. System resilience employs systems engineering principles at product and infrastructure levels. The infrastructure system includes such nodes as the developer, the customer, the user, the maintainer, and the operator. System resilience requires that systems engineering principles be practiced across organizational boundaries and to a greater level of detail than is common in today's world. System resilience depends on developing beneficial paradigms within all nodes of the infrastructure. Finally, system resilience requires that all nodes of the infrastructure system have a set of capabilities that are directly derivable from root causes of catastrophes. The combination of capabilities, culture and infrastructure forms the basic framework of system resilience.A key aspect of catastrophes is emergence, that is, the negative interaction among two or more elements of the system, who, when acting alone perform benignly. Prediction of emergence and design against emergence is a major challenge of resilience.Adaptability is the characteristic of a system that allows it to survive a catastrophe. Although rules for the creation of adaptability in human‐intensive systems have been formulated, similar rules for hardware and software systems are in their infancy.
6.4.1 The Hitchins‐Kasser‐Massie (HKM) Framework for Systems Engineering
Authors: Kasser Joseph E. 
Published: November 2014

AbstractGeorge Friedman (Friedman, 2006) called for the development of a grand unified theory of systems engineering (GUTSE) echoing (Hill and Warfield, 1972) who wrote “development of a theory of systems engineering that will be broadly accepted is much to be desired.” Taking up the spirit of the challenge, this paper applies systems thinking to systems engineering to propose a framework that can serve as a vital element in formalizing the discipline of systems engineering and potentially as a platform for developing such a theory.This paper focuses on what systems engineers do, and builds on past research and success. Documenting research using an object‐oriented approach in a creative and innovative manner it discusses the evolution of a proposed framework for systems engineering that meets or shows promise of meeting the following four requirements (Kasser, 2006):
The framework shall provide an understanding of why systems engineers can't agree on their roles and activities.
The framework shall provide an understanding of the reasons for the overlap between systems engineering and management.
The framework shall provide a way to cope with complexity.
The framework shall enable the lowering of the cost of doing work by at least an order of magnitude.The framework is based on a combination of the Hitchins' five‐layer representation of systems engineering (Hitchins, 2000) extended by Kasser and Massie over the systems lifecycle phases (Kasser and Massie, 2001) coupled with Shenhar and Bonen's taxonomy of systems based on technological uncertainty (risk) (Shenhar and Bonen, 1997).
6.4.2 A Metric Framework for Capability Definition, Engineering and Management
Authors: Lam Sylvia , Pagotto Jack , Pogue Chris , Hales Doug 
Published: November 2014

AbstractAs defence planning and management evolves from a platform‐centric, threat‐based approach toward a capability‐based paradigm, the need for a rigorous approach to systems engineering at the capability level is amplified. This is because capability‐based plans incorporate system‐of‐systems configurations with varying developmental timeframes that must deliver interoperable effects on the battlefield. In addressing this challenge, a capability‐based planning construct is being examined within the Department of National Defence. This construct is supported by integrating and enabling concepts like enterprise architectures, system‐of‐systems engineering principles and capability metrics. While an architecture framework is useful for developing functional requirements of a capability, a metric framework, as this paper contends, can be used as a guide for defining and articulating desired quality characteristics. This paper describes the concept of a capability metric framework, and how it has been applied to define capability goals and evaluate implementation options.
7.1.4 Coping With System Integration Challenges in Large Complex Environments
Authors: Muller Gerrit 
Published: November 2014

AbstractThe increasing scope of systems integration poses many challenges for the system integrators. This paper contends that in conventional projects the Systems Integration phase is systematically underestimated. During this phase all unexpected and unforeseen problems surface, where most problems are cross‐organizational. When the project size increases with more suppliers, more users, more enterprise processes, and more (intelligent) functionality, then the system integration phase gets tremendously more difficult.In this paper we will bring order to the integration process and discuss an approach and best practices to cope with systems integration in conventional projects. Such level of integration approach is a prerequisite to deal with all added integration complexity in systems with a scope of (intelligent) enterprises.
7.2.0 Panel 7.2.0: Challenges and Successes in the Deployment of Systems Engineering in the Commercial World
Authors: Jain A. , Brickley L. , Reichart G. , Smith F. 
Published: November 2014

AbstractEach panel will focus on his or her experience in deploying Systems Engineering in their industry and domain with an emphasis on successful techniques for handling the lack of acceptance and lack of history of SE in each domain. Each Panelist will, at least, address the discussion items: Is there a lack of acceptance of SE in your industry? Is SE practiced in your industry under a different title? Can SE be deployed by management edict and training or one has to employ diplomacy in dealing with internal engineering departments? Can SE practices be domain tailored without sacrificing the basic SE principles? Audience participation will be requested.
7.4.1 Coupling Enterprise and Technology by a Compact and Specific Architecture Overview
Authors: Muller Gerrit 
Published: November 2014

AbstractEnterprise level projects tend to be delayed and to exceed budgets. Original expectations and targets are not met by these projects. Many solutions have been proposed to address this problem, one of them the application of Systems Engineering at large. In this paper we show how a compact Architecture Overview is a helpful instrument to keep enterprise level projects on track.Practical experience shows that such an overview provides a quick insight in project progress and in potential threats. Principal customers and managers should ask the architects for this overview. Benefit for the architects of making the overview is that it helps to position their work in the enterprise context. Experience also shows that pragmatic system engineering practices, such as process orientation and project management are complementary to the proposed overview. This combination of overview and pragmatic systems engineering is very powerful.One of the main issues in creating an architecture overview is the need for breadth, what needs to be included and for whom, and the balancing act of providing sufficient depth, what are crucial details that are part of this top‐level description. Also the way of describing is discussed, from stakeholder needs to ambiguity and the level of formalism.
7.5.1 Taking Out the Garbage – How to Get Good Risks into Your Risk Tool
Authors: Parker Vikki 
Published: November 2014

AbstractYou have a sophisticated risk tool. You have leadership buy‐in on the importance of risk management and you have formal risk management communication channels. Yet, your risk assessment discussions swirl and your list of top risks does not accurately reflect what you know to be true. Worse, the risk information is not helpful in your organization's decision‐making forums. What else can you do? Consider the old saying “garbage in, garbage out.” Before you dazzle them with your quantitative analysis and Monte Carlo simulations, strive for getting good content into the tool. In this white paper, you will see examples of effective risk statements and learn a proven approach for getting better risk data into your organization's decision‐making activities – and put that sophisticated risk tool to good use.
7.6.1 Systems are Imaginary—Systems are Not Real: Some Thoughts on the Nature of Systems Thinking
Authors: Martin James N 
Published: November 2014

AbstractSystems are not as real as we think they are. It is indeed true that engineers design things that when placed into service are very real. But these things are merely constituents of perhaps many different systems. Which systems these engineered things belong to is really up to our imagination to make such assignments. The assignments of these things to systems is what is involved in “systems thinking.” We make assignments of things to systems before these things exist in order to examine their contribution to the system's intended “purpose.” We can even make assignments of things to (different) systems to examine how they are currently behaving (or perhaps misbehaving). This paper will explore what it means to employ systems thinking to imagine various system structures and to examine these structures for their suitability in different situations to address perceived problems.
8.2.1 The Compilation of an Integrated Qualification and Commissioning Programme for a Nuclear Power Plant
Authors: Brits BC 
Published: November 2014

Executive SummarySystems engineering principles, and more specifically qualification principles, are application dependant. In general, these principles can be easily applied in the qualification of most products in the automotive, aerospace and arms industries. When it comes to the qualification of a commercial nuclear power plant (or probably any commercial plant for that matter), however, there are numerous limiting factors that prohibit the orthodox application of these basic principles.The intent of this paper is to show how the classic qualification principles can be interpreted and adapted to a specific application, provided there is a solid understanding of both the basic qualification principles, as well as the peculiarities associated with the specific product and its related industry sector. The size, cost, design complexity, maturity of technology base and the projected life cycle of the product, as well as acceptable practices within its industry sector, have a significant effect on how the basic principles can be applied. Once the application of the principles is understood, it becomes relatively easy to plan and structure a process for the compilation of an integrated qualification programme. This process is essential to ensure that all angles are covered during the qualification planning stages, and to ensure effective execution and management of the planned qualification activities.