bluuebunny/crossref_metadata_2025_split huggingface dataset:
A SYSTEM ENGINEERING APPROACH FOR THE MIGRATION OF COMPUTER‐BASED SYSTEMS
Authors: Makhlouf Mahmoud A. , James John H. , Wigfield Edward C. , Wheeler Thomas M. , Modeen Raymond A. , Schaffner Stuart C. 
Published: November 2014

ABSTRACTIn this paper major factors contributing to system migration failures are reviewed. We highlight the need for a comprehensive system engineering approach that can address the inherent complexities of migrating mission critical systems. To address this need, a model‐based approach supported by tools is presented. Central to this approach is the use of a new type of system architecture model called “Loop Relationship (LR) Models.” These models are used to recover the legacy system design, specify the migrated system requirements and proposed system design; and analyze the performance implications of proposed modifications to the legacy system. Finally we will discuss our experience in forming a team to apply the above approach on a number of system migration projects.
EVALUATION OF THE FEASIBILITY OF USE OF A COMMERCIAL OFF‐THE‐SHELF (COTS) OBJECT‐ORIENTED DATABASE MANAGEMENT SYSTEM FOR REAL‐TIME TACTICAL APPLICATIONS
Authors: Gracia Paul , Larson Stephen 
Published: November 2014

ABSTRACTThis paper describes the development and evaluation of a prototype tactical database for a new military command and control system. The database was developed using a commercially available object‐oriented database management system, and was integrated with seven user applications in a heterogeneous networked computer environment. Testing of the database took place as part of the Navy's New Attack Submarine (NSSN) Program Phase I Open System Critical Item Test (OSCIT) demonstration, conducted during late September 1995. The testing showed that use of a commercial database management product to support limited real‐time applications in a tactical command and control system is feasible. This indicates that the Navy could realize significant savings in this technical area through the use of commercially available products.
Engineering Information Systems and the IEEE Std 1220–1994
Authors: Rochecouste Hervé 
Published: November 2014

ABSTRACTThe IEEE Standard for the “Application and Management of the Systems Engineering Process” (IEEE Std 1220–1994) is the first standard that recommends (para. 4.6, 6.8.12) the use of an “Integrated Database” to assist the Systems Engineering Process (SEP). As technology evolves, and projects become more and more complex, the application of the SEP generates megabytes of data that must be managed effectively. This paper analyses the intent of the IEEE recommendations, and discusses the concept of an Engineering Information System in support of the SEP application for the Engineering of Computer Based Systems. Without integration, the independent tools of Requirements Analysis and Management, Design Modelling, Configuration Management etc. may end up removing value from Systems Engineering work.
AN OPEN LETTER TO THE TOOL COMPANIES
Authors: Grady Jeffrey O. 
Published: November 2014

ABSTRACTAll of the requirements tools developed to date for commercial sale attempt to satisfy the largest possible set of functionalities that the developing company is capable of mastering. As a result, these tools tend to be fairly difficult to master by users and for the users to maintain skills. The tool companies tend to focus inwardly on their own tool without sufficient interest in the common environment within which these tools are used. The tool companies apparently feel they have to protect their market share to the extreme of failing to contribute to raising the floor for all.Engineers in many aerospace companies feel a need for a requirements system that is very simple to use by a wide range of people without intensive initial and recurrent training. But, there are no suppliers of this kind of system. This “open letter” encourages the development of a tool that is focused on the simplest needs that can be supplemented with additional modules to satisfy more advanced needs when the user has matured their process and personnel skills to support those capabilities.Also, the tool companies tend to ignore the industry interest in universal hooks that would permit two or more tools to be applied on one program without sacrificing some of the fundamental tool features like traceability across the gaps. Many years ago gasoline station operators found that locating stations on all four corners led to more business for all rather than hurting each. A degree of cooperation among the tool makers would have this same effect by expanding the market size.
TRANSITIONING THE SAFER MANEUVERING UNIT FROM FLIGHT TEST TO PRODUCTION
Authors: Hess Cliff , Steele Gail , Hooks Ivy 
Published: November 2014

AbstractMany programs face the problem of building a single product that mushrooms into new versions or additional products. Requirements reuse can be a tremendous time and cost saver, but only if other essential information is retained when the original requirements are written.The Simplified Aid for EVA Rescue (SAFER) began as a flight test unit that was flown as a Detailed Test Objective (DTO) on Space Shuttle Mission STS‐64 in September 1994. The SAFER proved its usefulness as an astronaut maneuvering unit and was approved for production immediately after the flight. This paper details the requirements management process used by SAFER and discusses the changes required to go, not just to production, but also to an intermediate version of the product. The SAFER project used Compliance Automation Inc.'s Document Director requirements management tool for the DTO and transitioned to Vital Link, the Window's version of the tool for subsequent products.
Lessons Learned From Use of a Computer‐based Requirements Management Tool in the Environment of a Project Configuration Control Board
Authors: Meilich Abe 
Published: November 2014

