bluuebunny/crossref_metadata_2025_split huggingface dataset:
BARRIERS TO BRINGING SYSTEM ENGINEERING INTO THE COMMERCIAL MARKET PLACE
Authors: LaBudde Edward V. 
Published: November 2014

ABSTRACTIt is evident to many that the commercial market place could benefit from a “systems discipline.” Thus far it has been difficult for system engineering to make much penetration into areas that clearly could use this discipline. This is not to say that the task is impossible. Scott Jackson (Smith, 1996) and Pat Hale (Hale, 1996) have reported success in bringing the systems discipline to commercial companies. Their experience makes it clear that some precautions must be exercised if success is to be ensured.LaBudde Systems, Inc. specializes in installing “a systems approach” in the commercial arena. We have successfully installed our Accelerated Product Developmentsm System (APDsm) into 13 commercial companies in the last three years. During this time we have made adjustments to our marketing and sales approaches in order to accommodate the perceptions and sensitivities of the commercial markets. In order to get to first base in the sales cycle, one must approach the commercial market segment with the right sales story. Our experience may be helpful to others attempting to penetrate this market.
A Total Systems Approach To Automotive Development
Authors: Hatley Derek , Rushton Gary 
Published: November 2014

ABSTRACTWe present an approach to automotive development that treats the automobile as a single system, interacting with its operating environment, data and signal sources, the occupants, energy sources, and service centers. The requirements and architecture of the vehicle are developed separately, but concurrently, interactively, and with their interrelationships clearly identified within a common framework. Every aspect of the system is developed within this same framework, including such things as maintenance procedures. The highest system levels include no assumptions about the vehicle technology, allowing, for example, gasoline, electric, solar, or any other energy source, and manual or mechanized subsystems.
SYSTEMS ENGINEERING FOR COMMERCIAL AIRCRAFT
Authors: Jackson Scott 
Published: November 2014

ABSTRACTThe application of systems engineering (SE) to commercial aircraft presents a set of requirements and processes unique to the commercial aircraft industry. SE can be applied to new, derivative, and change‐based aircraft design. The concept of an aircraft system extends beyond the aircraft itself. The hierarchy of the aircraft architecture is embedded in present‐day processes. Aircraft life‐cycle functions follow the classical life‐cycle functions. The aircraft‐level functions can be flowed to aircraft and subsystem level functions and requirements. Requirements which receive more attention than others include performance, safety, cost, reliability, and weight, not necessarily in that order. Economic requirements include both market‐driven and particular customer requirements. Certification guidelines for the aircraft, including its software, incorporate SE principles. Strong SE management is required for the successful development of commercial aircraft. This paper is based on the author's book Systems Engineering for Commercial Aircraft (1997).
System Engineering Online Documentation
Authors: Etcheverry Candace , Eldridge Miriam , Bajema Bruce , Dytko Thomas 
Published: November 2014

ABSTRACTThis paper describes how we successfully applied the principles of systems engineering to the process of creating online documentation for an existing commercial software product. Using systems engineering principles, coupled with a commercial systems engineering tool, we were able to reduce the time to market for our online documentation system from five years to sixteen months, which translates into a 50% saving in personnel and a 60% saving in product delivery schedule.
A Framework for a Decision Support System (DSS) Architecture for Air Traffic Management
Authors: Sinha Agam N. , Willingham Frank L. 
Published: November 2014

ABSTRACTThe current Air Traffic Management (ATM) system in the United States supports a wide variety of users in providing a safe and efficient air transportation system. The ATM system has to be responsive to the changing needs of its users. One of the challenges in the ATM system evolution is to design the evolution of a Decision Support System (DSS)/automation architecture. This paper proposes a framework and a common language for understanding the different aspects of a DSS architecture.
The Air Bag System: What Went Wrong with the Systems Engineering?
Authors: Buede Dennis M. 
Published: November 2014

ABSTRACTThe air bag restraint system in automobiles has received a great deal of attention since the summer of 1996. The purpose of this paper is to review the successes and failures of the air bag since its introduction in 1988 and to relate these successes and failures to the requirements that led to the current air bag design. Finally suggestions are made about how the requirements development process can be improved for all systems, considering the obvious and not‐so‐obvious mistakes that were made during the development of the air bag.
Rebaselining of the Plutonium Residue Elimination Project at Rocky Flats Environmental Technology Site
Authors: Sailor W. C. , Catlett D. S. , Burns T. P. , Conner W. , Moody D. C. , Muscatello A. C. , Norris T. L. , Parker M. A. , D'Amico E. , Rivera M. , Sendelweck V. 
Published: November 2014

