bluuebunny/crossref_metadata_2025_split huggingface dataset:
RISK MANAGEMENT BY COST IMPACT
Authors: Honour Eric C. 
Published: November 2014

AbstractThis paper documents an effective, formal risk management process that is based on cost impact. The process is used in current programs. Key to the process is the objective ranking of risks based on more detailed subjective identification of cost impact. Higher‐ranking risks have mitigation action plans, receive emphasis at monthly reviews, and are tracked in a planned manner. Lower‐ranking risks stay on the overall list for later evaluation without expending inordinate time and effort. The paper provides the process, methods to identify risks, methods to assess the risks, and methods to review and track the risks.
Capturing and Taming Derived Requirements
Authors: Scheurer Robert P. , Volz Michael E. 
Published: November 2014

AbstractSystems engineers are concerned with identifying, allocating, and managing their customer requirements to appropriate design teams. However, as anyone involved with the design process can testify, contractual requirements are only one piece of the requirements management puzzle. Designs as well as requirements evolve and are iterated to very low levels of detail, with each succeeding level offering more complexity and additional requirements. Unless these added requirements are well‐understood and documented, costly mistakes or omissions can be introduced into the completed product. As the reader will see, system requirement definitions can and do go far beyond the initial mandates imposed by the customer.
A METHOD FOR BASELINING AND IMPROVING AN ORGANIZATIONS SYSTEMS ENGINEERING CAPABILITY
Authors: Stone Arthur G. 
Published: November 2014

AbstractA fundamental premises of this paper is that the system engineering capability of an organization can only be as good as the collective skills of the individuals that make up the organization. This paper describes two distinct career paths for systems engineers, system integration and system analyst. Thirty‐five skill areas are identified for the system integration path, and twenty for the system analyst path. In addition, basic system engineering skills required for both career paths are described. Four levels of expertise are described for the two different career paths. Skill level ratings are determined for individuals in each skill area that applies. Collectively, these individual ratings are used as an indicator of the system engineering capability of an organization. Individual career development is based on achieving higher skill levels in the skill areas. The system engineering capability of an organization is improved as individuals achieve higher skill levels.
The PMTE Paradigm: Exploring the Relationship Between Systems Engineering Process and Tools
Authors: Martin James N. 
Published: November 2014

AbstractThis paper explores the relationship between process and tools for systems engineering. There is much interest now in process maturity, yet there are many cases of processes being developed and deployed with little effect on the bottom line. In fact, there are times when the overall health of the engineering organization is not improved with the use of standardized processes and tools.It is important to have a proper balance among process, methods, tools, and environment (PMTE) when performing systems engineering (SE) tasks. An improper balance leads to increased costs and lower quality, in addition to frustration for engineers and for management. The particular PMTE elements appropriate for a project should be defined and documented in an SE Development Environment (SEDE) Plan which can cover the gaps in a project SE Management Plan (SEMP). This paper proposes a paradigm for understanding the PMTE elements for systems engineering.
DEVELOPMENT OF A SYSTEMS PERSPECTIVE FOR LONG DURATION SPACE FLIGHT MISSIONS USING A CREW SYSTEMS INTERACTIONS MODEL (CSIM)
Authors: Upshaw Kathy 
Published: November 2014

AbstractThe confinement and isolation of the crew of a long duration manned space flight mission such as the planned International Space Station or proposed expeditions to the Moon or Mars cause the social environment and the crew capabilities and limitations to be extremely influential to mission success. The systems engineering process must be executed within the constraints imposed by the system environment (including the social, technical, economic, and political (STEP) factors) as well as those constraints imposed by the personnel who must design, operate, and maintain the system. This process could be facilitated if the diverse sociological and psychological models were integrated to define a set of requirements for spacecraft design and criteria for crew selection and training. A Crew/System Interactions Model (CSIM) is presented as a tool for synthesizing and linking psychological and sociological theories. The CSIM would serve as a reference for improving and refining the causal relationships describing effects of crew actions and behaviors on the system, allowing the development of design criteria that are better tailored to the mission needs and operational requirements.
THE BASICS OF BENCHMARKING
Authors: Fisher Gerard H. , Fisher Jack 
Published: November 2014