AbstractThis paper presents some lessons learned and experience gained 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 done 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 are often not the same as those that will have to manage the tools as part of an overall systems engineering process. Those who are responsible for procuring the tool sometimes get caught up in the flexibility and number of features the tool provides (i.e., typical vendor selection criteria checklists), only to find out later that the flexibility which the final tool choice has must be severely constrained, in order to manage and report the requirements and their dependencies to the Project Configuration Control Board. Even though taken from actual experience, the specifics of the actual projects used as a model and the computer‐based tool names have been deliberately removed from this paper to better focus on the issues addressed in the paper.
The Application of a Tool Like RDD‐100® to Accommodate Traceability from Requirements to Test Results
Authors: Smith Byron 
Published: November 2014

AbstractThis paper will focus on the ability to capture a full thread of traceability, from the inception of a requirement, to the test results that validate that the system (element) designed meets criteria defined by that requirement. As contracting agencies become more and more sophisticated, they are expecting their contracted agents to define a thread of traceability to include the test results that validate a design. The following paragraphs describe a process that can be used to enhance the effectivity of using a tool like RDD‐100® in the System Engineering process.
CRITICAL PROCESS ASSESSMENT TOOL (CPAT) FOR ACQUISITION REFORM IN DOD
Authors: Rountree Richard C. , Crabtree William , Davis David E. 
Published: November 2014

AbstractAcquisition reform within the U.S. Department of Defense (DoD) has induced a wide variety of innovative engineering methodologies on the part of Air Force agencies such as the Space and Missile Systems Center (SMC) in El Segundo, CA to minimize government risk. One of these methodologies is a set of Critical Process Assessment Tools (CPATs) being developed to support project officers and project engineers: (1) in preparing Requests for Proposals (RFPs), (2) for subsequent source selection or factfinding, and (3) to participate in or review contract execution after contract award. CPATs are applicable to processes that, because of risk, are considered to be critical to execution of the involved contract. The Systems Engineering CPAT (SE‐CPAT) is the overriding element in the set since it is most likely to be critical to the success of a contract when new military or other system functional requirements are to be levied or requirements allocations and/or design must be changed for some reason. Furthermore, the SE‐CPAT serves as the integrator of other multidisciplinary engineering CPATs acting under the Integrated Product Development environment. The SE‐CPAT described in this paper, and available on the Internet, identifies a menu of objectives and other inputs to a RFP, factors and standards for source selection, and key questions for conducting technical evaluations and factfinding, and post‐contract award reviews. Throughout the paper selected SE‐CPAT excerpts are provided.
SYSTEMS ENGINEERING'S ROLE IN THE RFP PROCESS
Authors: Clouse Aaron J. , Shaw Richard 
Published: November 2014

