bluuebunny/crossref_metadata_2025_split huggingface dataset:
REFINEMENT OF THE REQUIREMENTS DEFINITION (RD) CONCEPT IN SYSTEM DEVELOPMENT: DEVELOPMENT OF THE RD AREAS
Authors: White Michelle M. , Lacy James A. , O'Hair Edgar A. 
Published: November 2014

AbstractTo alleviate problems in performing the definition of requirements, it is necessary to review and understand the practice of requirements definition (RD). Refinement of RD is necessary in order to improve the processes and effectiveness. The purpose of this paper is to present some results of research performed to refine the RD concept in System Development. The objectives were to obtain an organized, coherent and unified representation of RD. Results of this research will enhance communication among the engineering communities, provide guidance in the effective development and management of requirements and provide the avenue for comparison, measurement, and improvement. Development of the RD representation consisted of identifying the areas of RD, primary functions of each area, and interfaces. The first step, identifying the RD areas, is presented in this paper. Documented RD representations were analyzed to determine a preliminary set of RD areas. A total of five areas were determined. Further research was performed to find evidence to reinforce the five areas determined. The procedures for developing the RD areas are presented. The RD areas identified were: Requirements Acquisition, Requirements Analysis & Synthesis, Requirements Correlation, Requirements Communication, and Requirements Management.
TEN LESSONS LEARNED FROM IMPLEMENTING CONCURRENT ENGINEERING AND IPTS
Authors: Popick Paul R. , Sheard Sarah A. 
Published: November 2014

AbstractConcurrent engineering (CE) and integrated product teams (IPTs) offer many advantages in product quality and cycle time reductions. Many companies are beginning to organize projects using IPTs, but the transition to CE and IPTs requires implementation details that are not commonly discussed in the literature. This paper covers ten of the most important lessons we have learned in our implementation of CE and IPTs.
A TEAM METHOD TO CAPTURE CONCURRENT ENGINEERING LESSONS LEARNED
Authors: Popick Paul R. , Smith Craig L. 
Published: November 2014

AbstractThe merits of Concurrent Engineering (CE) and Integrated Product Team (IPT) approaches are widely discussed (Miller 1993) but little attention has been given to methods to identify areas of difficulties and improve implementation. This paper describes a team based approach to capture, analyze, and deploy lessons learned. The lessons learned process is described with a process flow diagram and through charts developed in the lessons learned sessions. Several observations about learning and improving CE and IPTs are given.
Virtual Prototyping: A Powerhouse For Integrated Product & Process Development
Authors: Zittel Randy C. 
Published: November 2014

AbstractThe use of computer prototypes in industry and defense programs has exploded to become a significant tool used in all aspects of the systems engineering and development processes. Carried along with the electronics revolution, virtual prototypes are becoming more capable, accurate, understood and accepted. Now the logistician, decision maker and end‐user are finding valuable integration of engineering simulation with applications and operational procedures.The US military's program is developing a global network that allows for the modeling of integrated computer prototypes where one complete system, and sometimes complete military units of multiple and dissimilar systems, can be computer simulated long before formal design. Never expecting to combine war games with virtual prototyping, the easy variability obtained from computers allows for feedback to doctrine developers as well as the system builders that dramatically improves the requirements.Examples across industry prove virtual prototypes are showing greater returns on investment than ever expected. These savings empower better capabilities, open up new opportunities, and provide a better product sooner.
AN IEEE STD 1220–1994 BASED SYSTEMS ENGINEERING LIFE‐CYCLE REFERENCE MODEL, IMPLEMENTED IN RDD‐100®
Authors: Fossnes Terje 
Published: November 2014

