bluuebunny/crossref_metadata_2025_split huggingface dataset:
3.1.1 Systems Engineering for the Development of a Decision Support System to Help Manage the Railway Wheel ‐ Rail Interface
Authors: Thanh Vu , Roberts Clive , Williams John , Stirling Alan , Madelin Keith 
Published: November 2014

AbstractInteractions and interrelationships between the railway wheel and rail are complex, and managing them effectively would require an integrated systems approach. This paper describes how systems engineering has been applied to the development of a decision support system for the management of the railway wheel – rail interface. This work can be considered as a case study on the application of systems engineering in the railway industry. Stakeholder requirements, system functional requirements and architectural design of the system are described. A brief description of the prototyped system and its initial applications are also included.
3.1.3 Applying quantitative methods for architecture design of embedded automotive systems
Authors: Larses Ola 
Published: November 2014

AbstractArchitecture design is often referred to as an art, performed in the conceptual stages of a design process. However, it can be supported by quantitative methods. At the highest level of abstraction a goal oriented approach is applicable. This can be realized by a keyfigure based methodology similar to the management directed Balanced Scorecard.The automotive industry requires that a system architecture is optimised not only for a single product, but for reuse over a range of products, and also for reuse over time with continuous improvements. To achieve these goals the product should be modular. Keyfigures are useful for managing trade‐offs but do not easily describe modularity. For this purpose DSM (Design/Dependency structure matrix) and cluster analysis is more useful. A combination of the methods is proposed for design of automotive control system architectures. The proposed method has been applied and evaluated in architectural work at Scania CV.
3.2.3 Systems Reliability Demonstration
Authors: Benyamini Zvi , Zonnenshain Avigdor 
Published: November 2014

AbstractThis paper discusses the issue of system Reliability Demonstration. The classical reliability demonstration methods are discussed, as well as the difficulties associated with application of these methods in today's complex system and competitive project environment. Some insights are discussed, regarding the changes required in reliability demonstration methodologies, in order for them to be effective in today's environment ‐ from both RAFAEL's experience and trends throughout the world. The methods presented are being successfully implemented in several projects.
3.3.1 Quantifying Cost Risk Early in the Life Cycle
Authors: Kenley C. Robert , Nail James 
Published: November 2014

AbstractA new method for analyzing life cycle cost risk on large programs is presented that responds to an increased emphasis on improving sustainability for long‐term programs. This method provides better long‐term risk assessment and risk management techniques. It combines standard Monte Carlo analysis of risk drivers and a new data‐driven method developed by the Hoy and Hudak (1994). The approach permits quantification of risks throughout the entire life cycle without resorting to difficult to support subjective methods. The Hoy‐Hudak methodology is shown to be relatively straightforward to apply to a specific component or process within a project using standard technical risk assessment methods. The total impact on system is obtained using the program WBS, which allows for the capture of correlated risks shared by multiple WBS items. Once the correlations and individual component risks are captured, a Monte Carlo simulation can be run using a modeling tool such as Analytica to produce the overall life cycle cost risk.
3.4.2 How the Pro‐Active Program (Project) Manager uses a Systems Engineer's Trade Study as a Management Tool, and not just a Decision‐Making Process
Authors: Felix Arthur 
Published: November 2014

AbstractThis paper takes the Program (Project) Manager's (PM or manager's) point of view in strategic decision management when trade studies are used as the decision‐making tool. The application of trade studies as a tool in the strategic decision management process transcends commercial and defense industries. Industry, government, and academia projects can benefit from using this robust, structured decision‐making process discussed herein as a management tool in overseeing and providing guidance in the project's direction. The trade study created and developed by the systems engineer for decision‐making should follow a clear pre‐defined decision‐making process. Such a process would result in unambiguous interpretation and understanding thereby improving buy‐in from all stakeholders. The focus of this paper is the major stakeholders' acceptance, buy‐in and in understanding the underlying information and knowledge used in the trade study decision‐making process.The PM is responsible and accountable for the successful execution of a program (project) given the necessary resources. As part of those duties, he/she is responsible for making the major decisions of the program and will also be accountable for those decisions. The leadership/executive management can and should ask the PM to explain, defend, and demonstrate the decision‐making methodology used in each major decision. Those demanding answers may include but are not limited to Director level, Vice‐President/ President of an organization, Board of Directors, contracting agency, Government representative, and/or any other sponsoring stakeholder. There may also come the expectation by major stakeholders to reproduce the major steps in the methodology of the decision‐making process. This expectation should in‐turn, be demanded by the PM and come as no surprise to the systems engineer developing the decision making study thus establishing and enforcing accountability. The process used for the trade study in arriving at the recommended decision, as a matter of good engineering/business practice, should be documented and archived in the program artifacts for future reference.
4.3.2 Engineering and Implementing RMS Engineering's DTC Metric
Authors: Redman F. Quentin , Stratton George , Casey Ed 
Published: November 2014