AbstractMany companies that develop products in the defense industry rely on the DoD Request For Proposal (RFP) process as the principal means for acquiring new business. While the process steps used by each company may vary in the details, the general RFP requirements demand that certain steps be accomplished by all participants. It is also at this early stage of acquisition where the Systems Engineer plays a significant role. This paper presents an outline of the process of responding to DoD Requests For Proposals (RFP's) and discusses the process steps that most naturally involve Systems Engineers. Finally, it points out the benefits of having a well‐documented proposal process.
Technical Objectivity Supporting Systems Engineering for Internal R&D Projects
Authors: Hand James A. , Gilmore Jerold P. , Lawrence  , Freier J. 
Published: November 2014

AbstractThree capabilities, or intellectual tools, are considered particularly important to Research and Development (R&D); namely Technical Objectivity, Technical Depth and Technical Breadth. In this brief report we deal with the first tool and leave the latter two for a future paper. The paper concentrates on the system engineering process in company‐funded Internal R&D. The intent is to illustrate Technical Objectivity as a tool in addressing internal and external corporate product innovation barriers, and as an essential element in achieving an IR&D product's commercial success in the market place.The systems engineer's task of identifying, acquiring and applying Technical Objectivity is discussed, including characteristics and applications. This task is applicable (tailorable) to several types of IR&D efforts within the fast moving infotech, biotech ‐ medical, telecommunications, instrumentation/electronics, and engineering/technical services industries, as well as the aerospace and defense industries.Our main observation is that Total Technical Objectivity for planning and operating IR&D projects is a capability found in a team, rather than in an individual.
SYSTEM REQUIREMENTS ENGINEERING PROCESS
Authors: Field Melvin D. 
Published: November 2014

AbstractThe system requirements engineering process is a systematic and comprehensive approach to the development, allocation and management of functional, performance and interface requirements and design constraints over the system or product life cycle. Users, developers and managers use a common, structured communications media to build and manage, an integrated requirements database to develop, operate and maintain a system or product effectively. System or product quality and timeliness can be improved. Concurrent system engineering is feasible.A primary objective is to maintain traceability (both down and up) between user requirements and system and/or product design requirements during development and system or product use. The system requirements engineering process is usable for new acquisitions and for product improvements and supports the system engineering process as defined in IEEE P1220 and EIA 632/MIL‐STD‐499B.
Systems Engineering: A Problem of Perception
Authors: Senglaub Michael 
Published: November 2014

AbstractThe characterization of systems engineering as a discipline, process, procedure or a set of heuristics will have an impact on the implementation strategy, the training methodology, and operational environment The systems engineering upgrade activities in the New Mexico Weapons Development Center and a search of systems engineering related information provides evidence of a degree of ambiguity in this characterization of systems engineering. A case is made in this article for systems engineering being the engineering discipline applied to the science of complexity. Implications of this characterization and some generic issues are delineated with the goal of providing an enterprise with a starting point for developing its business environment.
Unraveling the Systems Engineering Lexicon
Authors: Lake Jerome (Jerry) G. 
Published: November 2014

AbstractTerms related to systems engineering have had a tempestuous history, at least for the years that the International Council on Systems Engineering has been in existence. The term “Systems Engineering” has been at the center of the confusion.This paper looks at the history and problems associated with defining systems engineering and then applies a systems engineering approach to provide definitions of what systems engineering is and what systems engineering does.The definitions provided in this paper are not to end the discussion but to stimulate more discussion.
AGGREGATE SYSTEMS ARCHITECTING
Authors: Grady Jeffrey O. 
Published: November 2014

ABSTRACTThe INCOSE definition of a system recognizes the existence of the components, items, or elements of which the system consists. This paper addresses the development of systems where those components are systems themselves in several specific subsets of the full range of possibilities with which a developer may be confronted. The developer should evaluate alternative system functionalities and configurations leading up to selection of a preferred solution, but this same well understood activity can be extended to embrace the development of families of systems to serve several needs of interest to the developer and its potential customer base. The tool makers are challenged to support this capability.
Architecting Principles for Systems‐of‐Systems
Authors: Maier Mark W. 
Published: November 2014

AbstractWhile there is growing recognition of the importance of “Systems‐of‐systems,” there is little agreement on just what they are or on by what principles they should be constructed. This paper proposes a taxonomy of these super‐systems and exhibits a basic set of architecting principles to assist in their design. While several heuristics are particularly applicable to systems‐of‐systems, the key insight is the central role played by communication standards. The enabling architecture of systems‐of‐systems is non‐physical, it is set of standards that allow meaningful communication among the components. This is illustrated through existing and proposed systems.
How to Survive as a Change Agent in Hostile Territory: “Principles of Process Improvement Terrorism”
Authors: Garcia Suzanne M. 
Published: November 2014

AbstractProphets have always run the risk of being disregarded in their own land. Many champions of organizational change face the same problem as the prophet–their message is clear, but it is not attended to by those in positions of power to make the necessary changes. I call these prophets of change “process improvement terrorists”, not because they are physically violent, but because they are often forced to work underground, outside the conventional power and communication channels of the organization, their weapons are obtained from unconventional sources and are applied in unconventional ways, and their situation is much like that of the terrorist – often in hostile territory, needing to take drastic but often subtle actions to get their message heard and acted upon. Terrorism is used as a “processmorph” for process improvement (see body of paper for a definition). This paper provides survival and (hopefully!) success strategies for the change champion who has had to go to ground and become a Process Improvement Terrorist (PIT).
SPENT NUCLEAR FUEL APPLICATION OF CORE® SYSTEMS ENGINEERING SOFTWARE (U)*
Authors: Grimm R. J. 
Published: November 2014

AbstractThe Department of Energy (DOE) has adopted a systems engineering approach for the successful completion of the Spent Nuclear Fuel (SNF) Program mission1. The DOE has utilized systems engineering principles to develop the SNF Program guidance documents and has held several systems engineering workshops to develop the functional hierarchies of both the programmatic and technical side of the SNF Program. The sheer size and complexity of the SNF Program, however, has led to problems that the Westinghouse Savannah River Company (WSRC) is working to manage through the use of systems engineering software. WSRC began using CORE®, an off‐the‐shelf PC based software package, to assist the DOE in management of the SNF Program. This paper details the successful use of the CORE® systems engineering software to date and the proposed future activities.
DOORS™ TO AUTOMATED METRICS
Authors: Miller William D. 
Published: November 2014

AbstractThis paper describes the automation of metrics data collection and analysis using the Dynamic Object Oriented Requirements System (DOORS™) tool from Quality Systems and Software (QSS). Using the concept stated by Crosby that “Quality is conformance to requirements”, DOORS tracks the completeness, timeliness, and cost of project deliverables that are the outputs from standard processes. The traceability links in DOORS bind the project and process metrics together to higher level organizational objectives. Metrics automation based on a foundation of standard processes, methodologies, tools, and environment provides a quantum improvement in the objectiveness, cost, and fidelity of metrics. Also, metrics definitions important to organizations change over time. The change control capability of DOORS provides complete history to the ongoing metrics collection and analysis to provide a continuum from past performance to the present and future.
“MIL‐STD‐001” ‐ A SYSTEM STANDARD (THEORY OF SYSTEMS = ACQUISITION REFORM!*)
Authors: Marshall John A. 
Published: November 2014

AbstractProduct improvement means product behavior understanding; Acquisition process begs for it. Needed: more focus and vision on product performance: Without it, at best incremental improvement; With it, the bigger, better view for system Continuous Process Improvement (CPI). Here is a new & improved view.
ADAPTATION OF A SOFTWARE REQUIREMENTS ENGINEERING METHOD TO THE SYSTEM LEVEL FOR SOFTWARE‐INTENSIVE SYSTEMS
Authors: Crowe Dennis , Smith Howard , Haberli Greg , Cohen Robert M. , Lykins Howard 
Published: November 2014

AbstractThis paper reports on an investigation of the adequacies and benefits of applying software‐level analysis techniques to system‐level requirements activities, with specific concern for software‐intensive systems. The investigation takes the approach of adapting a well‐defined, mathematically precise, software requirements engineering method to a real‐world, complex, system engineering problem. This case study is a preliminary application of the Software Productivity Consortium's CoRE method, which has been applied to embedded real‐time applications, to developing requirements that will be allocated to the landing capability of a military combat helicopter. This effort takes a step toward model‐based system engineering by addressing some of the representational issues and semantic gaps that make it difficult to model subsystem‐level behavior from the system level without commitment to system architectures and designs. This paper proposes conceptual representations that support multitiered abstraction of performance measures and requirements for analyzing interactions between elements of a system and their external environments.
VALIDATION OF TRADE OFF STUDY METHODS APPLICABLE TO PACKAGE‐BASED ENGINEERING
Authors: Botten LeRoy H. 
Published: November 2014

AbstractA mature tradeoff study methodology, developed over the past 25 years, is shown to be consistent with emerging package‐based engineering methods. The tradeoff study methodology and related experiences in implementing complex systems from commercial off‐the‐shelf (COTS) and legacy components are described. Validation of the methodology as a tool for Integrated Process Team use in package‐based engineering is presented.
THE APPLICATION OF QFD TO SUPPORT A MISSION NEEDS ANALYSIS
Authors: LaSala Kenneth P. , Phillips Brent W. , Wallace William E. 
Published: November 2014

AbstractThe technique of Quality Function Deployment (QFD) has been applied to an analysis of the mission needs for the existing NOAA atmospheric observing system. QFD shows clear relationships between customer needs and the observing system capabilities. QFD will play an important role in the continued evolution of both the customer needs and the observing system itself. We believe that QFD can contribute significantly to the development of Government mission needs analyses for systems similar to our observing system. Although this paper discusses the use of QFD within NOAA, the views expressed in this paper are solely those of the authors and do not necessarily represent the views of NOAA.
Evaluation of Risk Management Strategies for a Low‐Cost, High‐Risk Project
Authors: Shishko Robert , Jorgensen Edward J. 
Published: November 2014

AbstractThis paper summarizes work in progress to define and implement a risk management process tailored to a low‐cost, high‐risk NASA mission–the Microrover Flight Experiment (MFEX, commonly called the Mars microrover). The tailored risk management process is described along with the extensive data collection, documentation, and quantitative analyses that are being performed. This effort has the explicit purpose of trying, evaluating, and documenting new risk management techniques so as to help not only the MFEX mission, but future missions in the same risk class.