bluuebunny/crossref_metadata_2025_split huggingface dataset:
THE UNWRITTEN LAWS OF SYSTEMS ENGINEERING
Authors: McClinton David F. 
Published: November 2014

AbstractThe paper states some of the unwritten but spoken laws that abound in any engineering project. The laws are really simple basic truths that arise in typical engineering discussions. We didn't hear them in engineering school but they came through loud and clear in that school of hard knocks, the engineering project. The initial three laws are (1) Everything interacts with everything else; (2) Everything goes somewhere; and (3) There is no such thing as a free lunch. Several other laws capture the lessons learned in various activities in the systems engineering process.
A Draft Systems Engineering Tools Taxonomy and Mapping to a Meta‐Process Model
Authors: Oliver David W. , Steiner Rick 
Published: November 2014

AbstractThe goal of this paper is to provide a draft classification of tools that may be useful to systems engineers in understanding tool choices for the automation of their work. An accepted classification will require input from NCOSE members and modification of the draft.The tools automate the systems engineering process. Each kind of tool performs particular functions and captures particular sets of information. In this paper the tools are mapped to a meta‐model for the systems engineering process. That meta‐model describes the core systems engineering steps and gives an information model for each step. Mapping the tools to the meta‐model defines the functions performed by each tool type and the information it captures. The mapping also establishes the interfaces between tool types.
COLLABORATIVE SYSTEM ENGINEERING APPROACH TO AN EVOLUTIONARY OCEANIC SYSTEM DEVELOPMENT
Authors: Feerrar Wallace N. , Sinha Agam N. 
Published: November 2014

AbstractThe Federal Aviation Administration (FAA) is in the process of developing significant new capabilities in the Oceanic Air Traffic Management (ATM) System in response to the increasing demand on the system and the needs of the users of the oceanic air traffic management system. The FAA has planned for an evolutionary approach to the oceanic system development with a series of successive “Builds” adding new operational capabilities. The Center for Advanced Aviation System Development (CAASD) at The MITRE Corporation is providing the system engineering support to the FAA in this effort. One of the major components of the R&D system engineering process is the generation/validation of operational concepts and requirements for the successive Builds. A second, equally important, element is the requirements tracking/traceability process to ensure that the system evolution does indeed provide the operational capability to the users/operators/maintainers of the system. This paper describes some innovative measures (including the use of CASE tools) for the life cycle of the evolution of the Oceanic ATM System.
Business Reengineering for Information Technology: From Business Process to System Requirements
Authors: Bohner Shawn A. , McGowan Clement L. , Harlow Mary M. 
Published: November 2014

AbstractThe bridge between business process and information systems reengineering is all too often missing from the roadmap of reengineering efforts. When process and system engineers get to this transition, they discover a rickety old bridge with steep terrain on either side of a wide chasm. Recognizing this dilemma, we developed the Business Reengineering for Information Technology (BRIT) approach that systematically transitions from business process to information systems engineering. BRIT is designed to handle a wide range of reengineering factors including: “best practices,” COTS applications, non‐standard business processes, and change situations ranging from continuous improvement to radical restructuring. This proven approach is described here with relevant examples of its applications.
COTS/NDI ASSESSMENT AND SELECTION METHODOLOGY
Authors: Verma Dinesh , Powers Tipmuny , Blanchard Benjamin S. , Giffin Ralph G. , Webb Rowland , VanBuskirk David 
Published: November 2014

AbstractIn an effort to radically reduce system development times and necessary resources, the Department of Defense (DoD) is emphasizing utilization of “Commercial‐Off‐The‐Shelf (COTS)” or “Non‐Developmental Items (NDI)” in the development of new systems and the upgrade of existing systems. This paper outlines a methodology, involving the integrated application of Quality Function Deployment (QFD) and Analytic Hierarchy Process (AHP), to facilitate the prerequisite analysis and evaluation before making a commitment to a COTS/NDI alternative. While this COTS/NDI analysis and evaluation methodology is generic in its applicability within the system engineering process, in its current state the model based on this process has a system supportability bias.
CONDUCTING A TECHNOLOGY MANAGEMENT ASSESSMENT
Authors: Mackey William F. 
Published: November 2014

