bluuebunny/crossref_metadata_2025_split huggingface dataset:
9.2.3 Successful Implementation and Application of Continuous Risk Management to Complex Systems Development in the Automotive Industry
Authors: Negele Herbert , Pfletschinger Thilo , Wenzel Stefan , Getto Gerhard 
Published: November 2014

AbstractCurrently, more than 90% of the innovation in the automobile industry is driven by new ideas in the electric and electronic sector (Frischkorn 2004). Due to the increased complexity of the electrics/electronics (E/E) system, car breakdowns today are more often not mechanical in nature, but are likely due to a defect in the electrics/electronics system (ADAC 2004). As a result the development of a more reliable automobile E/E system is a major concern for car manufacturers around the world in order to produce innovative and reliable cars and remain competitive.Besides sound requirements engineering and effective project management, the key to dealing with the increasing complexity of E/E system development is to identify potential system problems throughout the development process and respond with appropriate actions to mitigate potential adverse impacts and thus achieve the project objectives. This issue can be accomplished by implementing a continuous risk management (RSKM) approach focused on the development of the E/E system.This paper illustrates a practical, proven approach applied to new product development at the BMW Group. The approach enables proactive risk identification and mitigation to obtain more transparency in the development of the complex E/E system of an automobile.
9.4.2 Improving process evolution using ideas from the Venture Capital industry
Authors: Rogers Derek , Beukman Piet 
Published: November 2014

AbstractThis paper provides a coherent framework for process evolution and new product introduction. The approach overcomes common limitations with process evolution including:

Opportunity driven; rather than directly linked or driven by an organisation's strategic goals.
Non‐standard methods within an organisation, for example, in the approach used for calculating return on investment if such explicit calculation exists.
Neglect of resource availability, skill needs and organisational change management.
Neglect of the timeliness or window of opportunity.
10.1.3 Agile SYSTEMS ENGINEERING versus AGILE SYSTEMS engineering
Authors: Haberfellner Reinhard , de Weck Olivier 
Published: November 2014

AbstractThis paper explores recent developments in agile systems engineering. We draw a distinction between agility in the systems engineering process versus agility in the resulting system itself. In the first case the emphasis is on carefully exploring the space of design alternatives and to delay the freeze point as long as possible as new information becomes available during product development. In the second case we are interested in systems that can respond to changed requirements after initial fielding of the system. We provide a list of known and emerging methods in both domains and explore a number of illustrative examples such as the case of the Iridium satellite constellation or recent developments in the automobile industry.
11.4.2 Managing Priorities: A Key to Systematic Decision‐Making
Authors: Gilb Tom , Maier Mark W. 
Published: November 2014

AbstractA central concern of systems engineering is selecting the most preferred alternatives for implementation from among competing options. The selection process is sometimes called tradeoff analysis, and is often built on the methods of decision analysis and utility theory. The process can be loosely divided into two parts, a first part in which one determines the relative priority of various requirements, and a second part, a design selection phase, in which alternatives are compared, and the preferred alternatives chosen.This paper discusses the means of determining the priority order for implementing system changes. It also outlines the implications on the selection process of evolutionary systems development.
1.1.2 Defining the “Trade Space” for CAIV Optimization Using a Cost Model Derived from Linear Regression of NASA Project Data
Authors: Krupa Joseph F. , Componation Paul J. 
Published: November 2014

AbstractIn 1995, Dr. Paul Kaminski, then Defense Undersecretary for Defense for Acquisition and Technology, established the principles of CAIV—“Cost as an Independent Variable”—to take advantage of aerospace's experience using Target Cost to battle the escalating cost of defense systems in a time of declining procurement and development dollars.One of the key tenets of CAIV is to limit Key Performance Parameters (KPP) to the critical few, to establish thresholds and desired levels of performance, and to trade off performance, cost and schedule. This trade arena is called the “Trade Space”. Although a number of authors have proposed methodologies for performance, cost and schedule trades, a clear process has not emerged. One difficulty that emerged from study was how to use existing cost estimating systems to perform “Trade Space” optimizations. This paper presents the use of a cost model derived from log linear regression analysis of data from eighty‐six NASA projects, the Analytic Hierarchy process, and non‐linear optimization to show how CAIV “Trade Space” can be developed from cost data.
1.3.2 Context‐Based Measurement of Requirements Instability
Authors: Biddle Mark , Moritz Shelly 
Published: November 2014