AbstractThis paper addresses the motivation and some of the effort undertaken to develop and describe a Systems Engineering Life‐cycle Reference Model and a Generic Systems Engineering Management Plan (SEMP) for introduction of the Systems Engineering process into an organisation.The work is based on the IEEE Std 1220–1994 “IEEE Trial‐Use Standard for Application and Management of the Systems Engineering Process” and is modelled in the Systems Engineering tool RDD‐100® from Ascent Logic Corporation. A description of the principles of the content and how projects can utilise the model are included. Finally the future objective of the initiative is addressed.
SYSTEMS ENGINEERING: Myth or Reality
Authors: Kasser Joe 
Published: November 2014

AbstractEach year at the National Council of Systems Engineering (NCOSE) symposium lots of dedicated people spend a lot of energy assessing, measuring and educating people about an incomplete body of knowledge (systems engineering). The incompleteness is due to the lack of a definition of what that body of knowledge is supposed to cover. Now every systems engineer knows that it is important to capture all the requirements as early as possible in the program, so why have the systems engineers not defined systems engineering (SE)? This situation led me to hypothesize that there was no such thing as systems engineering (after all, if the experts in NCOSE can't come up with one, then there isn't one).This paper analyzes the functions performed by systems engineers, shows there seems to be no unique body of knowledge to SE, which explains why the NCOSE experts have failed to define SE. The paper then looks outside the SE box for the reasons for the failure, and provides a surprising conclusion.
Project Management, Systems Engineering and the Amazing DNA Double Helix
Authors: Smith Byron , van Gaasbeek Jim 
Published: November 2014

AbstractWhat possible connection is there between Project Management, Systems Engineering and DNA? The answer is the double helix and the amino acid pairs. It is the contention of the authors that, just like the DNA double helix, Project Management and Systems Engineering could also be thought to have a double helix. A unique amino acid like Thiamin appears at one location on a DNA strand, it is opposed on the opposite strand by Adenine. This same kind of synergy can be found in the relationship between Project Management and Systems Engineering. In our terms, however, we don't deal with amino acids but tasks or responsibilities. When an integrated master plan is prepared by Project Management, for example, Systems Engineering is inevitably called to provide significant contribution to that plan including development of a SEMP. During the course of this paper this and other corollaries will be discussed. The discussion will also focus on how a strong bond between the two disciplines can have a significant impact on a project's success. Furthermore, the authors will focus on the fact that this unique Project Management/Systems Engineering helix forms the nexus at the core of a process that can be replicated to other projects much in the manner that the DNA can replicate itself.
Decision/Risk Analysis Software: Survey for Trade Studies
Authors: Buede Dennis M. 
Published: November 2014

AbstractThis paper provides an overview of the PC and Mac‐based software market for decision/risk analyses. Decision/risk analysis is a powerful methodology for conducting systems engineering trade studies and selecting system designs because the methodology explicitly deals with conflicting performance and cost objectives, uncertainty and risk preference. Information on 28 software packages is provided. Before describing these packages several applications of decision/risk analysis in systems engineering design are presented. In addition, technical performance, usability, compatibility and output documentation issues are discussed. Finally, we forecast the future trends for this software.
THE VALUE OF TWELVE SYSTEMS ENGINEERING ROLES
Authors: Sheard Sarah A. 
Published: November 2014

AbstractA description of the value of systems engineering, long sought by practitioners in order to justify funding for systems engineering, must be explained in the context of clear systems engineering roles. A companion paper defines twelve systems engineering roles in detail. Value added is not a simple concept. In manufacturing terms, value added work changes the product that is delivered to the customer. This paper suggests a more robust definition of value added that applies to the systems engineering environment, including managing work, defining the problem, and reducing risk. Then, this paper explores the value of each of the twelve systems engineering roles in terms of this definition of value added and other considerations.
A CONCURRENT PROCESS FOR DEVELOPMENT AND VALIDATION OF OPERATIONAL REQUIREMENTS
Authors: Anderegg Alfred H. 
Published: November 2014