AbstractTechnology management is concerned with minimizing the risks associated with new technologies and ensuring the successful integration of those technologies into systems and operations. The role of an Advanced Technology Manager is to identify the technologies that will enhance project operations, identify applications throughout the project that can benefit from appropriate new technologies, and ensure that these technologies are developed and/or transferred for insertion into operations.This paper describes the past year's experiences conducting technology management assessments for the Mission Operations and Data Systems Directorate (MO&DSD) of NASA's Goddard Space Flight Center (GSFC) and the CSC Systems, Engineering, and Analysis Support (SEAS) project. These assessments are based on a technology management process and on the technology evaluation and analysis methodologies developed for the NASA/GSFC New Technology and Data Standards Manager [Mackey 1995]. The paper includes a brief description of the six stages of technology commitment and focuses on the SEAS activities related to the Technology Awareness Stage. Note that the technology management process discussed in this paper is undergoing evaluation and will mature as it is implemented in the coming months.
THE EMERGING ROLE OF TELECOMMUNICATIONS: CREATIVE APPLICATIONS OF SYSTEMS ENGINEERING METRICS
Authors: Buford Carolyn 
Published: November 2014

AbstractThe rate of change in telecommunications business environments has a major impact on the types of key issues worked on by systems engineers. This paper describes a revolutionary prospective on emerging technologies in telecommunication as it impacts systems engineering metrics. The need for new creative metrics applications using telecommunications is exceptionally high for both new and existing business areas. New unique applications are emerging rapidly, with each application changing further the way business is done and the needs for evolving a particular business segment.With these changes in process, planning is essential. The more flexible and creative the planning approaches, the longer the utilization lifespan of the systems. Customers need to be involved in all aspects of the evolutionary process because they play key roles in the process resulting in new and better systems. Progress will be measured with ever‐changing metrics on a flexible metrics framework for gathering information. Tools will be developed to support the entire process from initial goal statement, strategic planning to user access, usage, and evaluation. These developments are the basis for a new world interaction for the concurrent involvement of business, community, and individual.“You have to go twice as fast in order to stay in place.”—Lewis Carroll, Through the Looking Glass
Applying Automated Systems Engineering Tools During The Proposal Process
Authors: Smith Byron J. 
Published: November 2014

AbstractThe proposal process is often characterized by frenzied activities to define a design solution and process by which the solution is to be met. These activities are often compressed into a 45 to 90 day turnaround from the time an RFP is received to the time that a deliverable proposal package must be submitted. Typically, the proposal package contains a technical section that defines how a company is going to address the needs described in the RFP, a cost and planning section defining a cost and work breakdown analysis, a preliminary Systems Engineering Management Plan (SEMP) and a preliminary Integrated Master Schedule. How can tools play a role in the preparation and submittal of a first class proposal package? Traditionally, different tools have been applied to address different aspects of this problem domain. Specific tools were incorporated to address the Program Management aspects of the proposal process. Other tools were deployed to create a plan to describe System Engineering activities. Still other tools were employed to address the design and implementation solution. Because COTS tools have become more sophisticated, it now possible to employ them throughout the proposal process including generation of a SEMP. This paper will focus on how that can be accomplished.
SLATE and the Proposal Process
Authors: Kearney David , Sampson Mark 
Published: November 2014

AbstractThrough the use of a process approach and Systems Engineering tools, a 3x proposal productivity improvement is available. This paper describes an approach to organizing the RFP, gathering the proposal response information, and proposal generation process using SLATE object‐oriented engineering groupware. Approach, proposal development and management process, lessons‐learned, as well as proposal reuse issues are discussed.
Using Object‐Based Simulations for Exploring and Testing Complex Systems
Authors: Schoening William W. 
Published: November 2014

AbstractObject based (and objected oriented) software design of models and simulations frequently focuses on the top down structure of individual players whose components behave in highly predictable ways. Electronics, engines, missiles, cars, tanks, and satellites give well known responses to inputs defined by the designing engineers. These same object based concepts, coupled with a few additional guidelines, can be applied with striking results to the simulation of complex systems of independent objects whose behavior is not predictable. The trick is to recognized that organization and cooperation between independent objects is a feature of the behavior of the objects themselves rather than some global entity that imposes the organization from above.Guidelines for turning object‐based models and simulations of real world systems into highly flexible tools for exploring and testing are discussed. Simulations that follow these guidelines give analysts the necessary visibility so they can be trusted and used for exploring requirements and even testing products before the products themselves are built. The guidelines have evolved over the past seven years based on experience with a variety of software simulation environments and tools to simulate complex systems.
A PRACTICAL EVALUATION OF DATABASE RE‐ENGINEERING TOOLS
Authors: Owens David A. , Bighash Iraj 
Published: November 2014

