bluuebunny/crossref_metadata_2025_split huggingface dataset:
1.4.2 Space System Concept Center, a CDC in an Educational Environment
Authors: Schiffner Michael 
Published: November 2014

AbstractThe Institute of Astronautics (LRT) at the Technische Universität München gathered during the last years experience in the area of implementing Concurrent Design Center (CDC) in industry. It was both involved in the implementation of the Satellite Design Office at Astrium in Friedrichshafen and in Ottobrunn and developed a software tool to support the development process in the SDO. It was also involved in the implementation of a design center at Fairchild Dornier Corporation (Finkel et. all, 2002).To teach the students the idea of concurrent engineering besides system modeling and systems engineering, the institute decided to provide a workshop for students during which they will learn these ideas. To achieve this goal, a small CDC, called Space System Concept Center (S2C2), was established at the institute.This paper describes the workshop and the experience gathered during the last workshops. It outlines the process and team size required to perform a workshop in an educational environment.
1.4.3 Designing a new airport using a system engineering approach in a classroom exercise
Authors: Ludema Ir. Marcel W. 
Published: November 2014

AbstractIn the year 1999 the main transportation issue in the Netherlands was the Question: “If, why and how to facilitate the need for a new national airport?“. Amsterdam Airport Schiphol is growing towards its maximum capacity, due to space and environmental restrictions. The Dutch government looked for alternatives to facilitate the demand for further growth in air transportation, besides expanding the current airport. An alternative would be an airport on an artificial island a few kilometers out of the coast of the Netherlands. As part of a course addressing the subjects System Engineering and Integrated Logistic Support it became the problem field used as a case study. A problem solving method was developed based on some basic inter‐related concepts such as the necessary requirements for capacity, availability and maintainability that should be addressed during the system engineering phases related to the design and development of complex systems. Students stepwise designed a conceptual plan for an airport in sea on an artificial island based on the problem solving method. In respect to the duration of the course the results were more than satisfying.
5.4.1 ProACT™: Process‐aware Zero Latency System for Distributed, Collaborative Enterprises
Authors: Madni Azad M. , Madni Carla C. , Salasin John 
Published: November 2014

AbstractEnterprise integration technologies such as XML, publish‐subscribe, and message brokers have made it possible for distributed enterprises to exchange information in a consistent, standardized way. However, these technologies do not address how to effectively integrate humans within distributed, collaborative enterprises nor do they specifically address how to minimize latencies in collaborative enterprises.This paper presents ProACT™, a process‐aware collaborative system for integrating distributed collaborative enterprises at the functional/task level. ProACT exploits knowledge and awareness of planning/process execution status to eliminate/reduce information latencies in the distributed enterprise. ProACT employs a variety of process‐enabled, zero latency strategies such as optimal information caching, information prefetching, message prioritization in a bandwidth‐limited network, optimum database partitioning, and information replication to achieve the near‐instantaneous awareness goals of the enterprise.
5.4.2 Understanding Enterprise Behaviour: A Feasibility Study
Authors: Clegg Ben , Turner Mathew 
Published: November 2014

AbstractThis paper describes work conducted as a joint collaboration between the Virtual Design Team (VDT) research group at Stanford University (USA)1, the Systems Engineering Group (SEG) at De Montfort University (UK) and Elipsis Ltd2. We describe a new docking methodology in which we combine the use of two radically different types of organizational simulation tool. The VDT simulation tool operates on a standalone computer, and employs computational agents during simulated execution of a pre‐defined process model (Kunz, 1998). The other software tool, DREAMS3, operates over a standard TCP/IP network, and employs human agents (real people) during a simulated execution of a pre‐defined process model (Clegg, 2000).This docking study was conducted to develop a supporting tool‐set for the concept of Enterprise Systemics, an approach designed to address the increasing commercial volatility of enterprises. It has been funded by the PISCES network project4, which has drawn together a cross‐disciplinary resource for comprehending the dynamics of the extended enterprise.
1.5.4 Capability Maturity Model Integration (CMMI) Process Using Unified Modelling Language (UML) for Flight Safety Process Modernization at a Major Range Test Facility Base
Authors: Donahe Dave , Gonzales Regina M. , Eubanks Carl , Gonzales Eli 
Published: November 2014

AbstractThe Capability Maturity Model Integration (CMMI) initiative is a blend of systems engineering and software procedures that promote process improvement in multi‐discipline activities such as a support system modernization at a Test Range. Using processes that promote consensus, the CMMI provides a cohesive framework for development that accommodates multiple disciplines toward a modernization development effort. This paper describes the on‐going processes involved in applying systems modeling techniques within a CMMI process environment to Flight Safety modernization at a Major Test Range. The system analysis and modeling is being done using various Requirements Engineering methods and is being expressed in the Unified Modeling Language (UML). This modeling effort is still at the conceptual or requirements elicitation phase. Some initial models will be presented in this paper along with the process framework that is being applied.
2.5.3 Overcoming the Obstacles to Systematic Design Reuse
Authors: Cole Robert 
Published: November 2014