AbstractThe FAA's Oceanic and Offshore Integrated Product Team has established a process for development and validation of system level requirements through the use of Joint Application Design. This process is initiated with operational requirements set in the context of a concept of operations. The concept and system behavior are wholly contained within a requirements model. The goal is to collect user inputs that compliment the operational requirements with a level of detail necessary to complete a system level specification in the model. The model will then be used to validate the requirements against the concept of operations and target benefits for the system build. This paper describes the requirements development and validation process and preliminary results of the application of the process.
Software Design of System Requirements Utilizing Set Theory Model for Anomaly Handling
Authors: Sanchez James A. 
Published: November 2014

AbstractIn 1995 Ronald Carson developed a mathematical model for system requirements analysis (SRA) utilizing set theory to explicitly treat unwanted or unexpected conditions that may be experienced by the system being analyzed. He showed that the SRA model can be used to derive completeness criteria. He claimed that the highest utility of the model would be found in the area of software requirements because of the focus on system states.A simple example using a Power Distribution Unit (PDU) was made in order to clarify the salient points. This simple example had only three states and six transitions, which were identified as nine antecedents (conditions which precede). Eight requirements were generated for the PDU.In this paper, the requirements for this simple example, along with its principles, are used to construct a simple software implementation in graphical fashion in order to test the effectiveness of the methodology for software.In conclusion, the SRA model utilizing elementary set theory needs some refinement for software applications. Though the method is rigorous, problems surface because of 1) ambiguities in language, 2) unforeseen conditions, 3) undefined initial conditions, and 4) probability density function of primitives.In addition, the start condition of the timers are undefined, as are the initial states of primitives, e.g. valid input, degraded input and inhibit output and degraded output.
IMPLEMENTATION OF DYNAMIC AIRCRAFT MODELS USING MATRIXx
Authors: Redling Thomas J. 
Published: November 2014

AbstractToday, the design of modern control systems is greatly facilitated by the use of computer based design and analysis tools. More specifically, the design of aircraft flight controls has benefited immensely from these tools. The ability to simulate control laws in a virtual environment allows for the design of complex algorithms whose functionality and performance may be evaluated during the design phase of a project rather than during the flight test phase. Besides improving the control engineer's ability to create a superior design, these tools reduce cost by uncovering design flaws and performance deficiencies before the flight test program commences.Before one can begin the analysis of a set of control laws, an accurate representation of the plant being controlled must be derived. In the case where one wishes to evaluate an autopilot, the plant is the aircraft being controlled. Therefore, the dynamics of the airframe must be modeled. This paper presents a framework for the derivation of a Laplace domain representation of an airframe based on raw aerodynamic data from both wind tunnel testing and actual flight tests. This representation can then be implemented using a dynamic systems modeling tool such as MATRIXx. This process has been carried out successfully on aircraft such as the C‐141B and A‐4D at AlliedSignal Aerospace Guidance and Control Systems by the author. Once this model has been generated, it is used to design and analyze the control laws targeted for that airframe.
USING PROBABILISTIC ANALYSIS TOOLS TO SIMULATE ALTERNATIVE PROJECT STRATEGIES
Authors: Keizur Alan E. , Miller Ian 
Published: November 2014

AbstractSystems Engineers and project managers routinely analyze and compare sets of alternatives in an effort to identify the best design or strategy to achieve the project's stated objectives. Software tools are available for performing such tasks, but the issue of uncertainty is often given little or no attention.This paper introduces the concept of analyzing and comparing project alternatives using probabilistic methods and provides an illustrative example of the use of software tools to simulate such analyses.
ASSESSING THE QUALITY OF LEGACY APPLICATIONS WITH PERSISTENT DATA: ASSESSING THE BASELINE FOR SYSTEM MIGRATION
Authors: Campbell Pamela D. 
Published: November 2014

