bluuebunny/crossref_metadata_2025_split huggingface dataset:
2.2.3 Observable States May be Necessary When Using COTS Products
Authors: Botta Rick , Bahill Zach , Bahill Terry 
Published: November 2014

AbstractIn order to use commercial off the shelf (COTS) products, the engineer must be able to prove that the COTS product is equivalent to the specified design. In most cases, this requires observable states, which are usually not available. Other techniques that have been used in lieu of proving system equivalence include creating multiple reset (or test) states and proving input/output equivalence with respect to these initial state pairs, designing built‐in self‐tests, building observers to estimate the system states and adding extra outputs that imply the states. This paper also gives examples where states are necessary and unnecessary in modeling systems.
3.2.2 Four Strategies for Reliability
Authors: Clausing Don , Frey Daniel D. 
Published: November 2014

AbstractReliability is one of the most important characteristics of a system. To be reliable a system must be robust – it must avoid failure modes even in the presence of the broad range of noise factors such as harsh environments, changing operational demands, and internal deterioration. In this paper we focus attention on “one‐sided” failure modes, which occur only on one side of a range of noises. Four effective strategies are presented for achieving improved robustness to one‐sided failure modes by conceptual improvements. Each strategy is illustrated through two examples from industrial practice.
4.1.2 A Model‐Based Requirements Database Tool for Complex Embedded Systems
Authors: Bennett Matthew B. , Rasmussen Robert D. , Ingham Michel D. 
Published: November 2014

AbstractIt has become clear that spacecraft system complexity is reaching a threshold where customary methods of control are no longer affordable or sufficiently reliable. At the heart of this problem are the conventional approaches to systems and software engineering based on subsystem‐level functional decomposition, which fail to scale in the tangled web of interactions typically encountered in complex spacecraft designs. Furthermore, there is a fundamental gap between the requirements on software specified by systems engineers and the implementation of these requirements by software engineers. Software engineers must perform the translation of requirements into software code, hoping to capture accurately the systems engineer's understanding of the system behavior, which is not always explicitly specified. This gap opens up the possibility for misinterpretation of the systems engineer's intent, potentially leading to software errors. This problem is addressed by a systems engineering methodology called State Analysis, which provides a process for capturing system and software requirements in the form of explicit models. This paper describes (1) how requirements for complex aerospace systems can be developed using State Analysis, (2) how these requirements inform the design of the system software, and (3) how this process has been aided through a State Analysis Database (SDB) and supporting multi‐platform client. The SDB provides a productive, collaborative development environment for State Analysis that is shared by both systems and software engineers.
4.3.1 Generic Measures of Effectiveness for Systems
Authors: Mackley Tim 
Published: November 2014

AbstractThe development of systems projects is often beset by problems because important parameters are not considered during their development. This paper sets out to determine a generic set of parameters for measuring the effectiveness of a system solution that can be used to compare different solutions, assess their development or consider strategies for replacement when in service. By consideration of a number of methods and models currently used within the domain of systems engineering, an attempt is made to produce a comprehensive list of measures of effectiveness.
4.3.3 Systems Engineering Measurement Primer – A Metrological Evaluation
Authors: Ferris Timothy L.J. 
Published: November 2014

AbstractThe paper presents the results of an investigation of the INCOSE Systems Engineering Measurement Primer from the framework of measurement theory. This approach to the Primer is outside the scope of the claims of the Primer, and so is not entirely fair to the authors of the Primer. This investigation is conducted in order to contribute to the development of measurement processes suitable for use in systems engineering and also to provide a theoretical framework for measurement of systems engineering processes.
4.4.3 Developing Requirements for Technology‐Driven Products
Authors: Wheatcraft Louis S. 
Published: November 2014

AbstractNew technology development is often a mainstay in product development, yet projects responsible for developing products based on new technology frequently are over budget, delivered late, poor in quality, and fail to meet customer and user needs and expectations. Two things that contribute to these problems are: 1) failing to define the product requirements up‐front and 2) failing to adequately manage the maturation of the enabling technology(s) needed. This paper introduces several key approaches and processes that address these issues and the many challenges of developing and managing requirements for technology‐driven products.
5.1.1 A Meeting of the Minds: A Successful Systems Engineering Experiment using Concept Maps for Effective Communications
Authors: BeVier John L. , Calimer Colleen A. 
Published: November 2014

