bluuebunny/crossref_metadata_2025_split huggingface dataset:
1.3.3 On the Alignment between System Architectures and Organizational Structures
Authors: Strandberg Tom , Burton Herb , Verma Dinesh 
Published: November 2014

AbstractEnterprises of today need to be agile in how they manage systems over their life cycle. The design of system architectures has received a lot of focus as a means to facilitate agility. Less attention has been paid to the relationship of the system architecture to the organizational structures of all of the entities involved in the system life cycle.A common, but inadequate, statement is that “the organizational structure shall mirror the product structure”. This research introduces processes as “middleware”, along with system architecture and organizational structure, to be included in the trade‐off for effective system life cycle management. Important additional factors that must be considered include informal organizational structures and the maturity of products, process and organizations.This paper suggests a model of the problem description and recommendations for further research that can be adopted by practitioners and researchers in the fields of both engineering and organizational design. The paper builds on a previous paper by (Strandberg et al 2006) and elaborates on, in particular, the aspect of maturity.
1.4.4 Introducing Structured Information Handling in Automotive EE Development
Authors: Malvius Diana , Redell Ola , Ritzén Sofia 
Published: November 2014

AbstractOne way for the automotive industry to cope with the demand of a more structured information handling is to adjust model‐based development (MBD) to multidisciplinary needs. Many of the issues faced in this transition are as much organizational and managerial as they are technical. In a case study carried out at a global automotive manufacturer a project to improve the electrical and electronics (EE) development has been followed and analyzed. The project originated from different needs identified by management in their ongoing work effort towards MBD as well as by developers who experienced that tools did not support their work situation. This paper describes how the introduction of a new tool support was made in a project carried out within EE development, further it reports on benefits achieved by using the tool. Both the effect on the work of affected EE developers and the expansion of a new information model are discussed, leaving important implications for management. Success keys for putting new support tools into practice are identified here and include; a bottom‐up approach, user involvement from the beginning, focus on the individual needs and adaptation to current work practice. Further, management support and adequate resources are essential for extracting long‐term benefits.
2.1.2 Designing Systems for Adaptability by Means of Architecture Options
Authors: Engel Avner , Browning Tyson R. 
Published: November 2014

AbstractSystems provide value through their ability to fulfill stakeholders' needs and wants. These needs evolve over time and may diverge from a fielded system's capabilities. Thus, a system's value to its stakeholders diminishes over time. As a result, systems are replaced or upgraded at substantial cost and disruption. If a system is designed to be changed and upgraded easily, however, this adaptability adds to its lifetime value. How can adaptability be designed into systems so that they will provide maximum value to stakeholders throughout their lifetime? This paper describes the problem and an approach to its mitigation.We adopt the concept of real options from the field of economics and extend it to the field of systems architecture. We coin the termarchitecture optionsfor this next‐generation method and the associated tools for the design of flexible systems. Architecture options provide a quantitative means of implementing the optimal degree of design flexibility in a system to maximize its lifetime value for varied stakeholders. Based on initial research to date, we believe that implementing this aspect ofdesign for adaptabilitycan increase a system's overall stakeholder value by 15% at a very conservative minimum. We also present an extension of a method for measuring the dynamic value of a system.
3.3.2 How Should We Use the Term “System of Systems” and Why Should We Care?
Authors: Cocks Dan 
Published: November 2014

AbstractAs an engineering discipline, systems engineering is relatively young. As this branch of applied science comes of age, it struggles with nomenclature and boundaries and roles of interaction with other disciplines. Yet before the foundations are quite set and cured, additional terms are being introduced to imply specialized subdivisions or independent offshoots of the yet‐ill‐defined context of systems engineering. This paper offers a proposed definition for “System of Systems” to distinguish it from “System” and “Family of Systems” that not only delineates the differences among these terms, but also postulates that there is value in recognizing these differences.
3.4.1 Technology and Obsolescence Sustainment for Integrated Systems
Authors: Herald Tom , Genaw Dennis 
Published: November 2014

