bluuebunny/crossref_metadata_2025_split huggingface dataset:
REQUIREMENTS MANAGEMENT COST/BENEFIT SELECTION CRITERIA
Authors: Honour Eric C. 
Published: November 2014

AbstractThis paper explores thç practical costs and benefits of managing individual requirements statements by different methods or tools. A relatively simple evaluation is offered using fill‐in‐the‐blank entries in a form. The evaluation considers improvement costs, process costs, and requirements change management costs. The evaluation considers benefits due to more complete requirements management, better change management, and reduction in excess technical features. The evaluation result is a practical algebraic benefit/cost ratio, which is a criterion to determine the relative worth of alternative methods. Using the author's heuristics, the paper applies the evaluation criteria to several typical decisions faced by companies today. Results confirm that program‐wide use of modern databasing tools makes financial sense for large programs, while small programs can effectively use well‐managed requirements lists.
A Brave New World: Melding Systems and Software Engineering
Authors: Downward Bernadette Gagnon 
Published: November 2014

AbstractThe introduction of Mil‐Std‐SDD (to be named Mil‐Std‐498), “Software Development and Documentation”, in conjunction with Mil‐Std‐499B, “Systems Engineering”, will redefine the development, reuse, and evaluation of software throughout a project's life cycle. This definition is being driven in an attempt to quantify the software development process. The focus of this paper is to explore how these changes will affect the systems engineering process. The process of systems engineering as defined by Mil‐Std‐499B is compared to Mil‐Std‐SDD. An interpretation is presented of the boundaries of systems and software engineering activities proposed within the framework of these new standards.
Creating an Effective Business Environment for Developing Computer‐Assisted Systems Engineering Environments
Authors: Epperson Roy E. 
Published: November 2014

AbstractThis paper discusses some of the factors that affect the ability to create a computer‐assisted system engineering environment (CASEE). The system engineering community needs to consider and take action on them as it adopts automated tools and tool integration. The assumption is made that the reader has or desires to add computer assisted tools to their system engineering organization.These observations are based on the author's experience working with customers in several industries to define project support environment requirements for system and software engineering.
THE THEORY OF TESTING APPLIED TO THE DEVELOPMENT OF A SYSTEM ENGINEERING METRIC
Authors: Ashburner Edmund J. 
Published: November 2014

AbstractAny discipline which wishes to optimize its performance must, at some point, develop a testing mechanism to compare the results of various attempts at improvement to determine which were successful and which were not. The knowledge of testing and measurement methods developed in other disciplines such as Education and Psychology can be applied to the System Engineering field to help us develop such an evaluation mechanism. The results of an initial investigation suggest that three factors should be used as primary goals of any such “Metric”; they are Reliability, Validity, and Usability. In addition, the limits and potential application of such a Metric can be derived. Without the structure of this (or some similar) approach, the quest for a useful and accurate measurement technique for the System Engineering process will prove to be as elusive as that for the “Holy Grail”.
A LEADERSHIP ROLE FOR NCOSE
Authors: Aslaksen Erik W. 
Published: November 2014

AbstractThis paper is concerned with the current state of Systems Engineering as a distinct discipline within engineering. It is argued that a main impediment to the acceptance and usefulness of Systems Engineering is the lack of precise and agreed operational definitions of the main concepts, such as system and state. This would be an area where NCOSE could take a leadership role, and a set of possible definitions is proposed.
THE MORPHOLOGICAL APPROACH: ITS ROLE IN SYSTEMS ENGINEERING AND ITS APPLICATION TO SOLAR ENERGY CONVERSION
Authors: Jackson Scott , Drubka Robert E. 
Published: November 2014

AbstractThis paper discusses the morphological approach, a methodology first proposed by (Zwicky 1969) and shows how this approach would enhance the systems engineering process. The morphological approach determines the requirements and design solutions of any system by considering the totality of all solutions. Examples of solar energy conversion studies conducted at McDonnell Douglas Aerospace (MDA) are shown to illustrate the approach.The morphological approach is a key ingredient in first‐order systems engineering (FOSE), the combination of which allows the analyst to examine all possible options at minimum cost before the design phase is initiated. Hence, it is recommended that the morphological approach, along with FOSE, be incorporated as integral parts of the SE process.
System Engineering Manual Update
Authors: McGee Allen , Khouri Jennifer 
Published: November 2014