AbstractAn informal experiment was conducted to test the effectiveness of communicating Systems Engineering concepts with customers using Concept Maps. The goal was to understand systems engineering concepts and techniques with customers using nontechnical diagrams, as well as to establish that the systems engineers had more‐accurately captured customer needs.In short, the experiment was about creating a more customer‐friendly vehicle that enabled dialog between the customer and the engineer, without asking the customer to comprehend “Systems Engineering‐speak“. This paper describes the customer/engineer communication problems found during the experiment, compares the effectiveness of Concept Maps and Use Cases for this experiment, describes Concept Map basics and the customer's reaction to them, and describes the proposed Systems Engineer's use of Concept Maps. The authors note that there are other, successful systems engineering communication methodologies and endeavors. They were not addressed in this experiment.Never‐the‐less, the result of the experiment was an enthusiastic and successful meeting of the minds, resulting in a successful shared customer/engineering vision. We offer our Concept Map findings for serious consideration in establishing both customer‐friendly and Systems Engineer effective communications.
5.1.3 Work Practice in Research: A Case Study
Authors: Martin Nathaniel G. 
Published: November 2014

AbstractWork practice analysis is a type of Ethnography that studies individual and group work. It has been developing at Xerox over the past 20 years. Recently, it was applied by a research group studying text mining. It showed flaws in the group's initial understanding of the problem and redirected the group's attention from classification to clustering. In addition, it led to the development of a novel approach to text mining. Further study showed that the novel approach is widely applicable. We describe work practice in general, then provide a case study of the application or work practice analysis to the gathering requirements for text mining. We conclude that work practice analysis in specific helps bridge academic results and industrial practice.
5.3.1 What can a project manager learn from an actor? ‐ improving professional skills through analogical thinking
Authors: Backlund Göran , Sjunnesson Jan , Josephson Erland 
Published: November 2014

AbstractA project manager with a holistic systems engineering perspective, encounters dilemmas and must make decisions on a daily basis. Traditional skills development programs are not well‐suited for these persons. Based on knowledge theory, a program has been developed that focuses on the practical knowledge that an experienced person has developed. The Dialog Seminar method has been used and tested on a group of project managers. At the final seminar of the program, the group met the well‐known Swedish actor Erland Josephson, and through analogical thinking, the project managers improved their understanding of their own professional roles through comparison with those of the actor and the director. The result is an awareness of the dilemmas, an ability to see them and meet them with improved security, and also insights on how they could improve their project management skills.
5.3.3 i‐pub – Towards Electronic Access to INCOSE Publications
Authors: Herzog Erik , Pandikow Asmus , Andersson Jonas 
Published: November 2014

AbstractOver the years a large number of high quality papers have been published at INCOSE symposia and conferences. However, the knowledge encoded in these papers is not easily available to INCOSE members. Symposia papers are generally only available to the attendees of the symposium where the paper was published, and then only in a format that does not supports structured access, considering today's technical possibilities.In this paper, we propose the implementation of an internet‐based INCOSE publication database (i‐pub) for facilitating access to INCOSE published papers. Results from initial prototyping activities are presented and an available COTS‐based software system is proposed for implementing the system.
5.4.1 RAS‐Centered Requirements Analysis
Authors: Grady Jeffrey O. 
Published: November 2014

AbstractSystem engineers for years have used the requirements analysis sheet (RAS) as a means of connecting the functions identified for a system under development with the corresponding performance requirements and product entities that should accomplish those requirements and functions. But we have commonly not extended the utility of the RAS to cover every requirement found in a specification. This paper extends the RAS to include every requirement that would be found in a system or hardware specification but it is no problem to extend it further to contain all requirements. Work continues to extend the concept to the several software modeling methods (modern structured analysis, early OOA, UML, and DOD AF). The content of the paper resulted from research undertaken during re‐write of the author's book “System Requirements Analysis” in preparation for its re‐publishing by Elsiver Publishing in November 2005.
5.4.2 Why Are Requirements So Hard To Get Right?
Authors: Carl Joseph 
Published: November 2014

AbstractThere are many instances in the history of system developments that illustrate how difficult it is to discover and understand system requirements in the same way that stakeholders understand them. This has resulted in cancellation of some programs, and has resulted in cost and schedule overruns on other programs. Misunderstanding of requirements is an acute problem in the development of systems for government agencies, but it appears in commercial developments, too, where it takes the form of products that fail to meet market expectations (the Ford Edsel is a classic example).This paper examines the deep reasons why requirements expressed in language are so hard to convey from a stakeholder to a supplier or from consumers to manufacturers. Semiotic concepts are summarized and bolstered with physiological and psychological evidence about the phonemic, syntactic and semantic properties of language. The paper concludes that language is profoundly arbitrary, whether spoken or written, whether in words or in pictures. It is therefore incumbent on all of us to remember the strong principle of communication: each party to a communication must work hard to understand what the other is trying to say. Such effort is one main thing that will help understand requirements. Additional help comes from development methodologies that quickly lower the level of abstraction by demonstrating solutions as early as possible, and by requesting feedback from stakeholders. Automated tools can also help.
6.1.3 Conceptual Design of an Environment for Systems Engineering Education
Authors: Ring Jack , Buede Dennis , Bolling Fred 
Published: November 2014