AbstractLarge, network‐centric systems utilizing legacy elements, integrating newest commercial technologies and involving highly diverse joint‐forces and international stakeholders have increased the magnitude and complexity of systems development and, subsequently, the system sustainment. This forces the need for additional bottoms‐up tangible change management decision and optimization support for the systems and supportability engineers.This paper addresses two critical aspects in the context of system‐level obsolescence management. The first is System Obsolescence Life Cycle Forecasting and the second is Product and Technology Obsolescence Surveillance and Health Assessment. Proactive forecasting and assessment condense into a sustainment plan that encompasses the complete product operational life cycle. Product surveillance is the real‐time data monitoring mechanism that calibrates the accuracy of the forecast and the implementation plan. This paper provides recommendations specifically for the supportability engineer and the systems engineer in order to optimize the design for system affordability and to monitor change through market surveillance of the system baseline elements toward continued support of program decisions.This paper is broken into five parts in order to highlight the needs and solutions which apply to each life cycle phase. This provides a complete technology management strategy for an integrated system that is comprised of varying commercial technologies, readily available Commercial‐off‐the‐Shelf (COTS) elements, and required legacy systems.Part 1: Overview of Technology Management (TM) Requirements and Approach. Includes a discussion of the “life cycle mismatch” facing any operational system, wherein the desired system operation period is much longer than the life cycle of the constituent parts. This obsolescence mismatch must be managed at the system level to ensure program affordability.Parts 2‐4: Development, Production and Sustainment phase TM needs and solutions.Part 5: Conclusions and Recommendations. Two distinct TM variables are covered; the life cycle phases and the program complexity. Understanding these variables guides the systems and logistics engineers to an optimal operational solution.
3.4.3 Systems Engineering Net‐Centric solutions – an analysis of different perspectives
Authors: Crosby Gary , Kemp Duncan , Snell Dave 
Published: November 2014

AbstractThis paper reviews several different perspectives of net‐centric operations (NCO) identified by the INCOSE NCO working group. It is of one of three initial products of the group alongside a review of the Systems Engineering challenges posed by NCO and a literature survey of the state of the art in NCO.The paper uses elements of Checkland's Soft‐Systems Methodology to understand a range of different perspectives on NCO. It describes three different perspectives of the benefits of net‐centric approaches, four perspectives of what constitutes a net‐centric solution and four different approaches to realising net‐centric solutions.Finally the paper examines the relationship between the perspectives and draws some high level conclusions about the utility of the different approaches to different situations.
4.2.1 A Diagnostic Approach to Risk Driver Definition
Authors: Stump Evin 
Published: November 2014

AbstractBrainstorming is a commonly used approach to generating project risk drivers. A consequence of brainstorming is that many proposed risk drivers are superficial symptoms, or at best next‐level‐down proximate causes.Unfortunately, statements about symptoms and proximate causes are often assigned risk values such as probabilities or probability density functions. This paper will show that this practice can seriously overstate project risks. It can also lead to significant risk understatement due to issues of statistical independence.The paper will conclude by proposing a diagnostic approach that eliminates or at least minimizes this problem. It is based on root cause analysis using fishbone diagrams.
4.2.3 Systems Engineering Professional Development & Certification
Authors: Fisher Gerard H. 
Published: November 2014

AbstractIn the mid‐1990s, the Federal Government pursued “Acquisition Reform,” which resulted in significantly reduced government technical oversight of contractors. This caused less technical personnel to be hired in the government program offices for the last ten years. Recent investigations of space problems have recognized the need to revitalize the systems engineering workforce within the government program offices. Two years ago, the National Reconnaissance Office (NRO) embarked on the development of a professional development and certification program for space systems engineering. The NRO workforce is heterogeneous; it is comprised of military and civilian members of all DoD services as well as several intelligence community agencies. Our objective was to develop a program that maximized the synergy with parent‐agency programs and avoided any redundant training requirements. A three‐level certification program was established that required technical education, systems engineering experience, and systems engineering training. The training selected is a combination of existing NRO courses, off‐the‐shelf academic courses, commercial training classes, newly developed classes and INCOSE CSEP certification. After the first year, over 375 employees have attended at least one training class and we are certifying systems engineers at the rate of 10–12 per month. The success of this program has led to potential expansion into other areas of the government.
4.4.2 Lessons Learned from Synchronizing Complex Systems Development within Automotive Industry
Authors: Negele Herbert , Schmidt Reinhard , Finkel Stephan , Wenzel Stefan 
Published: November 2014

