bluuebunny/crossref_metadata_2025_split huggingface dataset:
Systems Architecting: a Business Perspective
Authors: Muller Gerrit 
Published: November 2014

AbstractSystem architects play an integrating role between many specialized engineers and other stakeholders during the creation of new systems. The role of system architect requires a broad set of skills. How do you cope with conflicting needs, opinions, and interests? How do you lead the design team effectively? How do you balance innovation and risk mitigation, installed base and new systems, short term and long term? How do you share vision and make pragmatic choices at the same time?This tutorial focuses at the less technical aspects of systems architecting. The program is based on one of the basic working methods of an architect: viewpoint hopping. The tutorial addresses systems architecting from ten different viewpoints.Objective of the tutorial is to teach system engineers and architects methods and techniques function effectively in multi‐disciplinary design environments with lots of stakeholders. It teaches project leaders and other close stakeholders of the architect what to expect from the architect and how to interact with architects.All information (System Architecture articles, course material, curriculum vitae) can be found at: Gaudí systems architecting http://www.gaudisite.nl/
Simple Techniques for Applying Systems Engineering Principles When You're New to the Game
Authors: Hamelin R. Douglas , Caliva Robert M. , Park Charles , Braase Lori 
Published: November 2014

AbstractMany SE practitioners, particularly those who are new to the discipline, can become overwhelmed by the high‐end tools and techniques often viewed as necessary for conducting “real” systems engineering. Even though such tools and techniques are common in our applications of systems engineering, INL systems engineers have a long history of using simple, tailored methods to achieve significant success on complex projects. This half‐day (4‐hour) tutorial is designed to introduce new‐comers and seasoned practitioners alike to the overall systems engineering process as it relates to typical project life‐cycle phases and to present a few of the “simple” tools (with practical examples) that we have found useful in conducting systems engineering work. Ultimately, attendees will learn how to use items as simple as a white board, pad of engineering paper, and standard desktop software to help a project get from concept to system design without the need for high‐end tools and technologies.
Requirements Engineering for Large Scale Systems: Processes and Tooling
Authors: Berenbach Brian , Worl John 
Published: November 2014

AbstractRequirements engineering processes in the large are very different from those on small to medium size systems. Most texts on requirements engineering, for example tend to describe small or medium scale systems (up to about 5K requirements), or if the systems are large, describe the processes associated with product development and product lines. Industrial projects, however, start at 20K requirements and up. The creation of scalable processes that will support a large infrastructure project of the kind we are reading about in the headlines today (e.g. “shovel ready”) can be a daunting prospect. This tutorial will present some of the challenges associated with the requirements engineering of such large projects, and describe how to setup processes and tooling to support them. This is part one of a two part tutorial. This session describes how to set up processes and tooling for very large industrial projects, typically dealing with 50 thousand or more requirements. The second session describes the unique nature of requirements engineering processes for contract based projects. Either session may be taken independently, but the attendee will get the most out of the tutorial by attending both sessions.
What Forest? All I See are these SE Trees!
Authors: Powell Mark A. 
Published: November 2014

AbstractFar too often we Systems Engineers work intensely in one single activity area of SE, usually for long periods. Perhaps we work requirements, or verification, or maybe even the engineering specialties, for months or maybe even years. It is easy to get consumed in the job. It is easy to lose sight of exactly why we do these specific jobs as SE's, and why we do them the way we do. We can lose sight of how our specific job contributes to the success of the project. SE then just becomes another job. But it is not just another job – it is the most important job for any project.This half day tutorial is based on a 20 hour SE refresher course that has been taught to practicing SE's ranging from fresh college grads to grizzled and gray SE veterans. It addresses all of the major areas of SE, but with a twist – we focus on the “why” we do the things the way we do in SE, what was the lesson learned, and how it contributes to project success. For the fresh grad taking this tutorial, all of things we do in SE will make sense, fit together in a nice neat package, and will seem obvious. For the veteran, this tutorial will re‐ground and renew their spirit. Almost all SE veterans who have taken the refresher course report that they perform better in their jobs, and more importantly, they are a lot happier doing their SE job.
Scenario‐based requirements engineering facilitating interaction design
Authors: Kaindl Hermann 
Published: November 2014

