bluuebunny/crossref_metadata_2025_split huggingface dataset:
6.2.1 The Concepts of Systems Engineering as Practiced by the Wright Brothers
Authors: Buede Dennis 
Published: November 2014

AbstractTo the best of our knowledge the term “systems engineering” was first used at AT&T's Bell Laboratories some time in between 1920 and 1940. [Buede, 2000] The systems engineering profession made rapid progress for 20‐30 years after World War II, as did all of engineering. Nonetheless it is possible to see the concepts of systems engineering being practiced prior to 1920.The purpose of this paper is to explore one of those cases: the development and ultimate production of the airplane by the Wright brothers.
6.2.3 Application of Computer‐Aided Systems Engineering to Develop Automated Train Control (ATC) System
Authors: Lee Joong Yoon , Ahn Jang Keun , Park Young Won , Lee Woo Dong , Mok Jai Kyun 
Published: November 2014

AbstractThe project to develop an automatic train control (ATC) subsystem for the Automated Guided Transit (AGT) system has high technical risk because the wireless train control technology is unprecedented in Korea. To succeed in developing the ATC subsystem, SE team took a reverse engineering approach focused on building an engineering model of the ATC subsystem. The scope of this paper is to develop a functional architecture of the ATC subsystem using the CASysE tool of Vitech Corp., CORE. This paper shows how the generic SE process was tailored to perform a reverse engineering approach in developing the wireless signal/control subsystem.
9.1.9 Decision Metrics Matrix Process
Authors: Helm James C. 
Published: November 2014

AbstractThis paper presents a decision metric matrix process to evaluate the stakeholders needs related to their goal for improvement of a process, product or resources. The decision metric matrix gives the system engineer a method to name the components of the decision matrix and provides a process to extract, quantify and evaluate the metrics of the stakeholders' goals. Column one and subsequent rows of the decision matrix contain the decision parameters and the interior rows and columns contain the associated action statements and values. The stakeholder uses the action statements and action values as indicators to make a weighted decision concerning the goal. The decision metrics matrix uses concepts from the Goal‐Driven Measurement paradigm (Basili).
9.2.0 The Communications Requirements Evaluation & Assessment Prototype (CREAP)
Authors: Kasser Joseph E. , Cook Stephen C. 
Published: November 2014

AbstractToday's requirements engineering processes do not have very effective checks to ensure that system requirements are feasible. This paper describes extending the use of Requirements Engineering tools to assist the writers of requirements to only accept requirements that are feasible using the FBRET approach (Cook et al. 2001). The approach is illustrated by the description of the Communications Requirements Evaluation & Assessment Prototype (CREAP). The CREAP is a prototype software package that is able to integrate military communications domain expertise and requirements engineering practice in order to ensure the feasibility of equipment selected to meet the requirements imposed on communications systems for a rapid force deployment in a design to inventory scenario.
9.2.4 Open Source Software Assessment for the Naval Oceanographic Office
Authors: Lever John A. , Maresca Chris , Munro Robert 
Published: November 2014

AbstractThis paper describes an ongoing analysis of the utility of Open Source software at the Naval Oceanographic Office (NAVOCEANO). NAVOCEANO possesses leading‐edge technical and science skills for the application of Information Technology (IT) in processing oceanographic data over multiple scientific domains. NAVOCEANO produces numerous information products supporting U.S. Navy operations, the Department of Defense, and the other military branches, as well as various national and international customers. These capabilities are critical to developing and maintaining the highest quality oceanographic products for the Navy fleet. In addition, NAVOCEANO maintains an extensive library of state‐of‐the‐art scientific applications software.The Open Source Software Institute (OSSI) is a nonprofit organization that promotes development and implementation of Open Source software solutions within government and academic institutions.In 2001 NAVOCEANO requested OSSI assess the use of Open Source software within NAVOCEANO, and OSSI contracted with Olliance Consulting Group to assist with this effort. The objectives, scope, approach, and some preliminary results of this evolving Open Source assessment are presented.
9.2.6 Aging Transport Systems Rulemaking Advisory Committee (ATSRAC) Aviation Standard Wiring Practices Manual – Task 7
Authors: FRAeS Ross Lloyd 
Published: November 2014