AbstractLockheed Missiles & Space Company (LMSC) has used the system engineering process throughout the history of the company. However, the process was not formally released as a system engineering manual (SEM) until 1985. Space Systems Division (SSD) of LMSC is currently updating the SEM to reflect proposed changes to the associated military standard (MIL‐STD‐499), projected changes in our business base (a shift toward commercial ventures), and updates in technologies and methodologies used in system engineering (including new computer‐based analysis tools and Continuous Quality Improvement {CQI} methods). Many changes to the manual are due to a sweeping reorganization of the material such that the new manual has sections that are organized around system engineering functions. The functions used come from a list derived by the National Council of System Engineers (NCOSE) Process Working Group Committee. The SEM defines how SSD system engineers do business, is the basis for proposals, and serves as the core of our system engineering training program.
Design Reviews: Highly Lucrative Targets for Process Improvement
Authors: Wyman James P 
Published: November 2014

AbstractThis paper is a case study taken from the F/A‐18E/F Initial & Preliminary Design Reviews conducted during Sept 92 and Jun 93 respectively. These highly successful events serve as models from which the design review process can be documented, analyzed and improvement initiatives identified. The end objective is an improved process, road map and game plan that will lead to future successful Design Reviews. Key to the development of this road map, and the implementation of a game plan that would guarantee Design Review success is the clear understanding of:
Who is the real customer for the Design Review.
What are the customer expectations relative to the Design Review product.
What are the customer's quality requirements.
What processes will be employed to develop and deliver the product that will satisfy those requirements.
Post Design Review Presenter survey results and Design Review Process Improvement Team (DRPIT) findings and recommendations serve as the basis for process and product quality improvement initiatives with “real world” applicability to a wide range of acquisition programs. These initiatives will be implemented in preparation for future Design Reviews.
A SYSTEMS ENGINEERING ANALYSIS FOR RE‐ENGINEERING AN ORGANIZATION
Authors: Granata Raymond L. , Oran William A. , Beyer David S. , Mayer D. Stephen , Mackey William F. , Yost Robert F. , Van Nostrand George C. , Karlin Jay J. , Bagg Thomas C. 
Published: November 2014

AbstractA multicontractor/government systems engineering team analyzed a government organization in order to develop recommendations to re‐engineer its activities and improve its processes in terms of both efficiency and quality. The organization was NASA/Goddard's Mission Operations and Data Systems Directorate (MO&DSD), which 24 hours/day, 7 days/week supplies services including data capture, data processing, operations, and communications between orbiting spacecraft and ground based investigating teams. The service operations and the underlying organizational processes were analyzed using a systems engineering approach assisted by tools consisting of a Total Quality (process) Model (TQM) instituted by AlliedSignal Corp. and the Viable Systems Model (VSM) which has its genesis in management cybernetics. Aspects of both the TQM and VSM are discussed and compared along with their application in analyzing the processes of MO&DSD. Both analyses resulted in numerous recommendations to improve MO&DSD's activities including administrative, personnel, and operational procedures. The similarities and differences in the recommendations are compared along with a discussion of the use of these two analytical techniques.
Systems Engineering and Object Technology
Authors: Oliver David W. 
Published: November 2014

AbstractThis paper extends Systems Engineering methods to include object technology, which has been developing in modern software engineering, (Rumbaugh et. al. 1991). It applies the principles of Model Based Systems Engineering, MBSE, (Oliver 1993a), (Oliver 1993b) to the systems engineering process itself. This results in a layered process description which is tailorable and supports aerospace or commercial methodologies.Multiple phases of engineering ‐ concept phase, requirements analysis phase, and systems architecture and design phase ‐ are supported with a single core set of engineering steps. The additions of semantics and notations from object technology provides a capability to describe the choices of components and the mapping of behavior to components that lead to alternative architectures. Strong emphasis is placed on the systems engineering traditions of trade‐off analysis and sequential build and test which have been weak in software engineering methodologies.The joining of systems engineering with object technology provides a seamless engineering path for projects which will implement software in an object‐oriented fashion. Integration with existing methodologies is straight forward because existing methodologies can be defined by selecting among the core MBSE steps.
ROLE OF REDUCTIONISM AND EXPANSIONISM IN SYSTEM DESIGN AND EVALUATION
Authors: Clymer John R. 
Published: November 2014

ABSTRACTReductionism is based on the assumption that any complex system can be decomposed into a set of indivisible components that operate independently of each other. Interactions among components are based on cause and effect relationships described by a mechanistic model Expansionism is based on the assumption that a component is understood as it relates to a larger whole. It is possible, that in a mechanistic sense, a component may seem to operate properly when evaluated based on cause and effect; however, from an expansionist point of view the component may not adequately contribute to the goals and objectives of the system as a whole. In order to detect such problems early and minimize development time and cost, the expansionist view is applied during conceptual design To facilitate expansionism during conceptual design, an explicit operational model is applied that can assist understanding global context sensitive interactions that can cause problems later. To evaluate the architecture, the operational model is expanded, during system design, to include structural details.
SCRABBLE® ‐ A COLLABORATION TRAINING TOOL
Authors: Lentz Virginia A. , Stanford Jean C. 
Published: November 2014