AbstractWhen the requirements and the interaction design of a system are separated, they will most likely not fit together, and the resulting system will be less than optimal. Even if all the real needs are covered in the requirements and also implemented, errors may be induced by human‐computer interaction through a bad interaction design and its resulting user interface. Such a system may even not be used at all. Alternatively, a great user interface of a system with features that are not required will not be very useful as well.Therefore, the primary motivation of this tutorial is to improve system development in practice both regarding requirements engineering and interaction design, especially facilitating the latter. We argue for combined requirements engineering and interaction design, primarily based on usage scenarios in the sense of sequences of actions aimed at accomplishing some task goal. However, scenario‐based approaches vary especially with regard to their use, e.g., employing abstract use cases or integrating scenarios with functions and goals in a systematic design process. So, the key issue to be addressed is how to combine different approaches, e.g., in scenario‐based development, so that the result is an overall useful and useable system. In particular, scenarios are very helpful for purposes of usability as well.
Systems Architecting and Program Management with the Design Structure Matrix (DSM)
Authors: Browning Tyson R. 
Published: November 2014

AbstractThe design structure matrix (DSM) is a powerful tool for visualizing, analyzing, innovating, and improving systems, including product architectures, organizational structures, and process flows.Akin to a traditional N2 chart and the System‐System matrix (SV‐3) in the DoD Architecture Framework (DoDAF), the DSM is a square matrix showing relationships between system elements. These elements can be product components, teams, activities, etc. By analyzing the DSM, one can prescribe a better (e.g., more modular) system architecture or organization. Adding a time‐basis enables one to prescribe a faster, lower‐risk process. Because the DSM highlights process feedbacks, it helps identify iterations and rework loops—key drivers of cost and schedule risk.The DSM is concise, visually appealing, and used in many organizations across diverse industries. Users have found DSM extremely useful for fostering architectural innovation and enabling the situation awareness and empowerment that motivates the people executing complex processes. This tutorial introduces the DSM and three distinctive applications useful to product developers, systems engineers, and project and program managers. Real‐life examples are presented from the aerospace, automotive, semiconductor, and other industries. Participants will engage in hands‐on exercises (building DSM models) and come away with a clearer understanding of the drivers of critical, emergent behaviors in systems. The methods can be applied immediately to projects for quick results and insights.
Engineering Requirements in Product Lines
Authors: Mannion Mike , Kaindl Hermann 
Published: November 2014

AbstractNew product development is a usually a compromise between customer requirements, existing product architectural constraints and commercial needs. Many product innovations are cost‐effective extensions within a product line, and draw on a deep knowledge of existing processes, products or services. In this tutorial we describe how requirements for a product line can be modelled, selected and reused to engineer the requirements for innovative new products. Critical issues are the engineering of requirements commonality and variability across different products, the management of inter‐dependencies between reusable requirements during selection, the constraints placed upon these selections by existing architectures, and being able to manage each of these issues when the number of requirements is very large. We address these concerns, present results of using these techniques, and describe some software tools that can be used to support them.
Thinking Outside the Box ‐ In Systems Engineering and Integration
Authors: Eisner Howard 
Published: November 2014

AbstractBuilding large and complex systems continues to be a significant challenge for today's systems engineers and integrators. This tutorial sets forth new ways of thinking that could lead to improvements in how systems engineering and integration are carried out. In particular, nine new perspectives are suggested for “thinking outside the box”. Examples are provided for each, along with a discussion of their potential benefits. In addition, thinking in groups as well as historical thinking suggestions are examined. A summary provides an overview of notions that represent departures from current mainstream approaches.
Systems Engineering for Advanced Manufacturing: Unit Op Insights from Model‐Based Methods
Authors: Schindel William D. 
Published: November 2014

AbstractInnovative manufacturers, pursuing competitive advantage, increasingly push the envelope of production system complexity. Advanced manufacturing applies materials science, chemistry, thermodynamics, biology, information technologies, and engineering disciplines. Historically a pragmatic domain respecting intuition, experience, and judgment, manufacturing increasingly demands scientifically‐based mastery of the systemic properties of interacting processes, materials, and products. Stable and predictable performance is expected across technology transfers and changes in recipes. Customers, owners, and regulators press traditional process engineering and specialized disciplines to integrate more deeply, producing “Quality by Design” outcomes, faster, at lower costs.This paper describes a novel model‐based method focused on unit manufacturing operations and their integration into production cells, lines, and facilities. Modeling what occurs during transformations, these science‐based descriptions move beyond Process Flow Diagram (PFDs) to represent, independent of equipment design, interdependencies of materials, processes, equipment, and control strategies—automated or human. This approach has improved integrating insight across diverse manufacturing processes.
Identifying Agile Security Patterns in Adversarial Stigmergic Systems
Authors: Lugosky Jena , Dove Rick 
Published: November 2014