AbstractATSRAC was created to resolve certain aircraft wiring issues by problem solving. This entails the development of standards and therefore ATSRAC encompasses the theme of INCOSE 2002 – Problem Solving Through Structured Thinking with concentration on the Speciality Track of Development and Use of Standards.Task Group 7 of ATSRAC (of which the author is a committee member) adopted the Systems Engineering approach to solve the problem of introducing the requirement (through an industry standard) of a Standard Wiring Practices Manual.Soon after TWA 800 accident it was noted by the FAA that ‘aging’ could not be limited to structural systems and it was now necessary to include non‐structural systems in the FAA program covering Aging Aircraft.Standard Wiring Practices Manuals were developed, implemented and utilised by Aircraft Manufacturers in the development of their product line.Originally driven by (and in the most part, echoing) Military Standards, the layout and content varies considerably between manufacturers.Task Group 7 was established under the auspices of ATSRAC to develop a Standard for aircraft wiring practices.ATSRAC Task Group 7 is an example of ‘Development and Use of Standards‘.This paper provides a solution to inconsistencies with aircraft wiring not only between manufactures but also different aircraft models from the same manufacturer. This will be accomplished by developing standards, which are intended to be mandated throughout the aviation industry.
9.2.7 Integrated Product Development Planning within Distributed Organizations using ProcessEdge™
Authors: Madni Azad M. , Madni Carla C. , Plaut Jeff , Zarnow David 
Published: November 2014

AbstractAfter a series of acquisitions, major aerospace companies are still consolidating their infrastructures and processes. One of the more challenging issues is consolidating the systems engineering infrastructure. This is because each acquired company has its own systems engineering processes and best practices despite the fact that all claim to have embraced integrated product process development (IPPD) and systems engineering standards. Compounding the problem is the fact that each organization has a legacy of tools, applications, and databases that produce sufficiently different outputs that it becomes near impossible to reconcile them. This paper presents a “view from the trenches” as a major aerospace company took on this challenge. The circumstances, approach, and findings from this work should resonate with practitioners in the field while providing them with insights for future undertakings.
9.3.6 Effective Engineering Decisions Through Structured Collaboration
Authors: Wilson Mark A. 
Published: November 2014

AbstractThis paper describes a methodology for engineering decision‐making through structured collaboration. This collaborative decision engineering methodology has been effective in both government and commercial arenas on a wide range of programs. By thinking about the decision as a three step process of: (1) framing the decision to be made, (2) generating alternatives, and (3) deciding the course of action, decision makers can harness group dynamics to help achieve the goal of implementing engineering decisions that work and last.
2.3.1 The Impact of CMMI Maturity on Innovation
Authors: Walden David D. 
Published: November 2014

AbstractThis paper analyzes the impact that increased process maturity has on innovation. The Process Areas (PAs) and Generic Practices (GPs) of the Capability Maturity Model Integration for Systems Engineering / Software Engineering / Integrated Product and Product Development / Supplier Sourcing (CMMI‐SE/SW/IPPD/SS) were each individually assessed for their impact against six key characteristics associated with innovation.The analyses suggest that, on balance, increasing an organization's process maturity in the areas covered by the CMMI has a positive effect on the ability to innovate. Most PAs are either neutral to or have a positive influence on innovation. A few PAs have a negative influence on innovation. The results of this analysis are consistent with a similar analysis that used the EIA/IS‐731 Systems Engineering Capability Model (SECM).
2.3.5 Systems Engineering Beyond Capability Models
Authors: Sheard Sarah A. , Schoening William W. 
Published: November 2014