AbstractSCRABBLE®, (traditionally played as a competitive game) can be used to demonstrate the benefits of collaboration and enterprise‐wide visibility in support of alternative product development strategies. Observing individual and team play using a SCRABBLE exercise has strong corollaries to how we manage the system and product development businesses.The authors have modified the SCRABBLE rules of play to create our exercise used with hundreds of students. In the process, we validated a number of management and systems engineering rules of thumb. The exercise rules and observations in the areas of organization, team norms, productivity and status tracking are discussed. We describe how we build on these lessons in our systems engineering courses.
AUTOMATING SYSTEMS ENGINEERING
Authors: Kuhn Dorothy A. 
Published: November 2014

AbstractThe need for effective automation in systems engineering has been a subtext of nearly every book on this fascinating subject since the early 1960s, yet systems engineering is still the least automated of the engineering disciplines. We are now at the happy historical position of having met the three necessary conditions for developing such a tool. We can describe the systems engineering process, the level of system complexity continues to rise, and the level of computing power is now sufficient and sufficiently wide spread.This paper, a distillation of the author's masters thesis, will describe these three areas and will describe the general nature of such an automation tool.
The Next Big Step for Systems Engineering Tools: Integrating Automated Requirements Tools With Modeling and Simulation Tools
Authors: Schoening William W. , Daum Arthur W. 
Published: November 2014

AbstractComputer tools like J‐MASS (Joint Modeling and Simulation System) have become an everyday reality for simulating the real‐time operation and testing of new hardware and software products. Systems Engineers, designers, and testers now need to link the product requirements housed in requirements management tools to the corresponding representations in the simulation software and data. This paper describes the systems engineering context for this new modeling and simulation environment, summarizes key features of J‐MASS, a Government‐developed and owned simulation tool, and discusses some of the interfaces between J‐MASS and any requirements management tools that might be linked to J‐MASS.
On the Dimensions of Interfaces Between Database Applications
Authors: Stafford Randy , Axe Herb 
Published: November 2014

AbstractThis paper presents a model to facilitate the description of interfaces between software applications that maintain databases of information. An interface is a capability for one application's database, or portions thereof, to be automatically and electronically transmitted en masse into another application's database. Criteria are first given for assessing the sensibility of a proposed interface between two database applications (in the context of system development projects), considering issues such as motivation, technical feasibility, and cost‐beneficiality. Next, a three‐dimensional model is proposed whose axes serve as a conceptual framework for describing interfaces between database applications, covering cases from the simplest, one‐time data conversion utilities, to the most sophisticated, integration‐type approaches. The design of software servicing such interfaces is discussed. Considerations are given for the effective use of such interfaces on system development projects, and a few example interfaces are reviewed.
System Modeling Through Parametric Spreadsheet Analyses
Authors: Ghassemi K. , Conway W. , Hines J. 
Published: November 2014

AbstractOperational and cost effectiveness analyses are essential elements in the decision making process for both government and civil programs. Programs, now more than ever, require integrated system level models to perform early assessments of system tradeoffs between operational capability, performance, cost and schedule. At Rockwell Space Systems Division, an approach has been developed to achieve easy integration of various quantitative products of integrated product teams into a “system model”. This approach, at the present, is based on use of spreadsheets. We have taken advantage of the availability of PCs and Macs and familiarity of most engineers with spreadsheet operations. A demonstration of this approach is presented in the context of a satellite development program.
Digraph Analysis As a Valuable Part of the Systems Engineering Process in Design Optimization
Authors: Shih Eddie , Almeleh Nancy , Hines Jim 
Published: November 2014

AbstractDigraph analysis, an approach to Boolean modeling and analysis of large systems, is a valuable technique when performed as part of systems engineering effort‐Digraph analysis provides modeling of physical and informational flow to evaluate and document decisions regarding design capabilities. It supports effectiveness analyses, design analyses, and trades in examining system interactions, fault tolerance, reliability, redundancies, and risks. A demonstration of how digraph analysis was used when performing systems engineering in an integrated product team environment on the Mars Environmental Survey (MESUR) program is given.
SIMULATION IN SLATE: Construction and Application
Authors: Chang C.Y. , Strasburg Don 
Published: November 2014