AbstractConsistent comparison of applications which store data, written in different languages and using varying types of Database Management Systems, requires an assessment that measures the system(s) in accordance with a well defined, repeatable set of criteria.This paper describes a tool and methodology (MARS) for identifying the lifecycle risks related to data within existing applications, and describes the taxonomy of data quality assumed during the development of the assessment methodology.An example question is shown, with the rationale and method for applying the question. The relationship of the data quality taxonomy is also described in terms of database focus areas, such as data integrity and data dictionary, that are of interest to those working operationally with databases.
SYSTEM INTEGRATION LABORATORY ‐ A NEW APPROACH TO SOFTWARE/ELECTRONICS SYSTEM INTEGRATION
Authors: Huang Paul , Kar Pradip , Kennedy Alan , Kato Hiroko 
Published: November 2014

ABSTRACTThis paper describes the system definition and integration approach adopted for the Bradley Fighting Vehicle (BFV) M2A3 Engineering and Manufacturing Development (EMD) program at United Defense LP. The BFV A3 Upgrade program incorporates lessons learned in the Desert Storm Operation. Upgrades are primarily in the area of fire control, electronics and software.Modern electronics and software systems are relatively complex. Subsystems have to be integrated so that they perform cohesively to implement sophisticated system functions with minimal supervision from human operators. This cohesive implementation, or system integration, requires special discipline, knowhow, facility, and organization. This paper describes a systems engineering approach that allows an understanding of the system early in the program, identifies problem areas and generates candidate solutions before commencement of system design. It also describes the advantages of this approach.The approach described was used on the BFV A3 program. A System Integration Laboratory (SIL) was constructed and a rapid prototyping methodology was adopted to generate a simulation, emulation, and stimulation (SES) early in the program to allow for a better understanding of the overall system. The SIL also created an incremental integration environment that allowed the system to be integrated using the philosophy of “build‐a‐little, test‐a‐little, and integrate‐a‐little” to simplify the integration tasks and reduce program risk.
FOUNDATIONS OF SYSTEMS ENGINEERING ETHICS
Authors: Alessi R. Sam , Gokey John R. , Mayhew Michael E. , Walden David D. 
Published: November 2014

AbstractINCOSE has stated the need to develop standards for the integrity of Systems Engineering. Part of what defines this integrity will involve ethics. This paper provides background information to support a search for ethics peculiar to Systems Engineering. Presented are a rationale for considering ethics, the role and responsibility of professional societies to state ethical standards, a historical and theoretical perspective and requirements for development of a Systems Engineering ethics code. An ethics discussion within INCOSE will likely produce tools, such as a code, which distinguish Systems Engineering's role and responsibilities for ethical design and management of complex systems that minimize unintended harmful behavior.
INTERNATIONAL SPACE STATION PERFORMANCE METRICS
Authors: Rice Alvin F. 
Published: November 2014

ABSTRACTBoeing, as the Prime Contractor for the International Space Station (ISS), has a system of Metrics to manage the Prime Contractor portion of the program. The system of metrics and processes provide programmatic and technical type parameters to measure the status and progress of the Prime Contract and provide early warning indicators of performance problems.The metrics are generated and used as a management tool by the Prime Contractor and Product Group Integrated Product Teams (IPTs) and Analysis Integration Teams (AITs) for all phases of the program. The system of metrics are applicable to program hardware, software, firmware, support equipment and supporting services. The Space Station IPTs and AITs are made up of NASA and Prime Contractor participants. The metrics are an integrated part of the Management Control System and are used for reporting at weekly, monthly, quarterly and special event reviews. These metrics provide a means to assess and display the health of the program at various IPT and AIT levels.
A COST OF OWNERSHIP METRIC AND ITS USE ‐ A PLACE TO START
Authors: Stark George E. 
Published: November 2014