AbstractCapability models have been used for more than a decade to improve the ability of organizations to produce software and systems. The models themselves have matured and currently capture much industry wisdom. However, it is important to note that capability models1 do not and cannot include everything that an organization needs to know to do systems engineering well. This paper attempts to show where systems engineering is broader or deeper than is captured in capability models. Organizations that address these areas when implementing capability model‐based process improvement will make their systems engineering capability robust.
3.3.1 Tools for Requirements Discovery, Creation, and Elicitationa
Authors: Heydt Harold J. , Alessi R. Sam 
Published: November 2014

AbstractSystems engineers can benefit by increasing their familiarity with multiple approaches and tools for helping human beings express their desires and wants. This paper addresses this issue by presenting an overview of requirements elicitation tools. Numerous tools are discussed with their applicability to hardware, software, or soft systems, or any combination. It provides an overview of “what” the tools can do but not “how” to use the tool, the difficulty of learning (rough order of magnitude learning time), the type of product the tools are of greatest value (benefit/cost) for usage, and some advantages and disadvantages for each tool.
3.3.2 The Communications Requirements Evaluation & Assessment Prototype (CREAP) Project: A Case Study of a System Engineering Educational Project
Authors: Kasser Joseph , Cook Stephen C. , Pilgrim Anthony , Gamaliel Yoyok , Ton Dat Bao 
Published: November 2014

AbstractThis paper contains a case study describing the development of a software tool to prove a concept for use in design to inventory scenarios. The tool was developed by Master's students at the University of South Australia. The case study, designed as a reference for similar activities in other academic institutions, contains a list of lessons learned on the project. All the lessons learned have to do with the nontechnical aspects of the project. Even though the project was small, many of the attributes of large projects were seen.
3.3.3 Separating Product and Process Requirements
Authors: Abadi Christiano Danny , Bahill Terry 
Published: November 2014

AbstractWhen engineers design a system, they must design both the product and the process that will develop it. Accordingly, systems engineers must separately write requirements for the product and the process. Stating these requirements in separate documents should make it easier to get the requirements right and manage the requirements when either the product or the process requirements change.
4.3.1 Innovation and Technology Management
Authors: Simpson Joseph J. 
Published: November 2014

AbstractA systematic approach to innovation and technology management is outlined in terms of a generic systems engineering process. Two types of innovation, incremental and disruptive, are described and discussed. All aspects of the product development and application environment must be correctly managed if an organization wishes to consistently produce innovative technologies and products. System engineering concepts provide a structured framework for the successful practice of innovation and technology development, deployment and management.
4.3.4 NASA Technology Assessment Using Real‐Options Valuation
Authors: Shishko Robert , Ebbeler Donald H. , Fox George 
Published: November 2014

AbstractWe examine the use of real‐options valuation in the context of prioritizing advanced technologies for NASA funding. Further, we offer a set of computational procedures that quantifies the option value of each technology. Other researchers have applied a real‐options framework to private sector investments. In the case of NASA investments in advanced technologies, the underlying products, which must be used to justify the investments, are nearly pure public goods—in particular, space‐related scientific results and discoveries to be shared worldwide. As in the private sector, uncertainty plays a significant role in the motivation to use real options in NASA. Uncertainty in NASA technology investments can be classified as development risk and programmatic risk (whether missions using the technology will actually fly). The latter might be called the technology's “market risk.”We carried out the approach on a number of planetary exploration technologies. We illustrate the detailed calculations using one of them — lightweight propellant tank technology.
5.3.4 Introducing Innovative Technology in a Contract‐Driven Environment
Authors: Myers Kenneth N. , Beckley Jennie 
Published: November 2014

