bluuebunny/crossref_metadata_2025_split huggingface dataset:
5.4.2 Applying Systems Thinking to Expatriate Selection
Authors: Chapin Gregory G. , Martinez Zaida L. 
Published: November 2014

ABSTRACTA key factor in expatriation success starts with an effective selection process. Unfortunately, the expatriate selection process is often rushed and unstructured, resulting in poor expatriate performance or the cancellation of assignments. Systems thinking can provide structure and discipline to improve this process and, thus, expatriates' performance potential. Systems thinking can also assist corporations in defining expatriate selection as a problem that can be solved through developing a methodology that adequately addresses the problem, delineates feasible solutions to the problem, and provides feedback to improve the methodology used. Furthermore, such methodology can reduce selection costs and enhance expatriate performance. This paper shows the need for systems thinking in expatriate selection and describes how a systems methodology may be applied to expatriate selection.
5.4.4 Revisiting Accumulated Wisdom After 100 Years Of Engineering Railway Systems
Authors: Williams John , Allan Jeff , Jin Jenny Q 
Published: November 2014

ABSTRACTThere are a number of reasons why new types of segmentation of railway systems are worthy of consideration, e.g.:
New technology, particularly applied to communications and computing,
Operational economies and improvements to the recovery from disruption provided by the centralisation of control of railways,
The impact of traction power supply on both the future environment and on the diminishing fossil fuel sources,
Major changes in methods of funding large railway projects,
The extensive use of Outsourcing of maintenance and other services,
The vision that railways are part of an integrated transport system implying a need to take a flexible approach to the developing external interfaces.The implications of these, together with the increasing emphasis on safety and the railway customers needs has resulted in a re‐evaluation of the traditional approach to railway system architecture.
5.4.5 Introducing System Engineering into a Traditional Steel Making Environment
Authors: Duggan Peter J. , Groenewald Johan 
Published: November 2014

ABSTRACTThis paper discusses the lessons learnt from the introduction of the System Engineering process into a Steel Manufacturing organisation which had decided to develop a new technology. Some of the reasons for using the SE approach and the benefits obtained are discussed, as well as the pitfalls encountered. Many of the lessons are, we believe, applicable to Systems Engineering in general, and to commercial applications of system engineering in particular. A process approach is stressed.
2.5.1 Systems Engineering Standards and Models Compared
Authors: Sheard Sarah A. , Lake Jerome (Jerry) G. 
Published: November 2014

ABSTRACTCurrently there are five systems engineering standards in various stages of release and three systems engineering capability models. This makes it difficult to know what to use as a basis for process improvement. This paper discusses the similarities and differences among the standards and models. The standards have been evolving from the U.S. Military to international and commercial, with recent standards taking a broader scope. Two capability maturity models have been merged into a third, which is tied to the standards.
2.5.2 Key Features of the “Merged” EIA/IS 731–1 Systems Engineering Capability Model
Authors: Widmann E. R. 
Published: November 2014

ABSTRACTIn the past few years, several models have been developed to measure systems engineering process or capability maturity. Two models, the INCOSE SECAM and EPIC SE‐CMM, have gained a great deal of attention and have been used as source models, along with their application methods, to create a US standard, comprised of a single “merged” model and application method, for measuring and improving systems engineering capability. The “merger” effort has been conducted by the EIA SECM Working Group, which has representation from the EIA, INCOSE, and EPIC and was formed under the auspices of the Electronic Industries Association (EIA). This paper provides key features of the “merged” model, a synopsis of each of the two source models, and relationships between the “merged” model and its two source models. A description is provided of some significant factors affecting the merger effort. The information provided should assist in gaining an understanding of, and in transitioning to, the “merged” model, which is the EIA/IS 731–1 Systems Engineering Capability Model (SECM).
5.5.4 A Soft Systems Methodology to Support Business Process Change Towards Concurrent Engineering
Authors: Clegg Ben , Boardman John 
Published: November 2014

AbstractThis paper discusses the fundamental commonality of ‘total quality management’ (TQM) and ‘business process reengineering’ (BPR) that originates from their roots in ‘systems thinking’. The authors draw on the same ‘systems thinking’ origin to develop a new soft systems methodology known as the Boardman Soft System Methodology (BSSM). The BSSM has been evolved specifically for modelling business processes to support change management initiatives such as BPR and TQM. Evidence is given in a case study which reports on improving the use of concurrent engineering (CE) tenets in a medium‐sized engineering firm.
1.6.3 A Quantitative Metric of System Development Complexity: Validation Results
Authors: Thomas L. Dale , Mog Robert A. 
Published: November 2014