AbstractThe current economic environment is causing research, development and capital investments budgets to be reduced. Nevertheless, customers are demanding more value in the form of reduced cost, faster cycle time and higher quality products and processes. For a company to remain competitive and grow, it must find innovative means to improve performance. Benchmarking can provide the opportunity for improvements to those organizations that know how to use the information.Although benchmarking has been in use for 15 years, there has not been any application to the systems engineering process that has been reported in the literature. The purpose of this paper is to consider such an application and discuss how to it can be achieved. This paper provides: 1) a benchmarking tutorial, 2) some advantages and disadvantages of benchmarking, 3) some thoughts on the application of benchmarking to systems engineering, and 4) the role of NCOSE in the benchmarking process. It may be difficult to apply benchmarking to systems engineering, but the rewards can be significant. Systems engineering, a difficult, widely varying and sometimes closely guarded process, can only benefit from the exchange of data between organizations involved in the development of complex systems.
AN INTEGRATED APPROACH TO SYSTEMS ENGINEERING TRAINING
Authors: Hyer Scott A. 
Published: November 2014

AbstractThe issue of how systems engineers can be trained and prepared for positions in their fields is one which has received much attention. Some advocate university level classwork toward a degree in systems engineering, while others maintain that experience in real world problems is the only way a systems engineer can be developed. This paper questions some of the assumptions made regarding this issue and advocates an approach which integrates the best features of both classroom education and work experience. The approach is summarized by three main ideas: (1) The practice of systems engineering requires a maturity which is more effectively developed upon a specific technical base; (2) Training is dependent on the situation in which it is to be applied; and (3) Training is a continuous growth process which should be planned, monitored, and adjusted when necessary.
THE PROBLEM WITH SYSTEMS ENGINEERS…
Authors: Downward Bernadette Gagnon 
Published: November 2014

AbstractThis paper uses a lighthearted approach to address the communications barrier that sometimes exists between systems and software engineers. Anecdotes were obtained through a series of interviews and questionnaires. Typical but fictional scenarios examine the attitudes held by both systems and software engineers. Practical solutions are suggested to overcome the communications barrier so they can become better team players.
Meta‐Modeling for Project Engineering
Authors: Scruggs John V. 
Published: November 2014

AbstractSystems Engineering and Project Management are converging. Systems Engineers are assuming greater responsibilities for the complete project and Project Managers are requiring greater insight into the details of the project product and process. A technique, supported by a computer aided tool, is needed to assist the project Systems Engineer in meeting new responsibilities and to give the Project Manager the insight required. The technique proposed ismeta‐modeling.A practical working tool for project management and systems engineering meta‐modeling is presented using an extension of the tool RDD‐100. A new engineering discipline to provide the skill mix and modeling expertise required for project meta‐modeling is described. This discipline, calledproject engineering, is a natural outgrowth of the convergence of systems engineering and project management.
RDD‐100 IMPLEMENTATION ISSUES
Authors: Sheard Sarah A. 
Published: November 2014

AbstractLoral Federal Systems has begun to use the RDD‐100 (TM, Ascent Logic Corporation) systems engineering tool on a variety of programs, including one large and very complex program. Lessons learned in implementing RDD are collected here, so that managers and others who are thinking of using RDD can set up the introduction wisely. As the tool was introduced to the largest program part way through the development cycle, some of the lessons apply to mid‐phase implementation. Some other lessons would be appropriate for any program using RDD for the first time, and some to any program using tools.
HEURISTIC EXTRAPOLATION IN SYSTEM ARCHITECTURE
Authors: Maier Mark W. 
Published: November 2014

AbstractIn this paper we consider heuristic methods for system architecture. System architecture problems are particularly open‐ended and ill‐structured and resistant to “rational” or “derivational” methods. The heuristic method, employing catalogs of heuristics, is one possible way to address the particular problems of system architecture. The heuristic catalog attempts to capture important and consistent structural elements of complex systems that strongly correlate with success or failure. Unfortunately, most heuristics gathered to date are primarily descriptive rather than prescriptive. This paper describes a method for developing context sensitive prescriptive heuristics as part of a design process that iteratively removes abstraction in the design representation. We call this process heuristic extrapolation. We illustrate the method by application to hardware/software partitioning and the Intelligent Vehicles and Highways System, a large scale sociotechnical system.
SYSTEMS ARCHITECTURE WORKING GROUP
Authors: Smith Timothy B. , Johnson Kent A. , Olson Robert , Ramchandani Chander B. , Pohlmann Lawrence D. 
Published: November 2014

AbstractThis paper is a progress report to the NCOSE membership at large from the NCOSE Systems Architecture Working Group. The paper is intended to serve as the primary mechanism for informing the NCOSE membership of the activities completed and underway by the working group. The paper: 1) discusses motivations for establishing the group, 2) presents the group's charter, 3) provides the current definitions being used for systems architecture and some of the terms relating to systems architecture, 3) presents the working group's current view of what a systems architecture is, and the relationship of a systems architecture to the overall system and the system elements that comprise the system, 4) discusses the future plans of the working group, and 6) presents a bibliography of works that provide significant contributions to the subject of systems architecting and systems architectures.
Reuse of Simple Models Over Many Scales of System Architecture
Authors: Matyskiela Frank 
Published: November 2014