AbstractArchitecting a product requires a defined set of requirements for the finished product; e.g. size, weight, volume, range, power, color, cost, payload, etc. One very necessary requirement is the anticipated product production cost. Failure to set the production cost requirements at design kick‐off allows for unexpected and unacceptable production costs. Previously, all too often, programs were allowing establishment of the production cost goal to slip, or they would wait for their customer to establish it for them. Raytheon Missile Systems' (RMS) Engineering Directorate has specified that all development programs will now establish a production cost goal using the Design‐To‐Cost (DTC) metric described within this paper and will monitor their design progress towards meeting this goal. Each program's DTC metric is now collected monthly and reviewed by senior management. This paper discusses creation of the RMS DTC metric, the metric's details and its implementation across RMS.
5.3.2 Didactic Recommendations for Education in Systems Engineering
Authors: Muller Gerrit 
Published: November 2014

AbstractTeaching systems engineering differs from teaching a mono‐disciplinary course, because the focus is much more on skills and less on transferable facts. The teacher must trigger a learning process in the students that stimulates the student to become active with the subject in a perceptive, reflective, and explorative way. This paper provides a number of recommendations for interaction, illustration, soft skill development, the use of media and student feedback.
6.2.2 Measuring the Performance of the Risk Management Process
Authors: Roberts Barney B. , Kitterman Richard 
Published: November 2014

AbstractMeasuring the performance of the risk management process is difficult in that there is generally no physical outcome to measure. The best risk management processes ensure that nothing “bad” happens, hence nothing to measure. Even when something “bad” happens, it could have been predicted by the process, accepted by the project, and the project got a bad roll of the dice, and the project may even face cancellation. But would that outcome indicate that the risk management process malfunctioned? So the problem faced by the risk management community is that either a good or a bad outcome can be a result of the performance of the risk management process or simply good or bad luck.The professionals in the risk management community and the measurement community have posed several possible ways to measure the performance of the process. Those techniques are presented along with suggestions as to how the project manager may use the metrics to make adjustments to the process.
6.3.1 The MSOCC Data Switch Replacement: A Case Study in Elicitating and Elucidating Requirements
Authors: Kasser Joseph E. , Mirchandani Chandru J. 
Published: November 2014

AbstractThis paper is a case study of a situation in which a soft‐systems methodology coupled with an object‐oriented approach for viewing the requirements was used in a complex environment to gather a set of requirements. By considering the cost, priority, and risk attributes of the requirements, as well as clarifying the wording of the requirements for verifiability, an optimal systems architecture and development process was achieved in a relatively short period of time compared with the standard systems engineering process. Moreover, the Systems Requirements Review was deemed complete and comprehensive by the customer.
7.1.1 Integrating Views in a Multi‐view Modelling Environment
Authors: El‐khoury Jad , Redell Ola , Törngren Martin 
Published: November 2014

AbstractThe development of modern technical systems requires the close collaboration of various specialist teams and engineering disciplines in order to reach the expected complex functionality. Even though working with the same system towards the same goal, developers from the different domains use their own specific tools, providing their own specific views of the system to be developed. For the successful integration of the efforts from each of these disciplines, the different views produced need to be appropriately integrated, preventing any inconsistencies and divergences from creeping into the system design.We present an approach to multi‐view modelling which systematically integrates the two generally accepted complexity reduction techniques of hierarchical decomposition and multi‐viewing. While these techniques are common practice in many modern design tools, the approach presented in this paper defines how the inter‐view relationships can be used to tightly interweave the views' hierarchies. This provides a good basis for an information sharing environment enabling model based, multi‐disciplinary development.A small case study is used to exemplify how the proposed method simplifies the process of allocating system functions to a hardware architecture in a truck.
7.2.2 Learning from Lessons Observed–Mitigating Resistance to SE Process Change
Authors: Holzer Thomas H. 
Published: November 2014