ABSTRACTEach day, engineers cope with the challenges of building complex systems – challenges which place the project cost, schedule, and technical performance at risk. Can a measure of the inherent complexity of a system provide any insights regarding the risk to cost, schedule, and technical performance? Perhaps it can. This paper briefly reviews the development of a complexity metric and subsequently presents results from a validation assessment. These results indicate a significant relation between system complexity and program development cost.
2.6.2 Innovation in the Context of Systems Engineering
Authors: Walden David D. 
Published: November 2014

ABSTRACTThis paper analyzes the relationship between innovation and Systems Engineering. Innovation is essential in high technology companies. However, System Engineering's emphasis on process, documentation, and control is often perceived to inhibit innovation.We performed an in‐depth literature search on the topics of innovation and Systems Engineering. This research led to the conclusion that Systems Engineering is basically consistent with innovation, with the recognition that radical innovation may require special consideration. We also provide suggestions for better accommodating innovation within Systems Engineering.
7.2. CEENSS and Simulatable Specifications – A Progress Report
Authors: Driver L. , Thullen M. , Gearhart L. , Winn A. 
Published: November 2014

ABSTRACTThe Continuous Electronics Enhancements using Simulatable Specifications (CEENSS) project was begun in 1995 to define a methodology and provide CAD/CAE tools to improve the electronic design process. More specifically, TRW, along with the University of Cincinnati, Motorola and Mentor Graphics, is defining the system requirements methodology for applying formal methods to the specification of board/module‐level products, and the associated impacts to the development process, tool integration, and electronic data interchange (EDI). A key activity of the project is the definition of a Simulatable Specification (SimSpec) that is compatible with and complementary to the methodology. Now in its fourth and final year, CEENSS has met most of its objectives and will achieve additional goals in 1998. This paper presents a CEENSS status report, focusing on accomplishments in enhancing CAD/CAE tools to support the CEENSS methodology.
7.5. Development of the Reference Design Description for a Geologic Repository
Authors: Daniel Russell B. , Rindskopf M. Sam , Teraoka Gary M. 
Published: November 2014

ABSTRACTAs the Management and Operating Contractor for the Department of Energy (DOE), TRW developed the “Reference Design Description (RDD) for a Geologic Repository.” The document describes the current design expectations for a potential geologic repository that could be located at Yucca Mountain in Nevada. The Reference Design Description conveys the surface and subsurface repository and the disposal container design. Additionally, it presents the expected long‐term performance of the potential repository. This paper presents the systems approach used to develop the document. In addition, the role of the Reference Design Description in the overall systems design approach to the Mined Geologic Disposal Systems (MGDS) is discussed. Finally, the overall benefits provided to the Civilian Radioactive Waste Management System (CRWMS) and Yucca Mountain Project (YMP) by the Reference Design Description are discussed.
7.11. Lessons Learned in Applying the Capability Maturity Model to Systems Engineering Process Improvement
Authors: Johnson Howard , Breininger Alan 
Published: November 2014

ABSTRACTGDE Systems has initiated a systems engineering process improvement program to align with industry movement towards systems engineering process maturity, improve risk management, and focus on up‐front system requirements. The approach was to obtain the current state of the practice from the GDE Systems projects and from industry (INCOSE, SPC, etc). This information was used, together with the Systems Engineering Capability Maturity Model, to establish the company systems engineering process. The initial systems engineering policy and company operating manuals were then generated to establish the process requirements and to document the methodology. The projects were then internally assessed to determine their individual level. The results were used to improve the processes and prepare for a formal appraisal at the end of 1997. The formal appraisal was conducted and future actions were planned to meet Level 3, 4, and 5 goals.
7.12. LPD 17: Adding People and Profit to IPPD
Authors: Dube Chuck 
Published: November 2014

AbstractIn its contract for development of a new amphibious ship, the LPD 17, the US Navy required the use of Integrated Product and Process Development (IPPD). Raytheon Systems Company's Naval and Maritime Systems (NAMS) is one of the four members of the partnership which won the contract. NAMS is leading the Integrated Ship Electronics Team (ISET), the top‐level LPD Integrated Product Team (IPT) responsible for integrating the ship's electronic systems. In a unique adaptation, ISET purposefully enhanced its implementation of IPPD by special emphasis on two additional “Ps” people and profit. This “IPPPPD” approach produced some significant changes in certain program practices and activities. The focus on people manifested itself in how the program chose its team leaders and team members, how it aligned the individual teams and its team structure, and how it shaped the behavior of its people to support its IPPD practices. Its emphasis on profit required its teams to take responsibility not only for their technical work, but also for the related programmatics and contract issues.
7.13. Process Management for Skeptics (or The Case for Process Management in Modern Naval System Development)
Authors: Steiner Rick 
Published: November 2014