AbstractSystem adversarial communities appear to exhibit characteristics of natural agile systems, and enjoy an advantage as a result over static systems that are the focus of their attacks. A project started in graduate courses at Stevens Institute of Technology and currently pursued by the International Council on Systems Engineering Working Group on Systems Security Engineering works under the premise that security strategy will benefit by architectural patterns that are equally self organizing. To that end a pattern cataloging project is in process, identifying fundamental self organizing patterns that can explain the adversary operational modes and inform next generation security strategy. This article advances that pattern project by exploring and capturing the stigmergic communication employed by system‐adversarial communities according to the pattern project guidelines. This article first identifies the unique stigmergic pattern, explores its nuances, and presents it in a format identified by the pattern project. Then the stigmergic pattern is applied as a mold to analyze a series of three systems in an effort to regard each within a familiar context. Three adversarial systems, the Iraqi Insurgency, IED Networks and Cybercrime, were selected as prominent opponents that provide significant consternation to security experts. They are first identified as agile systems, per characteristics defined by the pattern project, then studied in the context of the stigmergic pattern.
Stakeholder Approach to Better Understand the Psychological Health Services in the Military
Authors: Ippolito Andrea , Srinivasan Jayakanth 
Published: November 2014

AbstractEnsuring the psychological well‐being of service members and their families has emerged as one of the principal challenges of today's armed services. Given that the system of care of psychological health services in the United States Military cannot be divorced from the large healthcare delivery system, an enterprise perspective is needed to truly understand the dynamics of care. This paper makes two key contributions: it identifies the key stakeholders of the military health enterprise with respect to psychological health, and analyzes the espoused senior leadership values over the last decade as seen in the stakeholder reports. This stakeholder analysis highlights the challenges faced in melding the constituent organizations into an enterprise, especially in the face of leadership turnover. The thematic analysis of senior leadership values shows an evolution of focus from managing execution of care to emphasizing healthy lifestyles and psychological health.
1.1.3 Need for Robust Systems Engineering in a Time of Budget Austerity
Authors: Rosenthal Rich , Sheard Sarah , Neuendorf William F. 
Published: November 2014

AbstractToday's larger, more complex systems are riskier than before, with dire consequences if they fail. This paper makes the case that systems engineering is needed now more than in the past, and it would be a mistake to reduce funding for systems engineering at the same time that national security programs in general are being reduced.Systems engineering helps improve decision making under conditions of uncertainty and complexity, using a combination of proven and new tools. Systems engineering orchestrates integration among disciplines and subsystems using collaborative tools such as integrative review. Systems engineering supports new acquisition models such as incremental commitment by implementing enterprise architecture roadmaps and recommending new technology to improve capability. Model‐based systems engineering leads to lower cost, improved capability, lower risks, and improved defenses against attack.Systems engineers are learning techniques from complexity science such as hierarchical and modular design, prevention of failures from unintended consequences, and analysis of power law characteristics in complex systems. The paper discusses these concepts to show the importance of maintaining systems engineering in the face of budget austerity.
1.3.3 Systems of Innovation I: Summary Models of SOI Health and Pathologies
Authors: Beihoff Bruce C. , Schindel William D. 
Published: November 2014

AbstractInnovation is critical to viability in changing environments. In living ecosystems, innovation adapts to changes by predators, prey, and the rest of the environment (e.g., geology). For engineered systems, innovation exploits market interests in new capabilities, creates new markets, develops competitive advantage, and adapts to changes in technologies, infrastructure, regulations, and commercial environment.In all these domains, the process of innovation may itself be described as a system—the System of Innovation, and studied by natural scientists, engineers, and technologists. The relative effectiveness of different systems of innovation impacts the competitive viability of the resulting series of innovated systems.Modeling pathologies improves understanding of healthy systems, assessment of effectiveness, and ability to prevent or correct pathologies. “System pathologists” are found in medicine, field support and maintenance organizations, agriculture, the natural sciences, and other domains. This work is concerned with modeling Systems of Innovation, including characterizing their pathologies and health.
1.4.1 Program Accreditation and the Graduate Reference Curriculum in Systems Engineering (GRCSE™)
Authors: Olwell David H. , Enck Stephanie , Hutchison Nicole , Pyster Art , Anthony James 
Published: November 2014

AbstractThis paper discusses the possible use of the Graduate Reference Curriculum for Systems Engineering (GRCSE) to inform engineering accreditation efforts. The paper is organized as follows: The first section provides background on the genesis of GRCSE. The second section discusses the status of accreditation of systems engineering in the United States and Europe. The third section discusses the objectives, outcomes, and core body of knowledge contained in GRCSE. The last section concludes with a discussion of how the GRCSE work might be expected to influence future accreditation.
2.1.1 Security Systems Engineering: Using Functional Decomposition to Resolve a Confused Taxonomy
Authors: Thompson Marcus A. , Ryan Michael J. , McLucas Alan C. 
Published: November 2014