AbstractChanging a Systems Engineering process culture is difficult. There can be organizational and individual resistance to change that needs to be effectively overcome. As good systems engineering practices call for, at the start of the change activity the process change team needs to look back on the problems faced by similar programs. Most importantly, the team must learn from those ‘lessons observed’ and implement improvements in conducting their activity. Fifteen critical lessons observed about resistance and the mitigations applied are summarized. A highly successful process improvement program was achieved by applying mitigations learned from earlier problems. The lessons apply to changing SE processes in a government and commercial organization. For anyone seeking to change the culture and systems engineering processes, acquisition methods or business methods, these findings are their head start to identifying problems and reducing change activity failures.
7.2.3 Tailoring Systems Engineering Lifecycle Processes to meet the challenges of Project and Programme applications
Authors: Adcock Richard David 
Published: November 2014

AbstractThe application of Systems Engineering to real world problems relies upon an understanding of lifecycle and process. Many attempts have been made to produce generic models of Systems Engineering process, which can then be applied to real world problems. More recent Systems Engineering (e.g. ISO/IEC 15288 and ANSI/EIA 632) standards have taken a more abstract approach. The standards describe a lifecycle and process framework, and give guidance on how to tailor the framework to specific problems. This paper explores the approach taken by the standards to describe Systems Engineering in this way. The difference between a project and a programme are defined; and the application of lifecycle tailoring to each is discussed. Finally, a generic lifecycle framework is described, and examples of its application given.
7.3.3 A Lifetime Extension Strategy for Simulation Models
Authors: Grainger Steven 
Published: November 2014

AbstractUsing a systems engineering approach, a lifetime extension strategy for legacy simulation systems is presented. This lifetime extension strategy establishes a bridge allowing legacy simulation systems to participate in a larger more diverse simulation community. Previous recommendations to solve this legacy simulation problem have been narrow in scope viewing the solution in terms of a single technical solution. However, like systems engineering, this strategy describes a solution using a multilayered interdisciplinary approach. This approach takes advantage of existing technologies across the hardware and software spectrum and presents a five‐year convergence strategy.
8.2.2 A Mark‐Up‐Language to Support the Exchange of Requirements during a RFQ
Authors: Kaffenberger Ruediger 
Published: November 2014

AbstractRequirements are the foundation of the project. Consequently the issues of requirements management and requirements engineering are emphasized in the context of the preparation of acquisition activities and during the early phases of the development project. In contrast, the role of requirements management and engineering during the acquisition phase has received negligible attention. In a world where sub‐system developers compete against each others for development contracts offered by system integrators effective requirements management and engineering during the bidding phase is vital for success. A smooth exchange of requirements is needed in this situation but there are numerous obstacles. In this paper a solution for the necessary kind of requirements exchange is proposed. It is based on the possibilities of XML and the STEP information exchange standards.
9.3.1 Specialised Requirements Management system for Maintenance Service Industry
Authors: Chen Yang‐Cheng‐Kuang , Sackett Peter 
Published: November 2014

AbstractCompanies in major aerospace, automotive and electronics consumer products industries now consider Requirements Management important in realizing business performance. As companies review and enhance their product development processes they will increasingly demand various types of requirement management capabilities. There is lack of clarify on how to use Requirements Management effectively even in conventional product development applications.This paper identifies a research and applications gap in the Maintenance and Service Requirements Management System domain. The authors identify the special needs of the sector classified as Requirements Derived Service Maintenance. Through a case study in high end mass market consumer electronics they illustrate the application of the requirement management technique in the maintenance service environment.
9.3.3 System Engineering Application to Knowledge Intensive Service Industry Development Strategy and Mechanism Formation
Authors: Wang T.J. , Chang Larry , Chin David 
Published: November 2014

AbstractThe Taiwanese government realized the fact that the service industry has reached 67.8% of the national GDP in 2003, also recognized the successful outcome such as GE and IBM companies to shift from manufacturing to knowledge intensive service business. In order to keep a good momentum of GDP growth rate for Taiwan economic development, the government has to set out for a new industry development policy through Service Industry Program, which could meet with the needs of the existing service industry. It is very crucial to enhance their capabilities with modern technology and management, encourage them to join the feasible and profitable pilot system service projects. The major purpose of this program is trying to generate higher value added and/ or new business with innovation technology and new business model to create a new system service industry, which can be duplicated in the global market.
10.1.2 Canadian Capability Engineering Process Foundations
Authors: Mokhtari Marielle , Lizotte Michel , Lam Sylvia , Lalancette Claire , Dussault Geneviève , Couture Mario , Bernier François 
Published: November 2014