ABSTRACTThe need for large, complex systems has fostered a need for large, multi‐disciplined organizations to design, build, and maintain them. At the same time, customers of large, complex systems are demanding unprecedented levels of efficiency and quality. To achieve these demands, builders of complex systems must employ a formal mechanism for managing their design and development processes. Understanding and controlling top‐level processes across large multi‐disciplined organizations, alliances, or consortia, is referred to as “Process Management”. To be successful, any process management activity must have the understanding, input and support of all key participants. This paper was originally developed as a step in getting that understanding and support, especially from domain specialists without any process engineering experience. The arguments presented here are applicable specifically to a large Navy development program, but they may be useful in gaining process management understanding for the development of other complex systems.
7.18. Systems Engineering for Software and Hardware Systems: Point‐Counterpoint
Authors: Sheard Sarah A. 
Published: November 2014

Abstract1Why has a problem between “systems engineers” and “software engineers” been documented every year of INCOSE's existence? Is it because there is a difference between systems engineering of hardware‐intensive and systems engineering of software‐intensive systems, and this difference is not understood or respected? This paper presents several of the issues involved and presents opposing factors for consideration by those who will have to face them, such as hardware systems engineers addressing systems with more and more software components.The author posted fourteen assertions, based on personal experience, to the INCOSE discussion list server. Twenty responses2were received, providing views, examples, and additional information. Respondents agreed on a number of differences between the systems engineering currently performed on software systems and that on hardware systems. Those differences are thought to be decreasing as software evolves as a field. Recommendations are made for changes that may improve both dialogue and system development.Open questions generated by the discussions are suggested in the hopes that research efforts may address questions of importance to the improvement of the engineering of systems.
2.1.1 Thought Systems, and Thought Warfare and Anti‐Warfare
Authors: Burke Martin 
Published: November 2014

AbstractThe notion of Thought Warfare and Anti‐Warfare (TWAW) has been introduced in earlier work as a way of thinking about future military conflict and its avoidance. TWAW involves the dynamic interaction of allies' and adversaries' Thought Systems. Current Thought Systems involve entities capable of cognition, emotion and volition ‐ typically (groups of) people ‐ interacting via networks of information and data systems.This paper summarises a conceptualisation, ie a system of ideas, of the domain of Thought Systems. This affords various new insights that may be of significance to both the Defence and systems thinking communities.
2.1.3 Systems Engineering in Support of Defence Logistics
Authors: Wright D M H 
Published: November 2014

AbstractThe paper examines the application of Systems Engineering (SE) principles to the complex system that is Defence logistic support operations. This system exists at a hierarchy level above that usually considered by SE and is distinct from the more traditional project or product view of a system. The establishment of a unified Defence Logistics Organisation in UK and its ambitious programme of change are described. Central to this programme is the gathering of information to understand and to manage the system more effectively. The paper proposes a programme of modelling and simulation should be established to make best use of the information. This would enable a more accurate understanding to be developed of the dynamic behaviour of the system. If this were achieved, then measures for change and improvement could be introduced, using the principles of systems engineering, thereby making a successful outcome in this complex setting more likely.
4.1.3 Smart Information Architectures – Systems Engineering Information within an Enterprise
Authors: Schulz Armin P. , Igenbergs Eduard , Wehlitz Pamela 
Published: November 2014

AbstractIn the past decades the world has been changing in almost every aspect. Systems development is facing ever rapidly changing and increasingly global environments in markets, competition, technology, regulatory and societal systems.The resulting increase in complexity within system development can be only handled by mastering the information describing the system (product development data)1. In most companies product development data is captured in an extremely heterogenous environment, that is various proprietary tools along the development processes request, manage, and provide product data. The heterogenity is causing user perceived information losses, in terms of redundant or inconsistent, incomplete, reduced, or mismatched information.Four properties (user orientation, integrity, adaptability, intelligence) of smart information architecture to overcome these shortcomings are introduced. A structured approach to model and analyze the existing information landscape of an enterprise, to develop a reference architecture incorporating the proposed properties and migrate the existing one, is developed and discussed. An application of the model within an automotive environment and the subsequent implementation of the results within a PDM‐system provide valuable insights as well as validate the basic applicability of the model.The results presented are based on various research projects with industry the authors have been involved in and in particular a Ph.D. thesis in preparation [Schulz, 2001].
4.1.4 Definition of Enterprise Architecture‐centric Models for the Systems Engineer
Authors: Osvalds Gundars 
Published: November 2014