AbstractA major problem in the teaching and learning of systems engineering is one of feedback concerning the quality of what we do: we often do not get any, and when we do, it is very late and imperfect. Accordingly, both initial learning and retention suffer. One of the few engineering domains involving complex systems and in which feedback is fast and quite accurate is racing, e.g., race cars!! Our proposed solution for the academic problem is a studio for modeling the “design, test, and operation of race cars“. This laboratory stresses the breadth of systems and systems engineering rather than the depth that is typical of classes in other engineering disciplines. The proposed studio can be used for capstone design and project courses at both the undergrad and grad courses.
6.2.1 “SYSTEMS ENGINEERING: DRIVING THE EVOLUTION TO ACTIONABLE ARCHITECTURE”
Authors: Popkin Jan 
Published: November 2014

AbstractSystems engineering is a well‐developed, proven practice in both the commercial world and the US government. Enterprise architecture, while comparatively new to many federal agencies, brings together proven commercial and government architecture and modeling best practices from the last three decades. Systems engineering is a key thread in any enterprise architecture initiative. With its enterprise view, architecture builds a thread through systems engineering and relates it to broader enterprise IT efforts.This paper examines the role and value of systems engineering in architecture development. How do the two relate to each other? Both utilize standards; both deliver a common platform that facilitates communications and information sharing among users.Systems engineering delivers an actual product–a system; enterprise architecture delivers a blueprint. Both deliver interoperability, yet systems engineering deals with product development while enterprise architecture deals with alignment and management. Systems engineering provides information for decision support, but this is not the primary goal. Enterprise architecture delivers a blueprint for decision support, not for product development. Both disciplines share a relatively long history of practice.We will discuss how systems engineering is related to broader architecture efforts. The importance of systems engineering as part of an architecture roadmap, and ultimately, a decision support tool, will be explored. We will also look at the trend toward ‘actionable’ architecture that integrates systems and mission, goals and capabilities into one view. ‘Actionable architecture’ offers improved decision support for IT in areas such as technology investments, gap analysis, cost reduction and improved efficiency.
6.4.3 Requirements Management, from the RFP to the Project
Authors: Jakacky Ronald F. , Doty Ormond R. 
Published: November 2014

AbstractSystem Engineers during preparation of proposals for new contracts often overlook requirements analysis as a vital step in producing a comprehensive and compliant proposal. The rigor required for a traditional requirements analysis goes by the wayside in the rush of tight deadlines, limited staff, and the stress of proposal production. Once the program starts, the team then performs requirements analysis with the initial task of reconciling the requirements with the proposed offering. This reconciliation often uncovers compliance issues not identified during conceptual design, or discovers that there may be alternate solutions for the set of requirements.A well thought out and streamlined requirements assessment process, implemented during the proposal, facilitates the development of system concepts that are complete and compliant while still satisfying demanding proposal preparation schedules. The assessment process then feeds a set of well‐analyzed and structured requirements directly into the post‐award contract work that reduces the need for reconciling the offering to the real program.ITT Aerospace/Defense Division developed and deployed this process with great success in reducing compliance and coverage issues during the proposal phase and providing a solid foundation for beginning the new program. This process is also in deployment to another division of ITT.
7.1.2 Sea Level Requirements as Systems Engineering Size Metrics
Authors: Valerdi Ricardo , Raj Jatin 
Published: November 2014

AbstractThe Constructive Systems Engineering Cost Model (COSYSMO) represents a collaborative effort between industry, government, and academia to develop a general model to estimate systems engineering effort. The model development process has benefited from a diverse group of stakeholders that have contributed their domain expertise and historical project data for the purpose of developing an industry calibration. But the use of multiple stakeholders having diverse perspectives has introduced challenges for the developers of COSYSMO.Among these challenges is ensuring that people have a consistent interpretation of the model's inputs. A consistent understanding of the inputs enables maximum benefits for its users and contributes to the model's predictive accuracy. The main premise of this paper is that the reliability of these inputs can be significantly improved with the aide of a sizing framework similar to one developed for writing software use cases. The focus of this paper is the first of four COSYSMO size drivers, # of Systems Requirements, for which counting rules are provided. In addition, two different experiments that used requirements as metrics are compared to illustrate the benefits introduced by counting rules.
7.2.1 Development of an Integrated Facilities' Management Baseline at a Federal Agency Using a Systems Engineering Approach
Authors: Thurau Robert , Dagli Cihan , Enke David 
Published: November 2014