AbstractAs one examines dynamic models of natural or human‐created mechanisms, it is apparent that they can be applied by analogy or reused over a broad range of architectural scales. For purposes of rapid analysis and decision support in a continually changing world, models must be simple and parametric. The dynamic characteristics of three simple models (the Control Hierarchy, Percent of Job Completed, and the Logistics Equation) constructed in a computer‐based simulation tool, are presented. A complete baseline for assessing model reuse, includes the life cycle domains of product and process, identified in current theories and standards on systems engineering improvement, plus the enterprise. Enterprise here is the high level entity that capitalizes, develops and changes corporate and social processes. Parametric context changes, necessary for applying the models across domains are discussed, the most critical being increasing uncertainty of resources and environment, as scale and complexity increase.
Gaining the Competitive Edge through Effective Systems Engineering
Authors: Kasser Joe , Schermerhorn Robin 
Published: November 2014

AbstractGaining the competitive edge through effective Systems Engineering means reducing costs by eliminating ineffective Systems Engineering. This paper first defines Systems Engineering and then identifies the role of the Systems Engineer. The consequences of ineffective Systems Engineering are then discussed at a high level in terms of the cost of, and delays to, both the process and the product. The paper concludes with a strategy for proactive Systems Engineering which can produce the desired system without incurring the cost escalations and schedule delays associated with ineffective Systems Engineering.
A THREE TECHNIQUE APPROACH TO SUCCESSFUL SYSTEM DEVELOPMENT
Authors: Altman Eric J. , Kenrick Karen M. 
Published: November 2014

AbstractOur experience shows that Systems Engineering and other engineering disciplines often work on the same phase throughout the program development life cycle. The combination of a heavy System's task load at the beginning of a program coupled with concurrent tasks with other engineering disciplines for the duration of the program causes System's Engineering to fall behind early on and have to play “catch up” for the duration of the development. In addition, current System Engineering methodology provides few standardized techniques that directly relate or trace System Engineering designs to Software designs.In this paper, we share with our readers the techniques that we used on a predominately software program to solve these problems that we encountered, by using a marriage of three techniques: staggered design phases, graphical threads, and cross reference matrices. The examples in this paper illustrate our implementation of this three‐pronged approach in selected stages of the program life‐cycle, and briefly suggest their possible application to other program phases.
Systems Engineering and the Object‐Oriented Paradigm
Authors: Masnick Burt 
Published: November 2014

ABSTRACTThe Systems Engineering process inherently involves creating some model of the system under development. This model is the basis for the analysis, allocation and subsystem specification used by hardware, software and test engineers as well as other specialists. The paradigm for the model determines the specific information provided to all those who subsequently deal with the development of the system. Object‐oriented representations of software have rapidly become the norm. This creates problems for organizations where systems engineering groups exclusively use functional models and representations of a system. This paper explores the merits of adopting an object‐oriented paradigm in formulating the base models for describing the behavior, interfaces and structure of a system under development.
SYSTEM ENGINEERING PLANNING AND ENTERPRISE IDENTITY
Authors: Grady Jeffrey O. 
Published: November 2014

AbstractThere are so many models to follow in framing an effective systems engineering process that one should hesitate to introduce another. But we are currently failing to make a powerful connection between our enterprise's identity and our customer's needs that will slow our approach to excellence. In this paper we will explore a way to connect a definition of our enterprise in the form of our practices and generic planning to customer needs in a seamless planning process that flows from the proposal period through contract award. This paper was motivated by the U.S. Air Force management initiative called the integrated management system and research accomplished by the author in writing a book by the same title as this paper.
INSTITUTIONALIZING THE ENHANCED SYSTEMS ENGINEERING PROCESS
Authors: Averill Robert D. 
Published: November 2014

AbstractEfforts to implement an effective systems approach to NASA space flight programs are underway agency wide. The Langley Research Center is committed to institutionalizing an enhanced systems engineering process for in‐house space flight projects. A Systems Analysis and Design Procedure has been incorporated into the Langley Project Life Cycle to develop a comprehensive systems engineering process for the critical early formulation phases of a project. A Systems Engineering Handbook has been developed which defines the systems approach and the specific activities and products for each phase of the project life cycle. Systems engineering software tools and training to support the institutionalization process are described.
Determining Metrics for Systems Engineering
Authors: Kasser Joe , Schermerhorn Robin 
Published: November 2014