AbstractEnterprise Architecture definition provides guidance to the systems engineer so that the enterprise system better reflects the needs of the customer. With the current systems engineering approach, the systems engineer can allocate requirements to systems without considering enterprise‐wide considerations. The architecture‐centric approach for system design provides enterprise‐wide information for systems engineers, who can utilize it to affect systems design. This paper describes Enterprise Architecture and related concepts, and explores the state of the art of Enterprise Architecture and Enterprise Architecture frameworks. The Zachman Framework is used as the basis for creating models of the architecture. This paper proposes a bridging concept to define the models for the architectural perspectives. The bridging process provides a traceable methodology for developing architectural models of the enterprise that are directly traceable to the Zachman Framework primitives, thereby ensuring that the architecture models all elements that are necessary to completely describe the enterprise.
5.1.4 The Benefits of Integrated, Quantitative Risk Management
Authors: Roberts Barney B. 
Published: November 2014

AbstractThere is no question that risk management (RM) has a value much greater than its financial cost for implementation. Hall1reports return on investments (ROIs) on the order of 20–1. While our experience supports this finding, we believe that the return would be much higher given comprehensive metrics. To date, we have been unable to compile metrics as Hall has done because of the collateral effects that occur in application. Thus, we cannot calculate the true cost avoidance based solely on the application of risk management. This occurs because our approach is intense, focused on quantitative analysis, and designed to produce risk‐based decision support information for decision‐makers. We have dubbed the process risk‐based decision support, (RBDS). A particular characteristic of RBDS is the requirement that an ‘integrated’ result be presented to the decision‐maker. That is, the decision‐maker must have a result that integrates the various risk factors (i.e., cost, schedule, technical, mission, etc.) into a single, consistent, parameter for decision‐making – usually cost.The execution of such a risk management process means stringent demands for quality information are levied on projects. In fact, the coincidental discovery of deficient information during the process has yielded the greatest benefit to programs we have supported with RBDS.Qualitative techniques typically result in subjective risk estimates of likelihood and consequence such as high, medium, and low. Our intent is not to be critical of qualititative techniques; as a matter of fact, we use them. Furthermore, we find great value in qualitative processes, as they yield quick and efficient communication of risk issues across the program/project.However, we always go one step further. We implement a triage procedure to discriminate the ‘high’ risks that require further analysis usingquantitativetechniques. These quantitative techniques demand quality information from within the program. Typically, examples of deficient information discovered in our application of RBDS include low‐quality program plans, poor cost estimation, missing project elements, inconsistent integrated master plans and integrated master schedules, poor system‐level requirements, and unstable requirements. Each of these deficiencies themselves constitutes a risk to the program.In the following pages, we present a discussion of these management risks and how their identification has contributed to the success of numerous programs and projects. For some of our cases, we will provide semi‐quantitative judgments about the ROIs for RM.
6.1.1 Systems Thinking for Managing Projects
Authors: Mawby Dave , Stupples David 
Published: November 2014

AbstractSystems thinking is a discipline that has developed substantially over the last few decades but most project managers remain unaware of its potential power in helping analyse, refine and deliver their complex projects. In fact, over the past 30 years several hundred of the world's largest and most complex projects have successfully used the technology to improve their outcome. Traditionally, a time‐consuming technique to implement, it has only been utilised for the most complex projects. However, these methods are fast becoming more accessible for large projects in general.Through modelling the rework cycle and the feedback loops that drive it, using system dynamics it is possible to analyse and hence improve the dynamic behaviour of our projects. In this paper we show how a system dynamics model of a project is constructed and used to assess project outcome. Examples of its application include: cost versus schedule trade‐offs, project improvement strategies, risk assessment and assessing resource constraints. The ability to deliver such answers quickly and accurately during the bid and project definition phases provides the project management team with a powerful decision making tool for project strategy formulation. The improvement in project outcome that can be achieved at this stage of the project is massive because of the low cost of change combined with a high leverage into project commitment, risk mitigation and outcome that is available early in the project's lifecycle.
2.2.2 System Safety – A Medical Perspective
Authors: Elahi Bijan 
Published: November 2014

AbstractThis paper examines safety aspects of medical devices such as: electronics, software, biological, toxicological, physiological, environmental, and even psychological factors. The views of different regulatory bodies in the world on approvals of medical devices are compared and contrasted. Examples of tradeoffs in design of medical devices and issues that face medical device engineers are presented. Risk assessment and mitigation techniques are discussed. Also, legal aspects of medical device safety are visited.
2.2.3 Simplifying Risky Business: An Improved Risk Management Approach
Authors: Shoults John 
Published: November 2014

AbstractThe Risk Management process used on the Theater High Altitude Area Defense (THAAD) Missile Program is discussed. Approaches for integrating risk management activities based upon a simple risk sources checklist questionnaire, standardized assessment templates, and easy‐to‐use tracking templates are presented. The human aspects of implementation, the real keys to success, are discussed. Specific recommendations for achieving success are provided.