AbstractThis paper discusses our experiences in developing and introducing a web‐centric Collaborative Engineering Environment (CEE) into an organization whose lifeblood is performing on government contracts. We review events in the team's 3‐1/2 year history that led to an increasing awareness that the product development paradigm needed to introduce innovation into the engineering organization is very different from that needed to perform successfully on a contract. While many lessons from the world of contracting have been valuable, some of the disciplined processes learned over the course of many years, such as up front specification and traditional forms of progress tracking, can hinder innovation. Finally, we summarize the process adaptations we have made to address the conflicts.
6.3.5 An Implementation of a Process Centered Collaborative Engineering Environment within the Satellite Industry
Authors: Hartmann Ralf , Knirsch Ulrich 
Published: November 2014

AbstractThe paper presents an approach for a Collaborative Engineering Environment (CEE), facilitating the work of distributed design teams. It includes an internet portal providing among others access to tools and to a project database. A core element is the so‐called process guidance, which is not only the basis for the derivation of the CEE user requirements ‐ including standard tools ‐ but also the primary reference for tailoring of processes to specific projects. The process guidance, which is currently being implemented at Astrium, is centered on databases with web interfaces. Thanks to the non‐proprietary software, it is easy to implement, to use and to update. Additionally, the paper discusses lessons learned in the development process.
1.4.5 A Systems Approach to Open‐Inquiry Evaluation of Engineering Programmes
Authors: Harris Michael B. 
Published: November 2014

AbstractThe problem of how to evaluate engineering programmes is considered. Engineering organisations are under pressure to improve the performance of their programmes, as failures in technological projects receive increasing criticism, while the demand remains for increasingly complex projects to be undertaken. Many engineering organisations have realised that the success of such programmes depends more on the management and related programme issues and less on the engineering details. Evaluation of engineering programmes is demanded, yet evaluation techniques from ‘soft’ (non‐engineering) domains with little understanding of engineering values and culture may be quickly dismissed as ‘not sufficiently quantitative’ and ‘without a systems (engineering) basis‘.Programme evaluation in the human services field is well established, and the types of programme evaluations are outlined. However, engineering programmes present a complex problem space for the evaluator, and require an evaluation method capable of accounting for the values and culture of engineering stakeholders.This paper outlines the systems approach for solving this problem of engineering programme evaluation, on the assumption that the engineering programmes are sufficiently complex that specialist evaluators from ‘soft’ domains conduct the evaluation. An evaluation model is proposed, based upon the open inquiry evaluation method used in human services programme evaluation, superimposed on the proven process used in the engineering discipline of Test and Evaluation (T&E) to validate ‘hard’ products of engineering programmes. With this model, it is suggested that an evaluation technique is easily understood and appreciated by the critical reference group in technology‐intensive domains.
2.4.1 Integrating Beyond Capability Maturity Models®
Authors: Ibrahim Linda 
Published: November 2014

AbstractThe Federal Aviation Administration (FAA) has been successfully pursuing integrated process improvement since 1997 using FAA's integrated Capability Maturity Model® (FAA‐iCMM®). FAA‐iCMM v1.0 integrated three CMMs: the software, systems engineering, and software acquisition models. Version 2.0 additionally integrates several important improvement approaches including ISO 9001:2000, EIA/IS 731, Malcolm Baldrige National Quality Award, CMMI, ISO/IEC TR 15504, ISO/IEC CD 15288, and ISO/IEC 12207. By integrating beyond CMMs, the FAA‐iCMM now contains guidance for improving business and technical processes ranging from enterprise management to operation and disposal.This paper describes FAA‐iCMM v2.0, points out specific contributions from new sources, and illustrates some insights gained from taking a broader perspective ‐ when integrating beyond CMMs. The paper will be of interest to any organization that has been using multiple standards and finds that approach too expensive, confusing, or ineffective. It will also be of interest to organizations that do business with the FAA.
2.4.4 Prediction of Information System Availability in Mission Critical and Business Critical Applications
Authors: Hecht Myron , Incorporated SoHaR 
Published: November 2014