ABSTRACTSystems Engineering Metrics are not easy to establish, perhaps that is why ineffective Systems Engineering is so prevalent. This paper discusses suggested metrics to measure the degree of effectiveness of both the Systems Engineering product and process. Metrics are suggested for reviews and documentation as examples of measuring the quality of the products, and for the effectiveness of Systems Engineers as examples of measuring the quality of the process.
APPLIED SYSTEMS ENGINEERING METRICS
Authors: Baerlocher Shawn P. , Pyper Walter R. 
Published: November 2014

AbstractThis paper demonstrates a step‐wise approach to the application of metrics to the requirements development portion of the systems engineering process as illustrated in Figure 1. The application to each phase of the product life cycle is also described, and the System Maturity Matrix (SMM) approach to product development is presented. The SMM use of metrics is part of an evolving approach to use in‐process assessment of the status of product development, as opposed to more traditional post‐process approaches which rely heavily upon developer reviews at the end of each development phase.
Application of Systems Engineering Methodology to the Design of an Agricultural Research Program
Authors: Schneider S. M. , Karlen D. L. , Shannon M. C. , Amerman C. R. 
Published: November 2014

AbstractIn 1991, USDA and EPA agreed to a joint program in Integrated Farm Management Systems (IFMS). In 1992, the Agricultural Research Service of USDA assigned four Systems Engineers to develop concepts for a research program in IFMS. Customer groups representing farmers, researchers, environmentalists, agribusiness, and administrators were interviewed to determine the necessary inputs, outputs, and performance requirements of the system. The inputs were identified as resources and demands for service. The outputs included plans for farm management, research publications, and software. Performance criteria were grouped into three categories; SYSTEM OPERATION, QUALITY of FARM PLANS, and RESEARCH PRODUCTIVITY. Four concepts were developed which met the I/O and performance requirements. The strengths and weaknesses of each concept were identified. The concepts were evaluated under three different hypothetical input scenarios. The CONTRACTS concept had the highest overall performance score across the three scenarios, but the PANELS concept had the highest performance per unit cost value. Sensitivity analyses identified the performance requirements contributing to the QUALITY of FARM PLANS as having the greatest overall impact on the system performance score.
SYSTEM ENGINEERING: COMMUNICATING FROM A SYSTEM DESIGN DATABASE
Authors: Baker Loyd 
Published: November 2014

AbstractDuring a recent System Engineering Tool Users Group meeting, a common complaint voiced by users was, “getting the desired data / information out of the project's analysis/design database in a timely fashion, and in a usable form, has been a major obstacle to the adoption of automated system engineering tools”. Keeping project members, management, and customers informed about the evolving system specification/design is crucial to maintaining a competitive edge. If the required project data/information can not be accessed, documented, and shared quickly enough, the expected benefits to be gained by communicating from a comprehensive project analysis/design database may not be realized. This paper discusses a process that makes publication of project documents a by‐product of the engineering/management process, providing increased productivity due to improved communication of requirements, design decisions/rationale, system verification, and traceability of system changes.
A SYSTEMS ENGINEERING APPROACH TO FAULT ISOLATE AND ASSESS DEGRADED MODES IN A REAL‐TIME BUILT‐IN‐TEST ENVIRONMENT
Authors: Sanchez James A. , Systems Radar 
Published: November 2014

AbstractThis paper describes a methodology that was successfully implemented as an experiment within a tactical radar program to create a software package with features superior to traditional customized software. The critical elements of the system are described in a way that makes it easier to create the package. These elements are then modeled, and a software package is created.For the systems engineer the package has made transformations from specification to executable symbols so economical that the cost of making changes becomes almost inconsequential. A development effort that took six man‐months in past years was reduced to a one hour effort, as illustrated in Figure 1. Moreover, the software package could be transported to any similar platform for use in radar software development efforts.The result is a reliable tool that has uncovered errors encoded by programmers, as well as system engineers, in prior years. The ease of use and consistency of results empowers the system engineers who are not trained as software developers. Errors due to the shear volume of detailed specifications or miscommunication among various people are greatly reduced. When hardware and software efforts are developed in parallel, changes to the target machine's I/O interface can be implemented quickly.In the world of personal computers, the user often has any number of software packages from which to choose. The user examines the limitations and features of various packages and makes a comparison. A particular package may not meet a specific user's needs, whereupon the persevering user either works with what is available or communicates the need for a new or enhanced software package.Using the methodology described in this paper an engineer can present the needs of the system as 1) fundamental pieces of information separated into logical groups, 2) rules of dependence among the groups, 3) attributes of each related group of information, and 4) functions to be performed on the information. A mathematical model may then be constructed and realized in the form of a reusable software package. This package is then judged on the basis of meeting the user's needs, including ease of installation, cost, user friendliness and similar “customer” criteria.