ABSTRACTSystems Engineering and Value Engineering principles were put into practice in rebaselining the Pu Residue Stabilization and Elimination Project at the Rocky Flats Environmental Technology Site. Tradeoff studies were conducted as to how to best rebaseline the system under the new Safeguards Termination Limits (STLs) issued by the Department of Energy. Through the use of a computerized database, the means by which Stakeholder values and other high‐level requirements have been included in the tradeoff studies were documented.
DEVELOPMENT OF THE ENVIRONMENTAL MANAGEMENT INTEGRATED BASELINE AT THE IDAHO NATIONAL ENGINEERING LABORATORY USING SYSTEMS ENGINEERING
Authors: Murphy James A. , Caliva Robert M. , Wixson James R. 
Published: November 2014

ABSTRACTThe Idaho National Engineering Laboratory (INEL) is one of many Department of Energy (DOE) national laboratories that has been performing environmental cleanup and stabilization, which was accelerated upon the end of the cold war. In fact, the INEL currently receives two‐thirds of its scope to perform these functions. However, the cleanup is a highly interactive system that creates an opportunity for systems engineering methodology to be employed. At the INEL, a group called EM (Environmental Management) Integration has been given this charter along with a small core of systems engineers. This paper will discuss the progress to date of converting the INEL legacy system into one that uses the systems engineering discipline as the method to ensure that external requirements are met.
Department of Energy Environmental Management Complex‐Wide Integration Using System Engineering
Authors: Fairbourn Paul 
Published: November 2014

ABSTRACTA systems engineering approach was successfully used to recommend changes to environmental management activities across the DOE Complex. A team of technical experts and systems engineers developed alternatives that could save tax payers billions of dollars if the barriers are removed to allow complete implementation. The alternatives are technically‐based and defensible, and are being worked through the stakeholder review process. The integration process and implementing project structure are both discussed.
Lessons Learned from Use of a Computer‐based Requirements Management Tool in the Project Configuration Control Board Environment
Authors: Meilich Abe 
Published: November 2014

ABSTRACTThis paper presents some lessons learned in Requirements Management (RM) utilizing a computer‐based tool in conjunction with a Configuration Management process and with the oversight of a Project Configuration Control Board. Computer‐based RM tools should help facilitate systems engineering on large complex system development projects. But, sometimes, the drive to either develop tools or purchase Commercial Off‐the‐Shelf (COTS) RM tools early in the life of a project is often pursued without a thorough understanding of the process, environment, or culture in which the tools will be used. The individual or group responsible for tool procurement is often not the same as those that will have to manage the tool as part of an overall systems engineering process. Those who are responsible for procuring the tool sometimes are overly attracted to the flexibility and number of features the tool provides (i.e., typical vendor selection criteria checklists), only to find that the flexibility adds more problems and choices than the requirements analyst was prepared for. Under this scenario, the final tool choice features must be severely constrained, to manage and report the requirements and their dependencies to the Project Configuration Control Board. While taken from experience, the specifics of the actual projects used as a model for this paper and the computer‐based tool vendor names have been deliberately removed to better focus on the issues addressed in the paper.
The Simulation Based Acquisition Vision and the Role of an Integrated Engineering Tools Environment
Authors: Karangelen Nicholas E. 
Published: November 2014

ABSTRACTThe dramatic reductions required in complex system acquisition life cycle cost and development schedule cannot be achieved via incremental systems engineering process and method improvements. A bold innovative shift is required which includes a focused employment of emerging simulation and modeling technologies to the systems engineering challenge. This paper describes an emerging systems acquisition paradigm, referred to as Simulation Based Acquisition, which is embodied by three principal components: (1) an advanced SBA systems engineering environment which employs formal methods and automation to support efficient design synthesis, capture and assessment as well as other complex system lifecycle activities; (2) a refined system acquisition process which takes advantage of SBA engineering environment capabilities; and (3) an evolved culture where enterprise wide cooperation is the rule and individual technical contributions and innovations are encouraged and efficiently managed.
Lessons Learned Applying Model‐Based System Engineering Methods to a Strategic Planning Activity
Authors: Baker Loyd 
Published: November 2014

ABSTRACTA recent strategic planning effort at the Savannah River Nuclear Site successfully utilized a model‐based system engineering approach to develop a plan for the disposition of stored nuclear waste material. In the beginning, many team members, as well as program management, did not understand how system engineering methods and tools could possibly help the team accomplish its objectives. The perception was that a system engineering approach was overkill – all that was needed were domain experts, a facilitator, and a scheduling tool. Introduction of the model‐based approach improved the team's ability to communicate their ideas and intentions. This paper presents the lessons learned during the effort to produce a well received strategic plan, including the supporting information data package that justified our conclusions.
No Matter What The Application, It Is Still Systems Engineering
Authors: Bahill A. Terry , Gissing Bruce 
Published: November 2014