AbstractThe automotive industry has encountered fundamental changes in the last decade, e.g. increased international competition, more complex and diversified products, and strongly changing product development processes. Nowadays, electrical/electronic (E/E) systems play a crucial role in vehicle development in order to offer innovative and attractive products to customers. Therefore, it is vital for an automotive OEM to master E/E systems over the entire life‐cycle. Besides sound engineering, an effective project and risk management becomes more and more important. Synchronizing all the development activities and all involved stakeholders is a major challenge here. This is of key importance, as the E/E system represents a triplicate highly distributed structure, in terms of process, organization, and the product itself.This paper illustrates lessons learned from implementing synchronization management within the E/E system development as part of a major process improvement initiative. The paper starts by highlighting the paradigm shift within the development processes of an automotive OEM from “component‐driven” development to “system‐oriented” engineering. Based on this background the need for synchronization of all involved “players” within E/E system development will be pointed out. The development and implementation of a generic synchronization/master plan as well as the usage and tailoring of this plan for specific projects will be described. Also, embedding this E/E synchronization management within the overall vehicle development process will be discussed (e.g. how to handle changes within the development process). The paper finally highlights lessons learned during the phases of conception, implementation, and application of the generic master plan and the synchronization management process.
5.2.2 Optimizing Quality Assurance for Better Results
Authors: Malotaux Niels 
Published: November 2014

AbstractWe know all the stories about failed and partly failed projects. Apparently, too many defects are generated by developers, and too many remain undiscovered by checkers, causing too many problems to be experienced by users. Solutions are mostly sought in technical means like processes, metrics and tools. If this really would have helped, it should have shown by now.Oddly enough, there is a lot of knowledge how to reduce the generation and proliferation of defects and deliver the right solution quicker. Still, this knowledge is ignored in many development organizations.In a recent booklet: How Quality is Assured by Evolutionary Methods [2], I describe how to organize projects using this knowledge successfully. This paper extends the use of this knowledge to QA, in order to optimize the contribution of QA to project success. Important ingredients are: a change in attitude, taking the Goal seriously, focusing on prevention rather than repair, and constantly learning how to do things better.
5.3.3 SysML‐Based Systems Engineering Using a Model‐Driven Development Approach
Authors: Hoffmann Hans‐Peter 
Published: November 2014

AbstractMore and more, systems engineers are turning to the System Modeling Language (SysML) to specify and structure their systems. This has many advantages, including verifiability and ease of passing off information to other engineering disciplines, particularly software. This article describes a SysML‐based process that systems engineers can use to capture requirements and specify architecture. The process uses the SysML exclusively for the representation and specification of system characteristics. Essential SysML artifacts include use case diagrams, sequence diagrams, activity diagrams, statechart diagrams, and structure diagrams. The process is function‐driven and is based heavily on the identification and elaboration of operational contracts, a message‐based interface communication concept. The outlined process has been applied successfully at various customer sites.
6.1.1 The Application of Architecture Frameworks to Modelling Exploration Operations Costs
Authors: Shishko Robert 
Published: November 2014

AbstractDevelopments in architectural frameworks and system‐of‐systems thinking have provided useful constructs for systems engineering. DoDAF concepts, language, and formalisms, in particular, provide a natural way of conceptualizing an operations cost model applicable to NASA's space exploration vision. Not all DoDAF products have meaning or apply to a DoDAF‐inspired operations cost model, but this paper describes how such DoDAF concepts as nodes, systems, and operational activities relate to the development of a model to estimate exploration operations costs. The paper discusses the specific implementation to the Mission Operations Directorate (MOD) operational functions/activities currently being developed and presents an overview of how this powerful representation can apply to robotic space missions as well.
6.3.1 Threads of Reasoning: A Case Study
Authors: Sandee J.H. , van den Bosch P.F.A. , Heemels W.P.M.H. , Muller G.J. , Verhoef M.H.G. 
Published: November 2014

AbstractIn the design of technology intensive products like copiers, wafer steppers and televisions, one searches for a product that satisfies the product requirements as well as the business drivers. The main need in an early design phase is to bring structure in the typical chaos of uncertainty and the huge amount of realization options present. Potential realization choices all have advantages and disadvantages, which cause tensions and conflicts. The earlier the (essential) conflicts and tensions are identified, the better it is. Turning them from implicit to explicit helps the system architect in making the trade‐off consciously or at least in selecting the most important tensions and conflicts that require further in‐depth investigation. In this respect we demonstrate the effectiveness of a technique called “threads of reasoning”. The illustrative case study is the design of the paper flow control (sensors, actuators, control architecture, etc.) in a high‐volume copier/printer.
6.3.2 No Cure No Pay: How to Contract for Software Services
Authors: Gilb Tom 
Published: November 2014