AbstractRequirements instability has always been and continues to be one of the more significant challenges for system development programs. Historical results across industry show that programs struggle and often fail to achieve stable and mature requirements baselines, and the impact of requirements instability on program cost, schedule and technical baselines is significant. This paper looks at some of the factors that affect requirements instability, and it outlines an approach for measuring requirements instability that takes contextual influences into account in order to provide insight as to why the requirements on a given program are unstable.
2.2.3 Directed Energy Weapon System Architecture to Meet Network Centric Operations Requirements
Authors: Marbach Phyllis R. 
Published: November 2014

AbstractNetwork Centric Operational Warfare (NCOW), the Global Information Grid (GIG), a typical Directed Energy (DE) Weapon System, and elements within a Battlespace that the DE Weapon would communicate with, are concepts introduced in this paper. NCOW requirements are described as applied to a weapon system, a DE weapon in this application, but the requirements and the solution proposed could be applied to other systems as well. This paper introduces a general DE Weapon and an architecture that meets the attributes described in the DoD Net‐Centric Data Strategy.
2.3.2 Towards a Work Breakdown Structure for Net Centric System of Systems Engineering and Management
Authors: Wang Gan , Valerdi Ricardo , Lane Jo Ann , Boehm Barry 
Published: November 2014

AbstractAs the system engineering industry sees an increasing focus on the lifecycle development, acquisition, and sustainment of net‐centric Systems of Systems (SoS) and Family of Systems (FoS), organizations find the need to evolve current processes and tools to better handle the increased scope, scale, and complexity of these efforts. One such tool, the Work Breakdown Structure (WBS) is important in planning and execution of program activities as requirements and goals of the program evolve. This paper provides an overview of the limitations of current WBSs with respect to SoS efforts and presents a proposed WBS structure that more adequately reflects the evolving processes and cross‐organizational complexities.
2.3.3 Uniting Three Families of Risk Management–Complexity of Implementation × 3
Authors: Holzer Thomas H. 
Published: November 2014

AbstractThis case study presents how a government agency overcame difficult challenges to establish a solid foundation for the management of its three families of risk‐ program, enterprise, and joint enterprise. Establishing an efficient and effective risk management process in a single development program is very challenging‐ culture resistance to change and unwillingness to share information viewed as negative prevail. There is additional complexity convincing people to adopt a process that is part of the bigger organization and sharing information regarding their ability to achieve program objectives. Now convince two different organizations to share information with each other. The outcomes show how the process can be scaled, adapted, integrated and adopted across the complex systems and diverse organizations and enable program teams to identify, assess, and mitigate complex risks. For an organization aspiring to establish an internal or joint enterprise risk management program, these findings are a head start.
2.4.1 Evolution of a Standard EIA‐632 From 1994 to 2006
Authors: (Rich) Harwell R.M. 
Published: November 2014

AbstractProcess standards represent the best practices used by an industry or discipline. Most process standards are usually created by volunteer teams operating under the auspices of an authorized standards development body such as the Government Electronic and Information Technology Association (GEIA). This paper examines the evolution of one standard from its inception in 1994 to its current revision activities, noting the factors influencing scope, content, and structure. It also provides an insight into the latest decisions affecting the current revision efforts.
4.1.1 Ten Design Principles: Some implications for multidimensional quantification of design impacts on requirements
Authors: Gilb Tom 
Published: November 2014

AbstractDesigns have multiple impacts on requirements, and can only be fully understood in terms of their impact on requirements. In other words, the contributions of designs towards the set of performance and resource requirements must be considered, when evaluating designs, in addition to their contributions to the function requirements.This paper sets out ten principles, and outlines their various implications for design. These are basic ideas about designs, which we should explicitly acknowledge, teach and use in practice. I would be surprised to find any serious disagreement about these principles, but I would be surprised to find serious conscious practice and teaching of them today!
4.1.3 i‐pub – Status, Insights and Visions
Authors: Herzog Erik , Pandikow Asmus 
Published: November 2014

AbstractThe i‐pub project aims at making INCOSE Symposia and other conference publications available on‐line on the INCOSE intranet. In this paper we present the status of the project, insights gained from analysing the material collected and our visions for future extensions of the i‐pub system.
4.4.1 Fine‐grained Method and Tool Integration for better Automotive Software
Authors: Altheide Frank , Buhr Kerstin , Doerr Heiko 
Published: November 2014