AbstractAlthough some level of design reuse is present in any engineering project, systematic design‐for‐reuse is less commonplace. Despite the known benefits of reuse, the implementation of systematic reuse faces strong resistance from management and designers. This paper considers inhibitors to implementing design reuse methodologies and the steps required to successfully transition from a no‐reuse culture to one of systematic reuse. Also considered are some of the pitfalls that can doom a poorly planned reuse initiative.
3.5.1 A Prototype Tool for Improving the Wording of Requirements
Authors: Kasser Joseph 
Published: November 2014

AbstractThe majority of work on a project is in response to a set of need statements or requirements, consequently errors in requirements are a major cause of project cost and schedule overruns. This paper presents a simple concept based on the FBRET approach (Cook et al. 2001) that can minimise the production of poorly articulated requirements, and describes a prototype software tool that implements the concept.
1.6.5 The Case for Flexibility in System Design
Authors: Saleh J.H. , Marais K. S. , Hastings D. E. , Newman D.J. 
Published: November 2014

AbstractIn this paper, we make the case for flexibility in system design. Flexibility is here defined as the ability of a system to respond to changes in its initial objectives and requirements, occurring after the system has been fielded, in a timely and cost‐effective manner. We argue that flexibility reduces a design's exposure to uncertainty, and provides a solution for mitigating market risk as well as risk associated with technology obsolescence. In order to illustrate the dynamics of system requirements, we first review the requirement generation activity. In addition, we demonstrate the criticality of technology obsolescence in the particular case of its impact on DoD related systems.
2.6.2 Integrated SE and PDM tool Support for Medium Sized Companies
Authors: Vonno Remco , Smeets Gaston , Boersema Niek 
Published: November 2014

AbstractThis paper describes how a fast and pragmatic design process for complex customer specific product development can be supported with a single tool. A commercial Product Data Management (PDM) tool has been extended with new functionality to provide support for the Systems Engineering (SE) needs of a medium sized company focused on modular design, maximum reuse and early involvement of suppliers.
3.6.1 The Concept Exploration Phase and Successful Coaching of Systems Engineering
Authors: McGuire Kathleen 
Published: November 2014

AbstractApplying systems engineering techniques to the Concept Exploration (CE) phases of projects is often met with either indignation or incredulity. This much less structured, problem‐ridden phase seems to many to defy the use of process. This phase has traditionally been problematic and difficult to execute. IF the word “process” is too strong, the idea of “systems thinking” that helps make some order out of chaos can be effectively used for coaching teams to better performance.This paper discusses some typical problems encountered in one organization and some successful use of systems engineering approaches to improve the teams' performances in the Concept Exploration phase.
4.6.5 Towards an Improved Understanding of Humans as the Components that Implement Systems Engineering
Authors: Axelsson Jakob 
Published: November 2014

AbstractSuccessful systems are developed from a good understanding of two things: the features and functions desired by the customers, and the features and behaviour of the available components. A firm developing a complex technical system is also a complex technical system in itself, so the same two things need to be understood about the organisation. Much research on systems engineering focus on defining the features and functions of the organisation, but less attention has been given to the prime component used for implementing it: the human being. In this paper, an initial attempt is made at describing some of the issues involved, from a mainly philosophical perspective.
5.6.1 Characterizing the Relationships Between Product Developers and Their Customers
Authors: Schoening William W. 
Published: November 2014

AbstractThe systems engineering approach of a product developer is strongly influenced by the business relationships with customers. The model presented in this paper characterizes those relationships and provides a framework for understanding why some developments are successful while others have little chance of success. The model is then used to examine more complex scenarios and transitions between scenarios to help understand some of the business management challenges encountered in a heterogeneous mix of business scenarios. A notation for describing these relationships is introduced to facilitate describing the individual scenarios.
6.6.2 System Integration in the Power Utility Industry: Lessons Learned
Authors: Rothweiler Angela 
Published: November 2014