AbstractThis paper reports on the “Execution of Specifications” or “Simulation” at the system‐level as it was internally implemented as a prototype at Texas Instruments under the developmental name ‐System‐Level Automation Tool for Engineers (SLATE). The paper reviews original requirements, implementation specifics, actual application on a specific program, and lessons learned from the development and application of the tool.
The Role of Architecture and Evolutionary Development in Accommodating Change
Authors: Isaac David , McConaughy Gail 
Published: November 2014

AbstractTraditional systems engineering processes emphasize controlling changes, and are effective at ensuring the transformation of system requirements into a system implementation that successfully fulfills those requirements. For large information systems, however, the rate of change in missions and technology is now such that a system that successfully meets the original written requirements may be obsolete on delivery. The days of static turnkey systems are gone: systems must continually evolve to adapt to changes in their environment. To support evolutionary systems, certain changes are required in the systems engineering process. Specifically, a shift in emphasis from limiting change to accommodating change is called for. Accordingly, a shift in emphasis from system requirements to the system architecture is needed. This paper discusses the need for evolvability, the role of architecture in enhancing evolvability, and the changes to the systems engineering process needed to support evolutionary systems.
OPERATIONAL CONCEPT and SYSTEM ARCHITECTURE for IVSAWS
Authors: Mayhew Gregory L. 
Published: November 2014

AbstractThe In‐Vehicle Safety Advisory and Warning System is a Federal Highway Administration program to develop a nationwide vehicular information system that provides drivers with advance, supplemental notification of dangerous road conditions using electronic warning zones with precise areas of coverage. Goal is to ameliorate the severity of scenarios which are particularly hazardous and have remained hazardous despite traditional crash reduction techniques such as mechanical signing. This system provides additional safety by enhancing the real time interaction between the general driving public and professional agencies. In order to solicit a broad based evaluation of the preliminary IVSAWS concept, user desired functionality was investigated. Two system design methodologies, Quality Function Deployment and Structured Requirements Specifications, produced significant refinements in the IVSAWS concept.
THE SYSTEMS ARCHITECT: SPECIALTY, ROLE AND RESPONSIBILITY
Authors: Rechtin Eberhardt 
Published: November 2014

AbstractArchitects, from the early Egyptians to modern systems architects, are specialists in the creation and building of complex structures, qualitatively different from those that have gone before. The architect, working with and acting as the agent of the client, creates and manages the design to maintain system integrity and to help achieve client satisfaction with the built system. This paper updates the ideas and conclusions of the teaching and study of systems architecting at the University of Southern California over the last six years.
EVOLUTIONARY DEVELOPMENT OF SOFTWARE‐INTENSIVE PRODUCT LINES
Authors: Hofkin Robert 
Published: November 2014

AbstractThe systems engineering process for software‐intensive products is the foundation for the developing organization's business. The enterprise's success is closely related to the capability and efficiency with which this process is performed and the quality and appropriateness of the products it produces. In the current competitive marketplace, developers of software‐intensive systems must find ways both to serve a broader range of customers and to operate more efficiently than in the past.Systems developers need to consider their organization's present development capabilities and its legacy of products as part of their corporate assets. This paper proposes a shift from the “single‐project‐at‐a‐time” view that is typical of contract‐oriented developers to a multiproject or “product‐line‐oriented” view. This change highlights the strategic importance of systems development and emphasizes the need for corporate capabilities that support product definition and development.
ANATOMY OF A TAILORED SYSTEM
Authors: Stern George 
Published: November 2014

ABSTRACTThis paper is a practical application of systems engineering theory. It is the result of a request be a customer to develop a routine by which the systems engineering process could be tailored. The routine should be able to respond to the exigencies of the current government environment.The Current environment is strongly influenced by small budgets and an emphasis on maximizing the use of existing resources. The methodology herein described will be effective in this environment.The key feature of this tailored methodology is that it uses the positive aspects of the Waterfall and Incremental methods to ensure positive control and insight by the customer fused with logical requirements organization to fulfill the customer's needs.
THE STATEMENT OF WORK: IT IS NOT NEEDED
Authors: Lake Jerome (Jerry) G. 
Published: November 2014

ABSTRACTCaution! Reading this exposition may alter your mind set on the need for a statement of work to direct development of a system, large or small, by a performing activity.The recommendation is made to eliminate statements of work, as we now know them, for acquisition efforts involving system definition (Demonstration and Validation phase within the Department of Defense acquisition cycle) and subsystem development (Engineering and Manufacturing Development phase). This paper points out that the statement of work is a redundant document based on the documents that are currently available in a procurement solicitation, or will be available with publication of Mil‐Std‐499B and IEEE P1220 standards on systems engineering.This paper is addressed to those interested in acquisition reform within the Department of Defense. It is also addressed to program managers in commercial enterprises having to communicate work tasks to a subcontractor.