AbstractThe objective of this study was to investigate tools and processes for evolutionary migration of disparate, legacy databases into a single logical design and a new physical implementation. We began by researching the availability and capabilities of current database re‐engineering tools. After reviewing literature on available tools, we selected several candidates for an in‐depth evaluation. We established a practical evaluation approach which exercised the candidate tools against our proposed re‐engineering process using a subset of the databases in an existing legacy system. The study also included investigating approaches for migrating legacy applications to use the new database design and physical implementation. Based on our evaluation, we recommended a set of tools to support our proposed database re‐engineering approach. These recommendations are directly related to our study project, and may not be applicable to other large‐scale, legacy database re‐engineering projects.
USING MS ACCESS TO MANAGE REQUIREMENTS
Authors: Bell Marty , Jones David A. 
Published: November 2014

AbstractMost commercially available tools that manage requirements are targeted for large projects. Small projects may find them bulky and cumbersome to use for managing a relatively small number of requirements. This paper describes a requirements management tool that is easy to use while providing requirements traceability from upper level specifications to lower level specifications. The tool is called Tracker and is successfully being used on a small project.This paper describes the tool in detail. Advantages and limitations are discussed. A comparison is made to the “INCOSE Requirement Management Working Group Suggested Possible Tool Features”. Benefits and cost estimates are provided. A sample screen and reports are shown and described. Attributes for each requirement is stated and tool performance is discussed.
Enterprise‐Level Regulatory Analysis and Requirements Management
Authors: Latorre Richard , Sampson Mark , Tominey Kathryn , Wildung Nancy J. 
Published: November 2014

AbstractTo improve overall operational efficiency, a formal requirements management program has been initiated at the Pacific Northwest National Laboratory1. The goal of this program is to develop a robust, dynamic, integrated, informative decision base, for Laboratory‐wide use instead of the more typical assemblage and maintenance of many specific “product line” or “product” requirements.The external requirement documents that regulate the Laboratory's activities include U.S. Department of Energy (DOE) Orders, Code of Federal Regulations, State of Washington regulations, industry standards, Tribal and local government consent agreements, contracts, city and county ordinances, other Federal interagency agreements, and Battelle Memorial Institute policies. When these documents get updated or revised, these changes can affect the Laboratory's work.The current estimate is that hundreds of external requirements documents yield thousands of individual external requirements. These documents also have a high degree of variability in format and content, both in a particular document and between document types. Given the large number and scope of issues encompassed by these requirements, our review found that the “historical situation” (i.e., information distributed from personal computers, lists, manuals, procedures, correspondence, and personal memory) was no longer sufficient. No unified requirements analysis set identified all of the individual, applicable external requirements in readily retrievable form, nor were the external requirements linked to the systems to which they apply.Similar external requirement document integration efforts by other organizations have produced work that is obsolete by the time they publish it, because of the failure to address the dynamic nature of the external requirements documents. This report describes an automation tool (“System Level Automation Tool for Engineers” [SLATE]) that we use to support requirements analysis and the ongoing management of requirements. Experience with this tool as a key element of requirements analysis and management in a timely, cost‐effective, Laboratory‐wide manner is discussed.Pacific Northwest National Laboratory is operated by Battelle Memorial Institute for the U.S. Department of Energy under Contract DE‐AC06‐76RLO 1830.
USE OF CORE™ IN THE SYSTEM ENGINEERING OF AN ANALOG ASIC
Authors: Gardner John R. 
Published: November 2014

AbstractThis paper describes the Systems Engineering process utilized to design and document a high speed, mixed signal, Application Specific Integrated Circuit (ASIC), using CORE™ as a requirements traceability and design tool. The paper describes the problem, the design process used and the ways that CORE™ facilitated the process. It shows how CORE™ aided in causing complete design definition through an iterative process and generating the final design documentation.
Specifying A System Using ERA Information Models
Authors: Baker Loyd , Long James E. 
Published: November 2014

AbstractStating the requirements for systems or business processes as a hierarchical collection of English text that can only be analyzed/verified by human inspection has proven time and again to be labor intensive and generally, inadequate. Projects employing a traditional document‐centered system engineering approach have experienced significant numbers of mis‐interpretations of the customer's requirements, or late‐detected design errors results in increased costs, schedule slips, reduced capability, or canceled programs. We have historically fixed requirements problems, that should have been understood and resolved early, during integration and test where it is more costly to identify and fix. Now that computerized system engineering support tools are available on the engineer's desktop, the leading edge aerospace/commercial corporations are transitioning from a document‐centered to a model‐driven system engineering approach to developing, analyzing, and managing explicit system/process specifications. Information and operational models (of varying levels of detail) not only aid in the understanding and communication of intentions such that incorrect assumptions can be eliminated early, they directly support the develop of system verification plans.
DECISIONEERING—A PROCESS SKETCH FOR DECISION SUPPORT SYSTEM DEVELOPMENT
Authors: Wirth John M. , Mar Brian W. 
Published: November 2014