ABSTRACTHumans (individually, on teams, and in organizations) can follow simple processes to increase their probability of success. Many people, both technical and non‐technical, have recently described processes for doing diverse things like designing a system, reengineering a company, teaching a course and solving personal problems. This paper illuminates the amazing similarities in these processes.
A User‐Centered System Development Model Based on Facilitator‐Assisted Requirements Elicitation (FARE)
Authors: Gambhir S. S. Gulu , Scotti Richard S. 
Published: November 2014

AbstractThere are numerous examples of system developments which have not been entirely successful based on cost, schedule, and technical criteria. Many development problems have been traced to poor system requirements. This research introduces a user‐centered system development model which begins with user participation during the requirements elicitation phase. The Facilitator Assisted Requirements Elicitation (FARE) method is introduced, in which a technical facilitator acts as a neutral third party who bases discussion of requirements on concepts of operations (CONOPS) and use‐cases. User involvement continues throughout the system development lifecycle via participation in Integrated Product Teams, design reviews, and human‐machine interface reviews. End‐users take ownership of the System Requirements Specification (SRS); the system design; validation, transition, and training plans; and ultimately the delivered system.
A Process for Requirements and Architecture Definition
Authors: Martin James N. 
Published: November 2014

ABSTRACTA Requirements and Architecture Definition Subprocess has been defined that provides an orderly and iterative definition of the problem and development of the solution. This subprocess consists of 5 activities comprising 40 tasks. The subprocess is described in the context of a larger Systems Engineering Process that has developed over the last six years and was designated by AT&T as a Best Current Practice.
Implementation of the Systems Engineering Discipline
Authors: Bruno Michelle E. , Mar Brian W. 
Published: November 2014

ABSTRACTThe functions or roles of the systems engineering discipline are well documented in literature. However, the opinions vary with many overlaps and there is no focus on implementation of systems engineering based on the size of the company. This paper summarizes the results of a survey conducted across companies of various sizes that perform systems engineering to determine which systems engineering life‐cycle activities are supported, who performs these activities, and how does a company decide who should perform these activities. The survey data indicates large companies implement systems engineering differently than medium and small companies.
An Approach to Successful Integrated Product and Process Development (IPPD)
Authors: Thornton John A. , Luczak Michael A. 
Published: November 2014

ABSTRACTToday's Department of Defense (DoD) acquisition environment challenges program managers with seeking new, innovative and efficient ways to develop their systems. One of the ways in which the government and contractor program managers for the Navy's Advanced Deployable System (ADS) Program have responded to this DoD challenge is through implementation of an Integrated Product and Process Development (IPPD) methodology for their system development. This article describes the program's successful IPPD implementation for development of its Underwater Segment and offers recommendations to other program managers interested in embarking on such a path.
A Spreadsheet Implementation of QFD and Systems Engineering Approaches to Support Concurrent Engineering
Authors: Doukas Louis , Pollock Graham , Jeyaratnam Canestus 
Published: November 2014

ABSTRACTFor an organisation to sustain its competitive advantage, there is a strong need for timely adjustment to ever rapidly changing customer demands. To achieve this goal, known customer needs must be prioritised and transformed into organised down stream design requirements. This paper describes how a spreadsheet framework has been developed which incorporates a modified Quality Function Deployment (QFD) and Systems Engineering Process (SEP) for product development and planning. The application of Analytic Hierarchy Process (AHP) is used as a means of ranking top level user requirements. The methodology provides a pro‐active means and a strong link between quantified user requirements that are prioritised and product design/performance requirements, by assuring that down‐stream design requirements are incorporated into trade‐off decisions. An example is also presented to test and evaluate the spreadsheet approach in heavy engineering projects.
Thoughts About Life Cycle Phases
Authors: Lake Jerome G. 
Published: November 2014

ABSTRACTThe question “What are the life cycle phases that a system must go through?” has been one of interest and confusion to many folks involved with engineering systems. The problem is that a set of life cycle phases is established from the perspective of a singular domain without consideration or knowledge of other domain life cycles. Thus, when a discussion is held with someone outside a particular domain, the life cycle phases are found to differ significantly by number, name, and purpose. These differences create confusion, misunderstanding, and often conflict.This paper is designed to put some order to the various domains of thought about life cycles. Four kinds of life cycles are discussed: Acquisition, Project, Development, and Product. The key life cycle of these four is Development. How this life cycle relates to the other three is a focus of this paper.The Development Life Cycle is akin to the spiral model and incremental builds approach used for software development.The premise is that life cycle phases are defined and implemented to manage the inherent risks involved with engineering a system.
Concurrent Engineering and more… A Systematic Approach to Successful Product Development
Authors: Wenzel Stefan , Bauch Thomas , Fricke Ernst , Negele Herbert 
Published: November 2014