AbstractOne of the most important attributes of on‐line computer systems that are performing mission or business critical applications is availability. System Engineers are often called upon to predict the reliability of such systems as part of proposal preparation, architecture definition, design reviews, and operation. However, traditional modeling techniques are incapable of handling integrated hardware and software systems with multiple states and redundancy. This paper describes how Markov Modeling and Reliability Block Diagrams can be used together to model a large on‐line information system and develop the answers to strategic questions on the configuration and operation of high availability computing systems. The analyses are performed using MEADEP, a reliability analysis tool capable of hierarchical modeling and integrating Markov and block diagram techniques. In the example 3‐tier architecture e‐commerce site described in this paper, it is shown that (a) the most frequently failing subsystem is not necessarily the availability bottleneck, and (b) that restoration time is often a more important parameter than availability when attempting to maximize system throughput.
2.4.5 Multistage System Integration
Authors: Tahan Meir , Ben‐Asher Joseph Z. 
Published: November 2014

AbstractIn large‐scale system developments, systems engineers usually divide the integration process into stages in order to facilitate the integration. Often this “divide‐and‐conquer” method, or what we call “multistage integration”, is the only way of rendering the integration of a complex system feasible. This paper proposes to consider the employment of the multistage integration methodology for large as well as for small systems. The main point is that, regardless of size, and even when a single stage integration is feasible, it may be beneficial, both time‐wise and cost‐wise, to pursue the multistage integration methodology. Two models are developed in order to analyze single stage and multistage integrations: a purely statistical model, and a robust design based model. Both models are shown to be viable and efficient as demonstrated by a simple representative example.
4.4.1 Systems Engineering Techniques in Support of Business Improvement
Authors: Kemp Duncan , Cole John 
Published: November 2014

AbstractThis paper discussesd the use of Systems Engineering concepts and techniques in business improvement projects being undertaken within the United Kingdom's Warship Support Agency, part of the and Defence Logistics Organisation.System's Engineering techniques have been used to understand complex cultural, process and organisational issues that have been limiting the performance of Warship warship Supportsupport, and help design and justify elements of the WSA's successful Enterprise Integration and Shared Data Environment Project.The paper discusses the use of failure mode analysis to identify strategic drivers for change and system dynamics modelling to link business improvement requirements to business benefits in business cases.
4.4.2 From Systems Engineering to Service Engineering
Authors: Wieser Michael 
Published: November 2014

AbstractFor many companies the optimisation potential in quality, process, and cost has become smaller and smaller in the last years. Systems engineering has played an important role in that process. Now, an almost untouched and in many companies often ignored domain has become the target of interest: services!A systematic development of services is supposed to be a key factor in the future in order to diversify the own company from the competitors. As customers more and more call for integrated solutions goods will not be sold in future on their own anymore. They will have to be integrated in services. Those one, who will be able to offer new services in a shorter period of time, that meet exactly the customers' needs, will have a main advantage in a global market. To do so, methods and tools are required.This paper describes the current situation of services, their role in the world economy and why it is so important not to ignore the services any longer. It is shown how services can be characterised and it is discussed if current systems engineering models can be transferred to the “immaterial” world of services.
4.4.4 E‐Business Infrastructure Capability Assessment
Authors: Ring Jack 
Published: November 2014

AbstractA modern E‐Business infrastructure must enable enterprise collaboration, both external and internal, throughout unpredictably dynamic situations. Anyone selecting an e‐business solution should assess the capability of its infrastructure using applicable Measures of Effectiveness (MOE's). This paper expresses the MOE's in the context of a conceptual model of an E‐Business infrastructure. In addition, a checklist and a graphical notation for scoring the capability levels of candidate solutions is provided. The purpose of a capability assessment is to help protect enterprises from making commitments to solutions that lack key capabilities. The ten MOE's described in this paper will provide a useful perspective to any systems engineering practitioner involved in creating an E‐Business solution.