AbstractThe specification and design of modern security systems are hampered by terminology that is overlapping and recursive. The definitions offered by prominent standards bodies lack commonality in meaning and interpretation and tend to be specific to electronic or cyber security. Consequently, the current set of security terms and definitions is of little use to stakeholders. This paper begins by examining the definitions and terms applied to security and security systems. A systems engineering approach is then used to analyse the set of terms and to propose a new definition of security, from which a suitable set of security terms is decomposed. Definitions of security services and security mechanisms that have a broad application across the electronic, physical, and personnel security domains are then developed, and examples are provided that illustrate the utility of the set of definitions in security management, requirements engineering, systems engineering, and system design methodologies.
2.3.2 It's All Rocket Science: On the Equivalence of Development Timelines for Aerospace and Nuclear Technologies
Authors: Crépin Maxime , El‐Khoury Bernard , Kenley C. Robert 
Published: November 2014

AbstractEarly in the lifecycle of a system development, systems engineers must execute trade studies to allocate resources between different research and development efforts that are developing technologies to be deployed into the system, and they must prepare risk management plans for the selected technologies. We have been developing a statistical model for schedule and cost uncertainty based on a small number of inputs that are quite objective and are already integrated with technology readiness assessment. An algorithm that transforms Technical Maturity (TM) scores from Department of Energy projects into a Technology Readiness Level (TRL) score was created, allowing us to add data from a US Department of Energy to an existing set of data from NASA. We statistically tested whether the two samples (i.e. the DoE and NASA datasets) were randomly drawn from the same population and concluded that the transition times for developing aerospace and nuclear technologies are very similar.
4.3.3 Emergence: The Illusion of Knowledge
Authors: McConnell George R. 
Published: November 2014

AbstractIn a series of papers to the INCOSE symposia under the banner of emergence, the author has introduced his audience to a variety of aspects of complex systems. The glue linking these together has been the fact that all systems exhibit properties, characteristics and attributes that can be collectively called emergent properties. Following this theme, this paper examines the issues that can arise when there is an assumption of a level of knowledge about a subject that is not backed up in reality.
5.2.2 Human Systems Integration in Next‐Generation Expeditionary Medical Treatment Facilities
Authors: Folds Dennis J. 
Published: November 2014

AbstractFuture military Expeditionary Medical Treatment Facilities (EMTF) face pressure to provide medical services for personnel and local populations while operating with reduced manpower and increasingly complicated equipment. Human systems integration (HSI) is the systems engineering process for integrating all human‐related technical considerations in systems planning, design, and development. The present effort was performed to identify HSI issues in future EMTFs and to develop HSI guidance to the designers, and developers of those facilities. Over 100 issues were identified in an assessment of current capabilities and in emerging technologies that are expected to become part of future EMTFs. The three highest priority recommendations from this effort are (1) develop a patient transfer system that simultaneously addresses physical and information transfer across units or shifts; (2) develop a team training capability integral to the EMTF; and (3) perform a system‐wide safety audit to ensure a total system safety perspective in future EMTF.
5.4.2 Introducing Systems Engineering Views in Product Lifecycle Management
Authors: Autran Frédéric , Scheithauer Dieter 
Published: November 2014

AbstractProduct Lifecycle Management demands to integrate all engineering data of a product or service in order to provide full traceability of dependencies between information of different types and from various sources. Current Product Data Management solutions set the focus mainly on data representing physical items. Version Management applications originating from software engineering environments are frequently used also for storing systems engineering data. However, this data management landscape is not adequate for the central role of systems engineering driving both, the development of physical system elements and of system elements implemented by software.This paper describes how all product data may be integrated with adequately emphasizing the role of systems engineering. It is based on principles EADS is establishing for an EADS‐wide standardized but versatile approach appropriate for the wide range of products and services offered by the EADS Divisions Airbus, Astrium, Cassidian and Eurocopter. Currently the defined and agreed concepts are further progressed and implemented.
5.5.2 Connections in System of Systems
Authors: Osmundson John S. , Langford Gary O. 
Published: November 2014

AbstractSystems of systems are becoming more important in today's global endeavors. In this paper use of model‐based systems engineering is examined from the viewpoint of understanding connections, that is the transfer of items between system of systems. The conclusion is that systems engineering models must include executable models in order to best understand the effects of transfer of items in system of systems.