ABSTRACTThis paper describes the CE+ Model, a comprehensive and systemic approach to assess and change product development processes successfully. First, a general description of new product development processes is given (Cycle Model). The second part introduces the “hierarchical” CE+ Model which is derived from the uppermost goal of a company: economic success. Focusing the economic success four general levers are explained how to reach this target. An elementary part of the CE+Model are 17 Essentials (WHATs), which describe what has to be done in order to generate an effective development system. Depending on the characteristics of the industries and companies analyzed, specific Practices (HOWs) are related to the Essentials in the House of CE+. Finally, all methods and tools are used by human beings. They need a solid and sound environment (soil) where they are able to develop their strengths.
No Innovation Process without Changes, but…
Authors: Fricke Ernst , Gebhard Bernd , Negele Herbert , Igenbergs Eduard 
Published: November 2014

ABSTRACTThere is no innovation process and no engineering of successful systems without any change, but it is absolutely necessary to understand and have a good grip on changes. Based on an analysis in German industry, five strategies are proposed to overcome problems and risks of changes in product development.
Systems Engineering Education Demystification: The Saga of Developing a University SE Certificate Program
Authors: Brown Charles F. , Kfoury Nicholas F. , Flowers Shirlee J. , Korman Howard F. 
Published: November 2014

ABSTRACTThe Inland Empire Chapter (IEC) sponsored and created a Systems Engineering Certificate Program with the University of California, Riverside (UCR). The program outline and action plan was developed by the IEC and accepted by UCR College of Engineering and UCR Extension. The paper describes how the certificate program started in 1994 and the first series of courses was developed. The lessons learned from that Series I, ending March 1996, resulted in improvements made to the Series II courses which began September 1996. We will share our experiences and focus on the key areas that require the most attention in the hope that it will help other chapters when a systems engineering certificate program is developed in cooperation with a local educational institution.
A Guide to CASE Tools in Support of System Architecting
Authors: Hyer Scott A. , Kauffman Donald C. , Hatley Derek J. , Parker Thomas A. , Chasse John L. 
Published: November 2014

ABSTRACTThe rapid pace recently established by the Computer Aided Systems Engineering (CASE) tools industry provides opportunities to constantly look ahead and challenge tools to do more in support of complex systems development. This situation also forces CASE tools users to cry out for guidance in defining tool capabilities and selecting from among the growing list of candidates. The INCOSE Systems Architecture Working Group (SAWG) has produced version 1.0 of “A Guide To CASE Tools in Support of System Architecting” (dated May 1997) to address such a need for guidance. The guide is written to give the CASE tool novice a starting point and to give the more experienced CASE tool user some considerations for advanced capabilities.
TOOLS INTEGRATION INTEREST GROUP REPORT: SCENARIOS FOR A CONCEPT OF OPERATIONS FOR AN INTEGRATED SYSTEMS ENGINEERING ENVIRONMENT, Part II
Authors: Schier James , Nallon John , Arnold Eileen 
Published: November 2014

ABSTRACTThe Tools Integration and Interoperability Working Group (TIWG) is developing a Concept of Operations and a Specification for an Integrated Systems Engineering Environment (ISEE). Last year's TIWG Report (Reference 1) focused on the development of an initial set of scenarios leading toward the development of the full Concepts of Operations. This paper collects the next set of three scenarios which have been developed. The scenarios presented address: (1) the process of defining an organizational systems engineering process; (2) the set of processes associated with administration of an ISEE as part of an organization's information infrastructure; and (3) the process of assessing an organization's systems engineering capability. Based on these process oriented scenarios, we discuss the requirements which an integrated tool suite will have to meet to provide user's with the desired capabilities. The discussion also addresses the technological needs and feasibility of developing an ISEE.
Principles Working Group 97–98 Summary Report
Authors: Alessi Sam , McCumber William H. 
Published: November 2014

ABSTRACTThis paper reports the activities and current state of the INCOSE working group on principles. The working group approaches systems engineering principles as a trichotomy – three distinct views of principles: mathematical, philosophical and pragmatic. Working sessions at the 1997 INCOSE symposium developed an outline for a text, “Logical and Mathematical Principles of Systems Engineering,” a framework for foundation philosophy and two sets of pragmatic principles, all of which are reported in this paper.
2.1.2 Contingency and Disaster Recovery Engineering: A Discipline within A Discipline
Authors: Botten LeRoy H. , Riggs Donald A. 
Published: November 2014

ABSTRACTThe adaptation of accepted systems engineering methods to contingency and disaster recovery (C&DR) engineering applications is described. A recent C&DR planning project is briefly discussed, and lessons learned in applying the C&DR engineering method are provided. The structure of a decision support tool (implemented as a Microsoft Excel spreadsheet) used to aid in assessment of and response to C&DR emergencies is described.