AbstractThis paper describes the fundamental characteristics (goals, scope, stakeholders, inputs/outputs and conception principles) upon which will be based the development of the first version of the Canadian Capability Engineering Process being investigating by the Department of National Defence and the Canadian Forces, to bridge the gap between the Capability‐Based Planning and Acquisition processes.
10.2.3 Guidance on Tailoring of Systems Engineering Processes for Quick Reaction Capability (QRC) Developments
Authors: Richstein Alan B. , Nolte Jerome T. 
Published: November 2014

AbstractAlthough the very basis for establishment of the discipline of systems engineering is grounded in development of large, complex systems, the principles and processes are also extremely valuable for other types of systems. As discussed in (INCOSE Handbook 2004) the responsibilities of systems engineers, that include “requirements analysis, functional analysis and allocation, architecture/design, systems analysis and control, and verification and validation of the system”, while “most apparent on large, complex systems … are also important in the development, production, deployment, and support of much smaller systems.”A Quick Reaction Capability (QRC), the focus of this paper, is a type of system development characterized by deployment of a critical capability to satisfy an urgent need in which the normal acquisition process is accelerated. That is, the driving requirement is the timely delivery of the system to operations. In this paper, we provide guidance on tailoring the CMMI processes for QRC developments to achieve mission success while satisfying the shortened development schedule. We assert that identifying and implementing the right SE processes is of even greater value for conducting a QRC development, precisely because time is such an important consideration.
10.3.1 The Producing System
Authors: Paul Arthur S. , Yerace Gary A. 
Published: November 2014

AbstractThis paper discusses the importance of the enabling resources (otherwise identified as enabling capacity or enabling capabilities) to the successful development of systems. It proposes the Producing System as a mechanism for planning, acquiring, deploying and managing these enabling resources as a system of interest, in addition to the delivered or required system, in the system development process.
11.1.2 A case study of multi‐disciplinary modeling using MATLAB / Simulink and TrueTime1
Authors: van den Bosch P.F.A. , van de Waal E.H. 
Published: November 2014

AbstractA big challenge in the development of complex machines is to evaluate the effects of early design decisions. This is because of 1) the multi‐disciplinary nature of such systems, and 2) the complexity of these machines. In this paper, it is demonstrated that it is possible to model essential system artifacts like timing and power usage for a complex machine, and obtain simulation results that can predict system behavior.As a case study, a model of the paper flow in a modern high‐volume printer / copier is made. This model focuses on timing and electrical power consumption. The model is validated using measurements on a real printer. It is shown that the model can be used to evaluate the impact of design decisions on the system.
11.1.3 The Nuts, Bolts and Duct Tape of Establishing a System Engineering Measurement Program
Authors: Frenz Paul J. 
Published: November 2014

AbstractWhile Software Engineering has a long history of conducting a measurement program, System Engineering (SE) is still in its infancy, in relative terms, in providing comparable measurement program guidance. This paper traces the establishment and institutionalization of a System Engineering Measurement Program.
11.2.3 Developing Section 4 Verification Text: Getting Early Buy‐In from Industry & Government Stakeholders
Authors: Haskins Bill , Striegel Jack 
Published: November 2014

AbstractDefining, designing & building a Large‐Scale Integration system is a daunting task. Even more daunting is proving that a system of that complexity meets the design requirements. The verification ‘proof process’ starts early on in a development program and the foundation is captured in the section 4 verification text, as defined in MIL‐STD‐961E, DoD Standard Practice, Defense and Program‐Unique Specification Format and Content. There have been numerous technical papers written to ensure that the section 3 requirements are verifiable, but few papers have been written to describe how to develop quality section 4 verification text. This paper describes a formal verification approach for developing quality section 4 verification text, with associated verification planning data, and getting early buy‐in from Industry and Government stakeholders in defining critical verification events, which is crucial to the success of any Large‐Scale Integration system.
1.2.2 Enhancing SE deployment in large organisations by proactively managing service quality of SE training and support services
Authors: Kossmann Mario 
Published: November 2014

AbstractWhen implementing Systems Engineering (SE) in large organisations, one key success factor that is absolutely essential for the acceptance of the related changes by concerned employees is the availability of high quality training and support services. For many such employees that are meant to start applying SE in their daily work, the first and arguably most important impression is the one given in the corresponding training session. Also, once they have completed the training needed for their level of involvement, it is crucial that they find the necessary support to get started and keep on track.The present paper will argue why it is worthwhile to proactively manage service quality when introducing SE in large organisations, give an overview of a proven Service Quality Management process for SE training and support services, illuminate the inherent advantages of such an approach and specifically look at a case study from Airbus, where the process in question has been used over a period of two years.