ABSTRACTIn the automotive field, software development methods and tools are used to cope with the high complexity of automotive software development. However, problems occur with the tracing of information, the assessment and monitoring of the development status, late and thus expensive changes, etc, which lead to increasing development costs and time as well as quality deficits. Our experience with recent projects have shown that the key to solving these problems lies in providing proper answers to the following questions: (1) How can development methods be assembled? (2) How can the use of a variety of development methods be supported by an appropriate tool?To answer these questions, we introduce a tool integration approach that is strongly based on the integration of development methods.The contribution of this paper is (a) a method integration approach that considers finegrained method objects and their specific structure in addition to the usually considered artifacts, (b) an approach to tool integration that overcomes the deficits of heterogeneous tool environments and utilizes the results of the methodical understanding.
5.1.3 Systems Engineering an INCOSE Chapter
Authors: Davies Paul 
Published: November 2014

AbstractIn this paper, the setup of INCOSE UK is used as a case study ‘infrastructure project’, an example of a ‘peopled system’. To begin with, the ad‐hoc developments in the typical formation stages of an INCOSE chapter are shown, and this is used to point out the relative immaturity of the processes from a systems engineering point of view. Then we look at how we made the Chapter more self‐sustaining, by a strategic overhaul of the ‘system’ using SE principles:
Business Case drivers
Stakeholder Identification
Stakeholder needs (requirements) analysis
Architecting the Organisation
Allocation of system requirements to organisational responsibilities
Decision analysis of likely return on effort invested
Validation and Verification via Event Q&A surveysComparisons are drawn with IEEE1220, EIA632 and CMMI. Finally, the Metrics that we have recently started to examine are presented, as evidence of increasing maturity of the process.
5.2.1 A National Approach to Systems Integration Skills Base Development in Australia
Authors: Cook S. C. , Sciacca L. , Bates B. , Nandagopal D. , Allison S. , Shackleton D. , Yates A. 
Published: November 2014

AbstractLarge‐scale systems, such as rail networks, air traffic control systems, and networked defence systems are vital to national well‐being. However, modern systems are becoming increasingly complex in nature and their development is proving problematical both in Australia and around the World. The paper opens by describing the nature of the problem and the best‐practice approach taken to overcome the difficulties. From here, the Australian needs for systems integration research and skills development are discussed. Finally, the paper outlines the approach taken to create a research concentration in systems integration that will form a coherent basis for a national response to the Nation's systems integration research and skill‐base capability requirements.
5.2.3 Capitalizing on Systems Engineering
Authors: Sherey Jason J. 
Published: November 2014

AbstractProject managers often find it difficult to justify allocating significant resources and schedule to systems engineering tasks when “real” engineering has to be done. With ever‐decreasing time to market demands, systems engineering continually loses out to design, integration, and test. A new method of systems engineering called Pattern‐Based Systems Engineering (PBSE) enables companies to transfer portions of systems engineering costs out of project specific budgets and into company capital asset accounts. Such a change in accounting provides a series of benefits that include improved documentation and management of core corporate intellectual property, best practices, and standards as well as not having to reserve as much precious project money on tasks that need constant re‐justification to product development managers with typically constrained budgets. This paper reviews PBSE, relevant accounting standards, and how much of systems engineering can be performed as a company‐wide capital asset development program instead of as project overhead.
6.2.1 Tradeoff Studies and Cognitive Biases
Authors: Smith Eric D. , Bahill A. Terry 
Published: November 2014

AbstractTradeoff studies involving human subjective calibration and data updating are often distrusted by decision makers. A review of objectivity and subjectivity in decision making shows that Prospect Theory is a good model for actual human decision making. Similarities between the elements of tradeoff studies and the elements of experiments in cognitive science show that tradeoff studies are susceptible to human cognitive biases. Examples of relevant biases are given.
6.3.4 Impact of Embedded Software Technology on Systems Engineering
Authors: Doyle Laurence , Pennotti Michael 
Published: November 2014