AbstractAt a time when Government budget cuts are in vogue and increased military readiness is the goal, knowledge of system cost of ownership is essential for decision‐makers and system engineers. As with many aspects of our economy, costs associated with operating and maintaining our C4I systems continue to climb. Understanding and correctly using a cost of ownership metric can direct attention to problem areas, help prioritize changes to the system, and track the impact of system improvements over time. This paper introduces the reader to the rationale and intended use for one approach to measuring the cost of ownership for a space surveillance radar system. The intent is to provide a starting point for learning more about the subject. By using such a metric, it will become possible to achieve the goal of increasing mission success for less cost.
PROJECT MANAGEMENT AND SYSTEMS ENGINEERING IN AN IPD ENVIRONMENT
Authors: Roe Charles L. 
Published: November 2014

AbstractIntegrated Product Development is a creative new way to produce quality products in a predetermined time within a set cost. The focus is on multifunctional teams working together and total integration of all products and processes (people, tools, and techniques). Within the team structure several potential pitfalls exist that can threaten the process. This paper suggests that two of the critical pitfalls involve (1) the project manager effectively executing new responsibilities that fall to him or her in the process and (2) the organization overcoming the difficulties of applying the systems engineering methodology to the products being developed by these concurrent teams.
EXPERIENCE WITH THE SYSTEMS SECURITY ENGINEERING CAPABILITY MATURITY MODEL
Authors: Hefner Rick , Monroe Warren , Hsiao David 
Published: November 2014

ABSTRACTThe Systems Security Engineering Capability Maturity Model (SSE‐CMM) is a tool for appraising and improving an organization's security engineering practices, and for augmenting existing assurance methods. The SSE‐CMM was developed through a government‐industry collaboration involving the nation's leading providers of security systems, products, and services. It does not specify how a particular process should be performed, but identifies practices generally accepted by industry. The SSE‐CMM can also be used to examine the practice of security engineering within the context of systems engineering.This paper describes the principles upon which the SSE‐CMM is based, the structure of the model, and its use in appraisals. Issues in model development, application, and adoption are presented.
Quantitative QFD for System Engineering
Authors: Maier Mark W. 
Published: November 2014

AbstractQuantitative QFD (Q2FD) is an extension of conventional Quality Function Deployment (QFD). Q2FD incorporates quantitative requirements decomposition models into the QFD framework. It also rearranges conventional QFD matrices to facilitate quantitative capture and both forward and backward chaining of performance values. The rearranged matrices also allows full representation of QFD matrices with standard spreadsheets instead of only with special purpose software. Q2FD can serve as a bridge between quality, system, and disciplinary engineering personnel and act as an organizing formalism for all performance aspects of system design.
Measuring Systems Engineering Process Maturity
Authors: Pierson Harold 
Published: November 2014

AbstractMany Systems Engineering organizations are beginning to examine their engineering processes as a means of improving their competitiveness. There are now process maturity models which serve as process frameworks and provide a yardstick for measuring Systems Engineering process maturity. These models define what activities must be performed and a scale for judging how well they are performed. Appraisal methods are available for evaluating an organization's process maturity. This paper discusses the importance of measuring Systems Engineering process maturity and gives an overview of two Systems Engineering process maturity models.
PROVIDING A FRAMEWORK FOR EFFECTIVE SOFTWARE QUALITY MEASUREMENT: MAKING A SCIENCE OF RISK ASSESSMENT
Authors: Martin Robert A. , Shafer Lawrence H. 
Published: November 2014

AbstractSoftware quality assessment is a field that is coming into greater focus as the global drive for systemic quality assurance continues to gather momentum. Many forces are at play, from the pressures of consolidations, mergers, and downsizing, to the emergence of new technologies which are sparking renewed looks at re‐engineering in business and government, particularly the advances in user interface capabilities endemic to the PC and distributed processing economic explosions. These developments and forces have led to our creation of a quality assessment methodology which harnesses the results of program analysis techniques to generate a timely analysis that can be productively used to focus management attention on the fundamental quality issues within their software systems. This approach has been used successfully for more than 75 system evaluations as part of source selection or project management studies.