Abstract50% of all software projects are total failures and another 40% are partial failures according to widely quoted surveys in UK, USA and Norway. Large government projects in all 3 countries have been reported with spectacular failure and expense to taxpayers (Royal Academy of Engineering and British Computer Society 2004). What is the problem? Most discussions have centered on improving the software engineering process itself: better estimation, better requirements, better reuse and better testing. No doubt all those can be improved. However, I suggest the motivation to improve them needs to be put in place first. Think about it. Most of these failures have been fully paid for! We not only pay well for failure, but the bigger the failure, the more people get paid!My suggestion is simple. Pay only when defined results are provably delivered. This requires several things:Contracts that release payment only for meaningful results;The ability to define those results, particularly qualitative ones, and particularly the organizational ones;The ability to deliver those results incrementally, thus proving capability at early stages and continuously.Note: This paper specifically addresses the software problem, but I am sure that the ideas here apply to the wider systems engineering problem to some interesting degree as well.
7.2.3 Tying Requirements to Design Artifacts
Authors: Briggs Clark , Sampson Mark 
Published: November 2014

AbstractA new generation of Product Data Management and Product Lifecycle Management tools offer a combination of systems engineering and design engineering capabilities with a common database. This provides the opportunity to tie requirements to elements of the design such as CAD models, drawings and analyses. Connecting the currently disjoint systems engineering and design engineering modelling domains provides a new opportunity for a rich set of relationships and the promise of alleviating much of the tedious checking of requirements usually performed by design engineers. This paper explores the use cases for joining systems engineering and design engineering modelling and proposes a set of relations that provide meaning to the new links.
8.1.3 Identification of Real Options “in” Projects
Authors: Wang Tao , de Neufville Richard 
Published: November 2014

AbstractThe concept of real options ‐ initiated in the field of finance ‐ has extended into engineering systems to model design flexibility in the realistically uncertain environment. However, whereas financial options are well‐defined traded contracts, real options “in” engineering systems are a priori undefined, complex, and interdependent. Moreover, systems involve many more options than designers could consider. Therefore designers need to identify the real options most likely to offer good flexibility and the most value.This paper proposes a procedure to identify real options “in” engineering systems. It consists of a screening and a simulation model. The screening model is a simplified, conceptual, low‐fidelity representation of the system that reflects its most important issues. As it is inexpensive to run, it is used to test extensively designs under dynamic conditions. The following simulation model is used to validate critical considerations, such as the robustness and reliability of the designs, which are omitted from the screening model in order to expedite its operation.The paper first establishes the concepts of the options identification model, and then resorts to examples to detail its application. The case of a hydro power system formulates the screening and simulation models, and presents the specific steps needed to search systematically for the interesting real options.
8.2.1 Establishing a Verification and Validation Process in Automotive Development: Increasing Product Quality while Reducing Costs
Authors: Meisenzahl Johannes , de la Cruz Marcelo , Vollerthun Andreas 
Published: November 2014

AbstractIn spite of continuous improvements in maturity levels of the electric/electronics development process, the structured verification and validation of automobile electric and electronics in all product phases takes on increasing importance. The methodology presented in this paper is based on the “5 dimensions” of verification and validation: what to “verify”, how, wherewith, when and by whom and focuses on a) the systematic planning and specification of verification and validation activities as a link between the requirements engineering and the testing itself, and b) the results of its successful user‐oriented implementation in an actual vehicle project of the BMW Group.This paper describes a proven methodology that contributes to handle the increasing complexity (e.g. caused by the multitude of variants) of automotive systems while still enabling innovations and premium quality. Further the organizational tasks, which must be met in order to customize the methodology to the specific project situation, are addressed.
8.2.2 Applying Systems Engineering to Naval Shipbuilding
Authors: Wells Brian H. 
Published: November 2014

AbstractThe processes for naval architecture and ship design evolved before the systems engineering processes used today were defined and documented. The standard systems engineering processes based on MIL‐STD‐499 and now ANSI/EIA‐632 have been extensively applied to the development of military and commercial products. While the designs of the naval ship combat system payloads have used systems engineering methods, the ship design, and development has traditionally applied processes that are unique and not included in the standard systems engineering activities. The development of many ship subsystems has followed an evolutionary approach that has not required many of the systems engineering process steps. This paper defines some of the unique challenges of applying the systems engineering process to the design and development of Navy ships. Some of the traditional naval architecture and ship design processes are presented and contrasted with the systems engineering standards. The challenges that required the amalgamation of these two cultures are discussed. Finally, processes and methods that provide an integrated approach are presented.
8.2.3 Giving the Integrator Role a Sporting Chance
Authors: Armstrong James R. 
Published: November 2014

AbstractAs systems become larger and more complex, there are more opportunities for playing the role of integrator in an expanding ‘food chain’ of layered development. Many organizations are seeking to increase their integration role and move up the ladder. This paper provides guidance on what that change means and requires. It also does so with an analogy to levels of play in the world of sports.