AbstractSystems such as aircraft and consumer electronics have included embedded computers in their designs for several decades now. In these systems, software was usually treated as a component inside a box much the same way you would treat a circuit card assembly or a power supply. Requirements would flow down to the box specification and the box specification would then flow down to the components inside the box. But recently, several trends are changing the relationship between embedded software and the system as a whole. Many embedded computer systems now use network protocols and infrastructures similar to information systems deployed on commodity hardware. Systems with embedded computers now have expectations and requirements for extensibility similar to those of information systems where methodologies for extensibility are well established. But unlike information systems, systems with embedded software often have complex non‐software elements and the software is not loosely coupled with the hardware. These systems require a synthesis of approaches.
8.1.1 Application of Systems Engineering to Industrial Supply Chains
Authors: Haskins Cecilia 
Published: November 2014

AbstractThis paper discusses the application of systems engineering alongside industrial ecology, systems dynamics and soft systems methodology to the study of industrial supply chains. As supply chains are ultimately a human activity, a multidisciplinary approach must include human‐centric investigation and knowledge‐sharing techniques. Systems engineering is seen as a proper foundation for defining a process for which the characteristics are unknown and for solving the problems found in cross‐organizational supply chains. Building on (Haskins 2003, 2004), Christopher Alexander's pattern language approaches are considered as a mechanism for sharing best practices. The paper closes with suggestions for the direction of further research.
8.3.1 Quantitative Analysis: Clawing your Way to the Top of the Maturity Pinnacle
Authors: Frenz Paul J. , Gurvin Anntoinette C. 
Published: November 2014

AbstractQuantitative Analysis is discussed at length in text books and articles. Statistical Process Control (SPC) articles address how you apply these principles, but real‐world application is the ultimate challenge. This paper describes tools, techniques and methods used to institutionalize Quantitative analysis in a Capability Maturity Model Integration (CMMI) Level 3 environment.General Dynamics Advanced Information Systems (GDAIS) Mission Systems achieved CMMI Level 3 rating June 30, 2004 using the CMMI‐SE/SW/IPPD/SS, V1.1, staged model.The goal: achieve a CMMI Level 5 rating before the end of 2005.
8.3.3 Use of Architecture for Engineering Systems; The Good, The Bad, and The Ugly
Authors: Osvalds Gundars 
Published: November 2014

AbstractMany programs have created architectures yet they have not been effective in producing viable results. The primary reason for this the ineffectiveness is derived from how programs are managed. While System Engineers perform engineering activities by developing artifacts; the complex relationships among engineering processes, the final products, and the creation of systems that meet customer expectations have not been well‐managed. Resolving this issue can be difficult. Even though Systems Engineering processes can provide guidance in Engineering Systems, it requires customer support and effort to make architecture actionable. To be successful in providing solutions, the Systems Engineer must apply Systems Engineering concepts to the customer's problems by educating the customer and assisting them to drive the system development effort. The author will present examples of “The Good,” “The Bad,” and “The Ugly” he has observed in U.S. Government Federal Agency and Department of Defense programs as it relates to the application of architectural engineering. Based on these tendencies, recommendations are presented to improve architectural effectiveness by urging a return to fundamental systems engineering principles and insuring that the customer is a solid stakeholder in upholding, supervising, and executing the architecture as an essential element of the new system or program.
9.1.1 Trade Study Cost Analysis Model
Authors: Casey Ed , Davis Desiree 
Published: November 2014

AbstractThe basic goal of a Cost‐Performance Trade Study is to find the optimum solution between several options that best balances cost, performance, risk and schedule given an agreed upon weighting.The Trade Study Cost Analysis Model was developed to support the CAIV trade study process by providing a means for the user to quickly and easily analyze alternative options. The model computes a rough order Life Cycle Cost (LCC) estimate for each study alternative, which can be compared giving the user a powerful input to the decision making process. The output should be considered a comparative estimate that is not the bottom line number, but rather the relative cost relationships between the alternatives. This model is not a bidding tool.The Trade Study Cost Analysis Model is primarily a predictor of Life Cycle costs and particularly Operation and Support (O&S) costs. Development and production costs are inputs to the model but not derived using the model. The Trade Study Model provides an estimate of the costs for the full life of the system/item being studied. While primarily hardware oriented, there is a software module embedded. The model has been designed to be used at the sub‐system and Lowest Repairable Unit (LRU) levels.Life Cycle Cost (LCC) Analysis is helpful to engineers in making decisions for trade study alternatives. They (LCC Analysis) are extensive and often require a great deal of time and resources to prepare.Included in this technical paper is the framework by which this model was created.