AbstractThe shift from regional monopolies to retail marketers has caused significant structural changes within the Power Utility Industry, such as the disintegration of the transmission sectors, the transformation from engineering management to business leadership, the reorganization of distribution operations, and the ongoing acquisitions, mergers and buy‐outs. For the past 6 years, utility companies have been seeking new economic solutions that will allow them to survive within the competitive market. One area that has gained popularity is substation automation (SA). SA entails the integration and data management of intelligent electronic devices (IEDs) within the substation.This paper attempts to use systems engineering (SE) principles for the design and development of substation data concentration (SDC) systems. A collaborated effort between the designer, the utility experts, the programmers and the technical manager transform the SDC operational need into system performance parameters; integrate functional and program interfaces in a manner that optimizes the total system; and ensures reliability, maintainability and survivability to meet cost and scheduling objectives.
6.6.4 Introducing Systems Engineering in the Fast Track: Wireless Data Communications Goes One Step Beyond
Authors: Ransyn Jack , Verhoeven Maarten , Vonno Remco 
Published: November 2014

AbstractThis paper contains the way Systems Engineering principles have been implemented in a very specific environment, a software engineering firm that creates applications for wireless data communication. This environment is challenging for a number of reasons, but mostly because there doesn't seem to be time for structuring the development process and introducing formal methods. On the other hand, not introducing a formal systems engineering method would be a dead end street sooner or later, given the fact that the company is making the transition from being project and consultancy oriented, towards becoming a productising firm with repeatable processes and predictable quality.The challenge was answered by introducing a dedicated task force, called the RADS team (Requirements Analysis Design Support). This team introduced the Systems Engineering way of working in a rather unorthodox way, that suited the way the company worked without interrupting or delaying its core processes. It proved to be highly effective, and can be used as an example for other organizations.
1.1.1 Improving Forecasting with Soft Systems Methodology
Authors: Stajnko Frank , Doukas Louis 
Published: November 2014

AbstractThe engineering of tomorrow's world today can only happen if we have some idea of what tomorrow's world is going to be like. This leads us into the murky world of forecasting and strategy making, which are highly dangerous and difficult activities for most organisations. Of course if you have perfect knowledge about the future, then strategy making is relatively easy, as there are literally hundreds of effective decision making and optimisation methodologies available for this purpose. Sadly, finding reliable, accurate and concise knowledge about the future is anything but easy. This is the central problem of strategy making. Strangely enough, it is possible to accumulate relatively large amounts of raw data and information about the future, unfortunately processing and condensing this into useful knowledge is remarkably difficult. Information about the future can be hard (logical, deterministic and syntactic), but is mostly soft (vague, complex and semantic). Forecasters often ignore the latter because it is impossible to process normatively, however the appropriate use of Checkland's Methodology (a soft methodology) can greatly improve this situation. In particular, this paper shows how Checkland's Methodology and the correlation matrix can be used together, in order to discover patterns of information about the future that are more consistent, reliable and meaningful. This knowledge is critical for effective forecasting and strategy making.
1.1.2 Using Patterns to Share Best Results ‐ A proposal to codify the SEBOK
Authors: Haskins Cecilia 
Published: November 2014

AbstractINCOSE has been making good progress in the compilation of a Systems Engineering Body of Knowledge (SEBOK). The committee struggles now with an abundance of literature augmented by over a decade of symposia proceedings and other material collected in the INSIGHT and the Journal of SE. Specifically, INCOSE struggles with the question of how to share this wealth with the world as the organization and its members attempt to communicate the value of SE to the international community, engineers and product developers.This is not a unique challenge. A history of civil engineering and other disciplines may offer some insights into how to cope with this opportunity. In 1977, Christopher Alexander tackled this question with the creation of “Patterns” and Pattern Languages. This author proposes that creation of a Pattern Language Framework to document the “Best Results” of Systems Engineering using the resources of the SEBOK will yield positive results in the quest to share the message of Systems Engineering. This paper is intended as the first in a series to introduce the reader to underlying concepts
3.1.3 System Level Costs—Eliminating Guesswork
Authors: Stump Evin 
Published: November 2014

AbstractWhenever a parametric cost estimate is made for a large system, there comes a time near the end of the estimating process when the analyst wonders if everything that is supposed to be in the estimate actually is in the estimate. Among the frequent errors and omissions are so‐called “system level” costs, also known as “wraps” or “SLCs.” NASA and the Air Force, in the NASA Air Force Cost Model define system level cost elements as comprising:

Systems Engineering and Integration
Integration, Assembly and Checkout
Ground Support Equipment
Program Management
System Test Operations
Launch and Orbital Operations SupportNot all of the items above should be added to a basic estimate. For one thing, not all of them occur in every major project. Moreover, many parametric models include some of the above in the basic estimates. But many cost models leave out some of them. And some cost models leave out any system integration above the subsystem/subassembly level (sometimes called level 2 integration). These can be significant omissions. In some cases, the errors could as large as 100%.SLCs often cause problems for projects trying to get an accurate handle on their costs. Recognizing this, the NASA Independent Program Assessment Office (IPAO) contracted with Galorath Incorporated to study these costs, and to get more visibility into their behavior. This study began in August 2001, and was completed in May 2002. The study had access to the NAFCOM99 database, and to other data previously collected by Galorath.The outcome of the study was a strengthening of Galorath's SEER‐H hardware cost model with respect to system level costs. The model previously could estimate these costs, but with less accuracy because of the need to rely strongly on the cost analyst's perceptions of the complexity of the project. With the modifications to the SEER‐H model coming out of this study, more objective criteria are available.
5.1.1 Reusable Specification Components for Model‐Based System‐Engineering
Authors: Weiss Kathryn Anne , Ong Elwin C. , Leveson Nancy G. 
Published: November 2014

AbstractMany modern, complex systems follow common design principles where the system is broken down into various subsystems and components. For example, every spacecraft requires a number of subsystems such as attitude determination and control, power, thermal, communications and propulsion. These subsystems have common functionalities and similar interactions, rendering them suitable for representation with a reusable specification architecture. Their similarities can be used to create a system‐engineering environment specific to modeling that particular system, its subsystems and the subsystems' interactions. Based on this hypothesis, a domain‐specific specification architecture has been developed that is tailored for cross‐disciplinary use by systems and software engineers.
5.1.2 Using the Systems Engineering Process to Explain Baseball's Rising Fastball
Authors: Bahill Terry , Baldwin David G. 
Published: November 2014

AbstractThe systems engineering process, called the SIMILAR Process, is used to help explain baseball's perceptual illusion of the rising fastball. This Systems Engineering process is comprised of the following seven tasks: State the problem, Investigate alternatives, Model the system, Integrate, Launch the system, Assess performance, and Re‐evaluate. This Systems Engineering Process is not sequential. The functions are performed in a parallel and iterative manner. In this paper this process is not used to design a new system, but rather it is used to understand an existing system.
3.2.2 Interfacing a Verification, Validation, and Testing Process Model with Product Development Methods
Authors: Hoppe Markus , Lévárdy Viktor , Vollerthun Andreas , Wenzel Stefan 
Published: November 2014

AbstractA thorough balancing of the costs of conducting verification and validation with the costs of failure promises new possibilities in reducing overall project costs and time‐to‐market. One goal of the presented SysTest project is to develop an approach to support the strategic verification, validation, and test (VVT) planning. This approach, reflected in the VVT Process Model, supports the trade off between different VVT strategies by calculating the effect of the strategy on cost‐, schedule‐, and quality‐risk. This paper describes the VVT Process Model, which is currently developed, and its application in the development process of a hydraulic pump. Furthermore, its interfaces with other company methods and the corresponding information flows between them are illustrated. To demonstrate its potential, the VVT Process Model is positioned in the verification process.
5.2.4 Systems and Objects
Authors: Simpson Joseph J. , Simpson Mary J. 
Published: November 2014

AbstractThis paper discusses basic system concepts including structure, content, semantics, scale and context. These basic concepts are reviewed and discussed in the light of two different human activity modes: system discovery mode and system design mode. A system meta‐model is outlined and discussed in terms of system behavior and context. A generic systems engineering model and process is reviewed and used as a basis to construct a system object model that facilitates the representation, description and detailed communication of system relationships and characteristics. The model is presented at the conclusion of this paper.
2.3.1 Systems Engineering Process Improvement in a Multi‐Model Environment
Authors: Evers John , Miller Chris 
Published: November 2014

AbstractThis paper reviews the major steps in the successful effort in reaching Level 3 maturity at Raytheon Falls Church, against the EIA/IS‐731 Systems Engineering Capability Model. This effort was conducted at the same time as other improvement efforts at Raytheon Falls Church, adding to the complexity of the task while providing the opportunity for synergy as well. Key elements associated with process improvement are discussed, including change management activities and their relation to other models for improvement. Finally, these elements are evaluated for application to other process improvement efforts in a multi‐model environment, such as the use of CMMI® and Lean or Six Sigma.
2.3.3 The Good, the Bad, and the Agile: XP Meets Systems Engineering
Authors: McDaniel Daryl , Neyman Roger 
Published: November 2014

Abstract“Agile” development methodologies (ADMs) have emerged in recent years in response to widely perceived failings of commercial software development organizations (CSDOs) to reliably produce quality results in a predictable timeframe. Criticism of requirements engineering (RE) practices current in CSDOs is prominent among the motivations spurring this movement. Comparison of high level features of ADMs with established systems engineering (SE) approaches reveals that there is significant commonality between them. The most important difference relates to the mixing in of development activities with high level RE activities, involving developers in them from the outset and reducing formality. On the basis of this analysis we make some general observations on the value of ADMs and their advocacy.