AbstractThe National Geospatial‐Intelligence Agency (NGA) has implemented an integrated facilities' management program covering its many buildings, operations, and site locations. In conjunction with organizational structure development, a commercial‐off‐the‐shelf (COTS) computer aided facilities management (CAFM) system was implemented to integrate data collection and user control. These facilities' management aspects include tracking building floor space usage, employee locations, AutoCad building designs, equipment inventory, operations and maintenance scheduling, etc. The systems engineering process included a spiral architecture development model, initial and recurring data validations, a risk management review, and multiple phases of tracking requirements and change control. Formal configuration management boards (CMB) were a critical element of development and continuing operation of CAFM. Use of an open systems interface design to allow exchange of data between CAFM and related databases from Human Resources and Security Departments was essential. By replacing the many separate legacy facilities programs with an integrated CAFM package, more complete data information was collected which allowed for better control and operation of facilities resources and improved strategic facilities' planning.
7.4.2 Extending Systems Engineering Frameworks for Special Application Areas: Case Study Safety and Security
Authors: Ibrahim Linda , Wells Curt , Bate Roger 
Published: November 2014

AbstractSeveral standards, models, and frameworks provide systems engineering best practice. There are also many standards that address special applications of systems engineering. If an organization is already working on improving its systems engineering processes using a general model, how might it additionally address standards and best practice in related fields of interest in an efficient, effective way?This paper describes a new construct, called an Application Area, designed for extending existing systems engineering frameworks with practices and guidance specific to a particular application. The construct is illustrated by means of the Safety and Security Application Area that was developed using this approach.
8.1.2 Improving the VVT Process: Evaluating the SysTest Results in Six Industrial Pilot Projects
Authors: Hoppe Markus , Engel Avner 
Published: November 2014

AbstractMany companies experience extensive product rework and failure cost due to ineffective Verification, Validation, and Testing (VVT). Therefore, there is a great potential benefit in streamlining and optimizing the VVT process. To that end, a consortium of eight European companies, research institutes, and organizations conducted the SysTest project. The stated aim of SysTest was to “…decrease product development cost and time to market by 10%“. SysTest intended to achieve this aim by developing a generic methodology and process model to support the process of systems' VVT. This paper describes the results of using the SysTest products in six industrial pilot projects. The diverse pilot projects have shown that the SysTest products are applicable in different industries. Specifically, each project was able to use most components of the SysTest methodology and process model and the pilot projects conducted by the industrial partners exhibited an average of nearly 8% project cost reduction with standard deviation of about 15%.
8.3.1 Towards an Integrated Methodology for the Model‐based Development of Embedded Automotive Control Software
Authors: Buhr Kerstin , Conrad Mirko , Dörr Heiko , Fey Ines 
Published: November 2014

AbstractThe complexity of developing automotive control unit software can generally not be mastered without an efficient development methodology. The development discipline activities requirements, modelling / implementation and quality assurance are, for this reason, supported by individual methods. In order to optimally coordinate the methods with one another during their deployment, a structured integration of these individual specialised methods is, however, essential. The following paper, using the model‐based development approach as an example, outlines the content and structure of an integrated methodology that provides such integration. Its use shortens development time and increases product quality by coordinating the deployment of individual methods over the course of the entire developmental process. The main components of this kind of integrated methodology are an interdisciplinary information model, process models with integrated procedures for the realisation of single development activities as well as guidance such as checklists, templates, and examples, among other things. In this paper, we present the experiences that we have gained at DaimlerChrylser Research in developing and applying such an integrated methodology1.
8.4.1 Implications of Sociological System Theory on Systems Engineering and Product Development
Authors: Pulm Udo 
Published: November 2014

AbstractSystems engineering can be regarded as a part of system theory, which seems to be most up to date in sociology trying to understand complex social systems. This contribution gives an overview on the development and appearances of system theory, compares systems engineering and the modern sociological system theory and shows how to improve the design and development of technical systems by the use of those sociological insights. This regard covers a new understanding of complexity, of systems themselves, of communication being any coordination of activities, as well as respective media. The considerations finally lead to a dynamic organisation as well as to measures how to approach complex social systems.