AbstractDevelopers of military command and control decision support systems need to use a decision‐based and user‐centered process for product development. The process must integrate the system's human decision‐maker (system operator, or user), with the other key system components—software and hardware.Decisioneering is a decision‐based, user‐centered process that provides this integration. Its objective is to improve the performance and safety of human‐computer partnerships in process monitoring and control. The approach emphasizes a clear understanding of the operator's cognitive needs and decision‐making environment. Research suggests (Wirth 1995) that the decisioneering methodology should begin as a structured, iterative, build‐and‐test life‐cycle and would encourage (perhaps require) early and committed operator involvement.Several related technical fields (systems engineering, software safety, human‐computer interaction, decision‐making, and cognitive engineering) each contain significant parts of a user‐centered, decision‐based approach. Their salient points are summarized and a sketch of the decisioneering process is given. Conclusions and recommendations suggest methods to implement the decisioneering process for decision support system product development.
TWELVE SYSTEMS ENGINEERING ROLES
Authors: Sheard Sarah A. 
Published: November 2014

AbstractTwelve roles are described which are occasionally or frequently assumed to constitute the practice of systems engineering. Some roles fit naturally as life‐cycle roles, others fit the Program Management set of roles, while still others are not normally thought of in either group. Interactions between the roles are discussed, and the systems engineering roles assumed by the papers in the inaugural issue of Systems Engineering, the Journal of INCOSE, are compared to these categories.
ANATOMY OF THE ENGINEERING OF A SYSTEM
Authors: Harwell Richard , Martin James N. , Lake Jerome (Jerry) G. , Velman John 
Published: November 2014

AbstractThe anatomy of the engineering of a system relies on a uniform approach using an elemental “building block” approach. This approach is applicable at any layer in a system development, whether it be the total system solution, a supplier's sub‐system, or a component provided to a supplier. There are four elements of this fundamental building block: (1) the system, (2) the end product, (3) end product subsystems, and (4) the enabling subsystems. This building block approach was introduced in IEEE 1220–1994 “Application and Management of the Systems Engineering Process,” and will be a central theme of the evolving EIA/ANSI Standard for applying the systems engineering process to the engineering of a system.
A CONCEPTUAL FRAMEWORK FOR A CUSTOMER‐CENTERED SYSTEM DEVELOPMENT LIFECYCLE MODEL
Authors: Scotti Richard S. , Gambhir S. S. Gulu 
Published: November 2014

AbstractThis paper is divided into two parts. The first contains a survey of various system development lifecycle models, including the Waterfall, Spiral, and Evolutionary Models. The second part introduces a conceptual framework for a new approach to complex, large‐scale system developments based upon a customer focus throughout the system development lifecycle. This customer‐focused approach utilizes automated Concept of Operations (CONOPS) and group dynamics techniques to allow greater understanding of end‐user ‘actual’ needs by system designers via more productive interactions. This approach is based on the development and use of detailed user objectives and critical success factors prior to and separate from their mapping into basic and derived system requirements. It provides a means for capturing previously obscure requirements within the user environment and mindset.
The Architectural Metaphor as a Foundation for Systems Engineering
Authors: Hilliard Richard F. , Rice Timothy B. , Schwarm Stephen C. 
Published: November 2014

AbstractOver the history of systems engineering, there have been numerous attempts to establish the foundations of that field on other disciplines. In this paper, we explore a new approach, founding systems engineering on an architectural metaphor. This approach is based upon our work of the past five years to establish a discipline of systems architecture. We outline the key principles of our approach and discuss their relevance to the broader field of systems engineering.
RISK AND OPPORTUNITY MANAGEMENT
Authors: Forsberg Kevin , Mooz Harold 
Published: November 2014

AbstractMany people are searching for the secret to success in managing risks and opportunities on their project. Some hope for a panacea in computer tools including monte carlo simulations which provide probability distributions and confidence limits on the risks to be managed. However practitioners ultimately realize that there is no analytical “silver bullet” that solves the risk equation. Risk and opportunity management is fundamentally a judgmental process, in which the project manager must evaluate appropriate data using intuition, common sense (or uncommon sense), and team consensus to determine the best approach for the project and for the organization.While some risk and opportunity issues are complex, many are relatively straight‐forward and can be readily solved. It is the number of issues to be faced – and the constant addition and deletion of issues – combined with the technical, cost, and schedule pressures that make risk and opportunity management a challenging process in project management. In order to be consistently successful, the project manager and team must follow a defined process. While monte carlo simulations, decision tree analyses, and other computerized techniques play a vital role, they must be used in the context of the risk and opportunity management process, and then only to the extent necessary to support the decision‐making process.The objective of this paper is to describe the risk and opportunity management process in the context of project management.