bluuebunny/crossref_metadata_2025 huggingface dataset:
AN OPERATIONS CONCEPT DEVELOPMENT METHODOLOGY USING A GRAPHIC PROCESS FLOW TECHNIQUE
Authors: Denzler David W. R. , Mackey William
Published: November 2014

An iterative methodology has been developed for creating operations concept documents (OCDs) that improves operations concept development by using a graphic process flow technique. This technique analyzes and presents the operations concept in a format that system developers, customers, and operations personnel can readily understand. The approach reduces costs and complexities associated with the more conventional OCD development preparation by stressing hierarchical text development. For example, one OCD constructed using this methodology was completed in 20 percent of the conventional development time.
DEVELOPING A CAPABILITY MATURITY MODEL FOR SYSTEMS ENGINEERING
Authors: Kuhn Dorothy A. , Garcia Suzanne M.
Published: November 2014

A proposed collaboration of industry to develop a capability maturity model and assessment instrument for systems engineering was made at the 1993 NCOSE Symposium. Several companies have participated in this collaboration, providing dedicated staff and resources to do the work.

This paper presents the goals, structure and nature of this collaboration and the results of its efforts to date.
Interim Maturity Model
Authors: Reichner Al
Published: November 2014

Ideally, a systems engineering maturity model, together with a questionnaire and supporting documentation, provides the capability for an organization to do a self assessment of its processes, practices, management, metrics, and quality. It would be a framework for assessing an organization's level of systems engineering maturity. Currently, several corporations, educational institutions, and government agencies are doing research in the field of systems engineering maturity models. This paper describes some of the research and products. Loral Space and Range Systems (LS&RS), realizing the potential benefits of a self assessment, used a model developed by Bill Money of Loral Command and Control Systems and evaluated its Systems Engineering Laboratory's maturity. The proponents of the assessment process hoped that the evaluation would provide an assessment of the current state of the division's systems engineering maturity, guidance for improvement, and improve effectiveness, making the organization more competitive. This paper presents an overview of the key features of the Loral model, how Loral used the model, and a summary of the findings and action plan. Even with its weaknesses, the assessment process was definitely worth the effort and cost. The paper concludes with recommendations on how others can benefit from the LS&RS maturity model experience.
Retooling the Organization
Authors: Schuster Cecilia H.
Published: November 2014

Even in this age of “Continued Process Improvements” where companies are paying increasing attention to their processes, attention may fail to be focused on day‐to‐day details in actual procedures until a tool is applied to the job. This paper addresses case studies that illustrate common pitfalls encounted when introducing automation into organizations. The conclusion supported by these illustrations is that technology insertion should be planned and that people are the most important factor in planning for change.
AN INTEGRATED APPROACH TO COMPLEX SYSTEMS ANALYSIS AND PERFORMANCE SIMULATION
Authors: Peterson Kenneth J. , Mar Brian W.
Published: November 2014

This paper presents a classification of types of simulation techniques and a correlation matrix that maps types of simulation techniques and types of systems engineering tasks. An analysis identifying the most appropriate application of specific types of simulation to “front end” systems engineering task is presented. A template for creating specifications to acquire systems engineering support and system simulation tools is developed to allow systems engineering efforts to increase their level of maturity.
MANAGING COMPLEXITY: AN APPLICATION OF CONSTRAINT THEORY
Authors: Friedman George J.
Published: November 2014

A fundamental intellectual thrust of Systems Engineering thinking is its extensive nature: the ability to integrate across many dimensions and disciplines, and to formulate problems. By contrast, most of our engineering and scientific education has concentrated on intensive thought processes: the concentration on relatively low dimensional submodels and the solution of problems. This paper provides a framework to guide systems engineers in multidimensional thought processes and problem formulation. It is based on the constraint theory developed by Dr. George J. Friedman.
SYSTEMS THINKING FOR PRODUCT DEVELOPMENT
Authors: Dick Michael J.
Published: November 2014

SYSTEMS THINKING is a disciplined methodology for dramatically improving both the quality and the development/production efficiency of high technology customer‐focused products. It begins at product inception and applies throughout the product lifecycle.

Systems thinking gives multidisciplinary teams a simple, thorough methodology for understanding the interdependence, interaction, and tradeoff among the many complex product development concerns.

At each phase of product development, systems thinking uses a simple, integrated set of activities: 1) Address the full spectrum of product objectives/requirements. 2) Stimulate and guide the generation of new ideas. 3) Perform risk‐based concept evaluation. 4) Use fault analysis to pinpoint and correct weak areas. 5) Document decisions and lessons learned.

Using systems thinking at each phase of product development assures meticulously thought out decisions before proceeding to the next phase. Such forethought is essential for success with today's complex products.
A CONCURRENT METHODOLOGY FOR THE SYSTEM ENGINEERING DESIGN PROCESS
Authors: Childers Susan Rose , Long James E.
Published: November 2014

The system engineering design process as detailed in MIL‐STD 499 does not adequately address the incorporation of design issues relevant to specialty engineering disciplines. This paper details a process by which the concerns of specialty engineers are addressed and incorporated into the system design in a consistent and efficient manner. The paper also introduces an incremental system engineering process (The Onion Model) which allows complete interim solutions at increasing levels of detail during the system specification process.

Along with the three standard concurrent engineering focuses of requirements analysis, functional analysis, and architecture definition, the process includes concurrencies for specialty engineering. Each specialty engineer assesses the implications of the system engineering design process in relation to the specific specialty requirements and evaluates the implications of the system functional and physical architectures on the realization of an adequate specialty engineering solution. Once an integrated solution achieves the approval of the acquisition agency, it is refined to the next level of detail. When the system level design is sufficiently refined to generate the System/Segment Specification, the segment development process may begin.
IDENTIFYING PROFILING SYSTEM REQUIREMENTS WITH QUALITY FUNCTION DEPLOYMENT
Authors: LaSala Kenneth P.
Published: November 2014

System engineering may be accomplished by many approaches. Central to each approach, however, is the development of clear, consistent user requirements and their translation into corresponding technical requirements. Quality Function Deployment (QFD) has been shown to be an effective means of developing and translating requirements. To test the applicability of QFD to NOAA systems, a generic, hypothetical atmospheric profiling network was subjected to a limited application of QFD. The results, though limited, showed that QFD can be applied to NOAA systems. Although more work is required to complete the profiler application in detail, this limited application has provided a model and lessons learned. Although this paper discusses a system of potential use within NOAA, the views expressed in this paper are solely those of the author and do not necessarily represent the views of NOAA.
FREQUENTLY ASKED QUESTIONS ON SYSTEMS ENGINEERING PROCESS
Authors: Rhodes Donna H.
Published: November 2014

The evolution of engineering processes is greatly enhanced through the sharing of lessons learned between organizations. Loral Federal Systems (formerly IBM Federal Systems Company) has evolved its Systems Engineering process over the past decade to a fairly mature process, with clearly defined ownership. Over the past several years, we've participated in many interchanges with other companies and organizations. Out of these exchanges, thoughts on various aspects of process management become crystallized through discussions on the FAQs ‐ Frequently Asked Questions. This paper addresses many of the frequently asked questions brought up in process exchanges, and the related lessons learned in hopes that other process owners will benefit and that further discussion will be prompted as a result.
Benchmarking System Engineering: Harris Case Study
Authors: Kraemer Bruce P. , Kabaservice Thomas P.
Published: November 2014

In 1991 Harris' Electronic System Sector decided to look for new ways to achieve significant improvements in its product development capabilities. A variety of plausible efforts were considered. One of the projects undertaken was to explore the applicability of Benchmarking as applied to the System Engineering discipline.

In this paper Harris describes its benchmarking journey including the project origins, approach to benchmarking and lessons learned in applying this improvement technique.

The practice of benchmarking requires a considerable amount of honesty and “soul baring” between benchmarking partners. But, it is accepted practice that information shared between partners be held in confidence. Therefore, this paper concentrates on the approach used and lessons learned in applying benchmarking rather than specific insights regarding how Harris or its benchmarking partners currently conduct their System Engineering or might change System Engineering practices as a result of the benchmarking.
Object Oriented Life Cycle Approach to System Engineering
Authors: Tronstad Yngvar D.
Published: November 2014

This paper provides a description of an Object Oriented Life Cycle process and methodology that combines System Engineering and HW/SW Engineering in one unified formal representation. The method, called RDDTM‐Object Modeler (RDDTM‐OM), emphasizes the interaction of the objects in the context of the system. This is done by object semantics that represents the components of the system, their interconnection and their behavioral interaction, to the level of detail that describes distributed design of computer based systems. The focus on objects that are transformed throughout the steps of the development process ensures a traceable and strong coupling to the problem at hand. If system requirements are based on an object oriented approach starting with the understanding of the problem domain, re‐use is easier and more likely to occur.
A SYSTEMS ENGINEERING FRAMEWORK BASED ON CARTESIAN ARRAYS OF SETS
Authors: Haines David E.
Published: November 2014

Increasingly, the system engineer's primary function is to facilitate knowledge capture from a concurrent product team. This role increases the need for the systems engineer to architect a data environment that meets strict criteria for a structurally valid schema. An encompassing theoretical base for creating such data structures is currently unavailable to the practicing systems engineer. Starting with the “three view” schema of MIL‐STD‐499B, a data array paradigm based on elementary theories of sets and arrays is developed as a generally applicable structure. This paradigm is then demonstrated with several examples of structured systems engineering practice. These are compared with current practices and usage to test for errors. Conclusions reached are 1) That even at the level presented, this paradigm can assist systems engineers in improving their real‐world practices; 2) Structured analysis should receive more attention in academic curricula for systems engineers; 3) Individuals knowledgeable in mathematical array and structural theories as well as systems engineering should contribute to a more complete body of formal theory; and, 4) Structural validity of the project schema should be regarded as a “first principle” for world‐class systems engineering. Recommendations include suggestions for “best practices” groundrules that could be defined now, and speculation as to where expanded theoretical development should take place for maximum benefit to the industry.
IMPLANTING EDUCATION IN SYSTEMS ENGINEERING IN A UNIVERSITY
Authors: Thomé Bernhard
Published: November 2014

This paper reports on a course on Systems Engineering of Computer‐Based Systems being given at a university. This particular course has the goal of laying a seed for a change in culture in universities. The cultural change targeted is for universities to offer their customers, its student body, a more systems engineering oriented educational opportunity. From this, it is felt, not only the companies in the systems business will benefit, but the students concerned as well, and ultimately also the universities courageous enough to venture in this direction.
The Systems Engineering Network at Hughes Aircraft Company
Authors: Miller Gary D.
Published: November 2014

This paper is an introduction to and an explanation of the Systems Engineering Network at Hughes Aircraft Company. The Systems Engineering Network (SEN) was established by the Executives of the Company, having determined that in the rapidly changing environment in which Hughes does business, a robust, modern, effective and efficient Systems Engineering capability was crucial to our competitive edge. To establish and maintain such capability the Systems Engineering Network was tasked to address all aspects of systems engineering for the corporation, cutting across all organizational boundaries. This paper will examine all aspects of the Systems Engineering Network at Hughes, including its history, its goals and objectives and its organization and structure. How the network goes about its business will be discussed, and the mechanisms for creating and sustaining improvements in the business of the Company will be explained.
ASEM ‐ A Simple Engineering Training and Personal Automation Tool
Authors: Whitten Carolyn , Keizur Alan , Mar Brian W.
Published: November 2014

This paper describes a simple systems engineering training and support tool called ASEM. Experiences in using ASEM to teach more than 300 students in formal university and professional training courses are described.

The purpose of ASEM is to support (1) the functional analysis, (2) the requirements analysis and allocation, (3) the recording of architectural decisions, test requirements and results and (3) the hierarchical development of any system description. The systems engineering process was used to create, test, and apply this tool. The tool has been well received in a teaching environment.
DESIGN OF A SYSTEM‐OF‐SYSTEMS ARCHITECTURE MODEL AND ITS USE TO IDENTIFY CROSS‐SYSTEM IMPACTS
Authors: McCay Brian M.
Published: November 2014

This paper describes the techniques used to build and extract information from an architecture model of an as‐built system‐of‐systems. The purpose of this paper is to describe the technical and procedural challenges in building the model using the commercially available systems engineering tool, RDD‐100. The paper also discusses how architecture model information is being used to identify potential cross‐system impacts due to proposed changes. The overall goal is to provide guidance to systems engineers to enable them to successfully develop useful models that support the controlled evolution of a system‐of‐systems architecture.
ADVANCED SYSTEM ENGINEERING AUTOMATION (ASEA)
Authors: LaMonica Frank S. , Comer Edward R.
Published: November 2014

This technical paper provides an overview of Rome Laboratory's Research & Development Program in the area of System Engineering. In particular, it describes the results of an exploratory development effort which specified the system level requirements and operational concept for system engineering automation known as Catalyst, and focuses on an advanced development effort entitled “Advanced System Engineering Automation (ASEA)” which is implementing the automation concept.
INTEGRATING SYSTEM ENGINEERING INTO THE SOFTWARE AND HARDWARE DESIGN PROCESS
Authors: Mori Daniel J.
Published: November 2014

A decline in the defense budget has driven contractors to search for the “panacea tool” which will solve all of its productivity and manpower problems. Companies purchase tools to perform Object Oriented Analysis, Computer Aided Engineering, Requirements Traceability, and System Synthesis with little thought as to how they will be integrated.

The process by which a company performs its engineering tasks must be considered when contemplating tool purchases. The tool must not only perform its required task in a satisfactory method, but also be easily integrated into other engineers' efforts. There should be a logical mapping between system engineering and hardware/software design tasks to ensure all engineers are cognizant of what is required, and that the design satisfies those requirements. When defining this integrated process, it is important that the handover of system engineering requirements to design be provided in a recognizable and usable form.

This paper describes a possible approach that can be used to integrate the outputs of the system engineering process into inputs of the software and hardware design process. This “integrated approach” is based upon the author's knowledge of existing tools and methodologies. The use of specific tools is included not to promote these tools or approaches, but to show feasibility of one approach with existing tools.
SPACE SYSTEMS PRELIMINARY DESIGN
Authors: GORY Jean‐François
Published: November 2014

As in all other industries, the space industry is evolving in three primary areas: technology, costs and socio‐organisational approaches.

A project conducted in CNES aims to revise the definition of future space systems with the introduction of global methods and computer‐aided tools. One of the main goals is the definition and the development of a cooperative workbench for missions and space systems design. It will be composed of a certain number of design and simulation tools dealing with unique and coherent information shared between different view points. Operated in CNES, this computer‐based workbench will focus on the early stages of projects but will also treat first order or “simplified” models which are managed daily during the projects' life span, in accordance with the detailed models from industry.
DATA QUALITY ENGINEERING: A SYSTEMS ENGINEERING “ENABLER”
Authors: Lehman Joseph R.
Published: November 2014

This paper briefly describes the circumstances that led to “legacy” automated data systems and characterizes the problems faced by today's large organizations as they grapple with escalating system maintenance costs, redundancy in data collection and maintenance efforts, and inadequate data quality. Some have developed a legacy system migration strategy that specifies, among other things, a requirement for integrated systems, common data standards, and a data repository system. However, most have had limited success at best in implementing practical, affordable solutions. This paper describes a successful approach out of the legacy morass—a rigorous methodology called “data quality engineering” (DQE). The DQE methodology provides a proven means for designing and implementing a workable migration strategy that features incremental improvement in system operations, implementation of a working data repository, and, most important, restored quality in the data values maintained in database files.
USE OF PERFORMANCE EVALUATION TOOLS IN SYSTEMS ENGINEERING
Authors: Vallone Antonio
Published: November 2014

Systems engineers define system operations concepts, analyze system requirements, allocate the requirements to system architectural components (hardware, software, and operations), design the system configuration (hardware selection and sizing), and support system implementation. System performance is a major area of concern during the system development life cycle. System performance evaluation tools make life easier for the systems engineering team.
DIFFERENT PHILOSOPHIES / DIFFERENT METHODS: RDD AND IDEF
Authors: Griffith Patricia B.
Published: November 2014

The Requirements Driven Development (RDD1) method and the Integrated Computer Aided Manufacturing (ICAM) DEEinition language (IDEF) methods are frequently considered competitively for use on a systems engineering project. The purpose of this paper is to clarify some of the ways in which the two method families are vastly different in modeling purpose, method philosophy, usage styles, underlying concepts and history. The first section describes basic needs for SE methods and sources of confusion in method selection. The second section discusses major differences between RDD and the IDEF family. Two lessons in terms of method and tool selection are offered.
MANAGING A SYSTEMS ENGINEERING TOOL IN A PROJECT ENVIRONMENT
Authors: York Donald M.
Published: November 2014

Rather than understanding the detailed mechanics of a Systems Engineering tool, the customer wants to be assured that an integrated systems engineering approach is being implemented on his project. The customer also wants the assurance that the design engineers are working with and talking to the Systems Engineers on an ongoing basis. Effective management of a Systems Engineering tool can provide these assurances.

However, many obstacles arise in managing the tool. This paper discusses these obstacles and presents lessons learned from managing Systems Engineering tools during several projects. Recommendations are provided for effectively managing any System Engineering tool such that an integrated Systems Engineering approach is realized and demonstrated to the customer.
PAYLOAD COST MINIMIZATION USING SEAT
Authors: Autio Gordon W.
Published: November 2014

This paper discusses the application of a methodology to arrive at a minimum cost solution to a given set of systems requirements for any electro‐optical (E‐O) payload. The Systems Engineering Analysis Tool (SEAT) is a powerful tool for the parametric analysis and cost‐effective design of E‐0 payloads. Cost estimating relationships (CERs) as a function of cost driving parameters for each subsystem along with design/performance parameters are input as analytical expressions into an existing tool called Multisensor Analysis Tool to perform the payload cost minimization. The quality function deployment (QFD) matrix or house of quality is used as an aid in deriving the system cost drivers. Various parametric trades and graphic plots in both 3‐D and 2‐D that show relative payload cost and signal‐to‐noise ratio (SNR) performance are presented. The goal is to integrate the disciplines of systems engineering and cost estimating into a cohesive, interactive process early in the system life cycle.
ISSUE DRIVEN DESIGN: PLANNING AND MANAGING DESIGN ITERATIONS
Authors: Alford Mack
Published: November 2014

The general recognition that the design process is iterative in nature presents the manager with a problem: how does one manage an iterative process? On the one hand, the manager would like to see a sequence of well defined tasks with well defined outputs. On the other hand, the design process may more strongly resemble a “search” process, in which the territory is unknown. This paper addresses this problem by providing techniques for defining and characterizing a sequence of partial designs.
Design Methods And Heuristics For A New High‐Volume Production System
Authors: Cavola Ray G.
Published: November 2014

This paper assesses two key elements of systems architecting: methodologies and heuristics, as they are applied to the concept design of a new high‐volume, discrete part assembly production system. A description of the system is provided, and then attention is focused on four major areas in the design: human factors design, system structure development, assembly scope definition, and system operating principles. In addition to descibing the use of existing heurisics, this paper presents and supports new heuristics developed in the course of architecting this system. These methods and heuristics have enabled forward progress in an evolution toward world‐class manufacturing.
Systems Engineering Practices in Generic Architecture Development and Tailoring
Authors: Wray Richard B.
Published: November 2014

A common practice in systems engineering is the reuse of successful approaches, techniques and templates from previous programs or similar development efforts. Very rarely in present systems development do we successfully use and document a generic approach or template for development which can be reused for specific programs and missions. Under National Aeronautics and Space Administration (NASA) contract, a Space Generic Open Avionics Architecture (SGOAA) was developed for application to new space systems development. A case example of applying “tried and true” systems engineering principles in tailoring the architecture to a planned spacecraft for new lunar missions is described. Included is a summary of the principles applied, the methodology used, the key development process elements, the interface definition process, and lessons learned. This example demonstrates that a formal systems engineering methodology is needed, a generic architecture can provide a means for verifying all key interfaces, functional interfaces addressing user requirements should lead to logical and derived direct interface requirements, and interfaces should be simulated and rigorously tested to validate needs satisfied and performance acceptability.
DRIVING THE FIRST STAKE IN THE GROUND
Authors: McClinton David F.
Published: November 2014

The paper describes a technique for making those difficult first system architectural decisions in a major engineering project. A few key decisions set the overall architecture and allow the lower level analyses and trade studies to progress. Three examples are given from early initial system studies on two major aerospace study programs. Requirement dependencies and parameter space constraints are shown. The step by step process is explained. The approach is applicable to any system architecture.
SYSTEM ENGINEERING FOR ALL ENGINEERS
Authors: Bailey Michelle , Butterworth Jay , Fortune Mitzi , Kibbe Jim , Kaspersen Janice , Smith Bob , Stringham Mike
Published: November 2014

This paper describes a plan to increase the capability of general engineers in the area of system engineering and to increase the number of system engineers within an organization. Key features are emphasis on a hierarchy of system engineering capability, experience and demonstrated skills, involvement of the first‐line supervisor, facilitating early responsibility, and the ability to tailor the training and experience to the needs of the individual. Included are the preliminary measures of effectiveness.
AN APPROACH FOR IMPROVING SYSTEMS ENGINEERING COST ESTIMATION
Authors: Tilton Catherine J. , Triantis Konstantinos P.
Published: November 2014

A critical part of a proposal for the development of a complex system is cost. One important element of this cost is the effort to perform the systems engineering function. The prevalent method for estimating these costs is a “bottom up” engineering estimate based on the experience and judgement of the estimator. In some cases, analogy to actual costs of previous, similar programs is employed. As practiced, neither of these methods provide the accuracy, consistency, or defensibility needed.

This paper summarizes current practices and problems, identifies systems engineering cost drivers, and presents an approach for improving the ability to estimate systems engineering costs. The primary conclusion derived is a confirmation of the need for improvement in this area and the role of a comparable database of costs and cost drivers, as well as management commitment, in this process.
Process Based System Engineering
Authors: Tronstad Yngvar , Earley Robert , Shreve Sue
Published: November 2014

This paper provides a description of a Life Cycle Process Base that combines system engineering techniques and tools for modeling the product to be built with the process for building it. The process template described here provides a means for formally defining the system development process, and then identifying the methods and tools that support the design process. With the adoption and allocation to a specific organization, the template becomes a process. Through simulation and enactment of the process description, an organization is empowered to engineer and evolve the process over time and effectively manage and control the complexity of today's large scale programs.
THE AMAZINGLY INVARIANT SYSTEMS ENGINEERING PROCESS–A 30 YEAR LOOK
Authors: Kuhn Dorothy A.
Published: November 2014

From time to time, systems engineers find themselves debating the subject of the systems engineering process. These debaters are commonly experienced systems engineers that may not, at the time, realize the limitations of arguing from experience. It is the trap of generalizing from a specific.

The systems engineering process is well established in the systems engineering literature; it is a pragmatic engineering process that has at its basis the practices of scientific inquiry. The systems engineering literature shows that the fundamentals of this process have changed very little over the past 30 years.

This paper will describe the fundamental systems engineering process, as shared by businesses as diverse as telecommunications, agriculture and defense, and will give an example of how that process is practiced in the 1990s at Texas Instruments Incorporated.
PARTITIONING COMPLEX SYSTEM DESIGN INTO FIVE VIEWS
Authors: Karangelen Nicholas E. , Hoang NgocDung T.
Published: November 2014

The complexity and sheer magnitude of modern computer based systems require a structured approach for their development. The principal objective of system development is to establish a design which satisfies the system requirements while optimizing the key trade‐offs associated with system functionality, behavior, and implementation. A methodology is presented in this paper for a multi‐domain system design capture approach. The methodology employs five views of the system which address the system design in separate but related domains. The basis for creating an integrated, automated environment for addressing design, capture and analysis of a complex system is discussed by: (1) defining each of the five views and organizing those views into three models of the system, (2) defining the relationships and dependencies between the models of a given system, and (3) identifying opportunities for application of advanced modeling and decision support techniques in the design, capture, and analysis of complex systems.
Automating Best Practices: The Challenge of Process Enactment
Authors: Masselle Eric , Rhodes Donna H.
Published: November 2014

Process Enactment, or Workflow Management as it is sometimes called, provides a new technology approach which captures a well‐defined, optimized process and encodes it in an executable form. The encoded process is then enacted, providing for automated execution of tasks and activities and the controlled management of all information and data associated with the process. Enactment can be expected to influence both the way we do business and solutions we develop for customers. This paper focuses on the many challenges of process enactment, from both a technical and a cultural perspective. Also discussed will be a pilot project that has provided a test bed for demonstration and evaluation of enactment in our systems engineering environment.
Information System Security Engineering, MIL‐STD‐499B, and Trusted Development Methodology
Authors: Howe Donald M.
Published: November 2014

This paper provides an introduction to Information System Security Engineering in conjunction with the draft MEL‐STD‐499B for Systems Engineering. The generic system security engineering activities are identified with respect to each phase in the life cycle, and security documents are listed. The paper also discusses the trusted‐software‐development‐process as a method for achieving high assurance.
A Process for Systems Engineering Planning
Authors: Martin James N.
Published: November 2014

This paper describes the Systems Engineering Planning process used in AT&T Advanced Technology Systems. A process diagram is shown with 19 specific process tasks. Each of these process tasks are defined. In addition, inputs and outputs from each process task are defined. This process is intended to be used at the beginning of each project and the major output is a Systems Engineering Management Plan (SEMP). Other outputs are the Systems Engineering Master Schedule (SEMS), Systems Engineering Detailed Schedule (SEDS), and a Systems Engineering Development Environment (SEDE) Plan.
Systems Engineering Metrics ++
Authors: Miller William D.
Published: November 2014

This paper describes the internal AT&T Advanced Technology Systems (ATS) concerns with the current high level systems engineering metrics and the ongoing work to improve their definition to better reflect systems engineering's value to the R&D process. The current high level productivity and cost metrics are based on page counts that do not give any indication of the quality of the content on the pages. The systems engineering organization is considering a redefinition of the high level productivity and cost metrics based on function/feature points similar to their definition in software engineering. A constraint is that the revised high level metrics be derivable from the existing detailed systems engineering metrics. These feature/function point based metrics are calibrated to the project mix within AT&T ATS.
MEASUREMENT AT THE SYSTEMS LEVEL: WHERE WE ARE AND WHERE WE OUGHT TO BE
Authors: Cruickshank R. , Gaffney J. , Werling R.
Published: November 2014

The primary purpose of a systematic measurement program is to provide quantitative information to support improved management and engineering decision making associated with system development and systems engineering activities. The measurement process includes the selection of metrics; the collection of data; and the integration, analysis, and reporting of quantitative information derived from the data. The Goal‐Question‐Metric (GQM) paradigm is the recommended approach for selecting metrics to provide the quantitative information for management and engineering purposes. The top‐down, information need‐based GQM paradigm has been used extensively to define metrics appropriate for software development and process improvement, and it can also be applied to system development and systems engineering.
The Lockheed Missiles & Space Company System Engineering Training Program
Authors: Khouri Jennifer , Morais Pam , Haskell Anita
Published: November 2014

Lockheed Missiles & Space Company's (LMSC's) Space Systems Division (SSD) has long felt a need to train system engineers, to continue to develop and improve the system engineering and integration skills which are our hallmark. As part of our commitment to system engineering training, our division established a formal System Engineering Training (SET) program, designed to provide intensive system engineering training to a small group of young engineers, who would then go throughout the division, working on different programs and sharing the knowledge they had gained. The following paper provides a more detailed description of the SET program.
SYSTEM ENGINEERING METRICS
Authors: Cabrera O. J.
Published: November 2014

The purpose of this paper is to show the evolution of System Engineering (SE) metrics at Harris Government Communication Systems Division (GCSD). Beginning in the late 80s, the SE Department started to collect a number of metrics over the life cycle of our program execution process. An example will be shown and discussed. Working within the framework of our Total Quality Management (TQM) culture and in the spirit of continuous improvement (starting in FY 1991), other metrics were considered and reviewed for applicability. A list of these metrics will be shown. The main goals of this metric review process were to (1) improve our way of doing business and (2) maximize the impact of the metrics on our program execution process. To this end, a new metric baseline was adopted in mid‐1993. This new baseline and a definition of each metric will be explained. Examples of Technical Performance Measurements (TPMs), as defined in MIL‐STD‐499B, are shown. TPMs are an important SE tool to control the baseline and manage requirements.
APPLYING SYSTEMS ENGINEERING AND ICON‐DRIVEN SIMULATION TECHNIQUES TO THE WASTE DISPOSAL PROBLEM AT HANFORD, WA
Authors: Keizur Alan E. , Mar Brian W.
Published: November 2014

This paper provides a case study on the use of systems engineering to create the hierarchical description of a decision‐support model for the tank waste remediation program at Hanford, WA. A commercial, off‐the‐shelf (COTS) icon‐driven modeling package is used to sharply reduce the model development effort. A database‐driven information management tool, used to describe the model functions, requirements, architectures and tests, provides the traceability and editing power to document the development with little added effort.
SYSTEMS ENGINEERING APPLIED TO STRATEGIC PLANNING: THE LASE FOLLOW‐ON STUDY
Authors: Walters J. Milam
Published: November 2014

The NASA Langley Research Center, Systems Engineering Office, has established a structured process for the application of systems engineering to in‐house projects. Concurrent with this process development, several pilot studies have been conducted to refine the application steps and better tailor them to existing Langley policies and procedures. One such study is the subject of this paper, the LIDAR Atmospheric Sensing Experiment (LASE) Follow‐On Study. The study was commissioned to utilize the LaRC systems engineering process for strategic planning, towards the overall goal of determining the best use of LASE hardware upon satisfaction of existing scientific objectives. This paper describes the process used, techniques employed, results obtained and lessons learned during application of the LaRC systems engineering process to the strategic resolution of the LASE experiment disposition.
RESULTS OF A SYSTEMS ENGINEERING DESIGN AUTOMATION LANDMARK STUDY AT TEXAS INSTRUMENTS INCORPORATED
Authors: Kuhn Dorothy A.
Published: November 2014

Within Texas Instruments' defense business (DSEG), high‐level managers recognized the need to improve the productivity of the systems engineering staff, and tasked a group of experienced systems engineers to execute a Systems Engineering Design Automation Landmark Study. This study was built on an analytical understanding of our systems engineering process, and included a survey of the systems engineering staff, a systems engineerng market analysis, analysis of systems engineering automation requirements, and an implementation plan for systems engineering automation. This paper describes the study and its results.
A METHOD FOR STRUCTURING THE SPECIFICATION AND DEVELOPMENT OF SYSTEMS ACROSS DISCIPLINES
Authors: McMullen Scott
Published: November 2014

This writing describes a structured approach for product development called trans‐functional development. Trans‐functional development utilizes the physical system architecture to cohesively manage product development across disciplines. The technique has been adapted from the Hatley/Pirbhai method for real‐time system specification and was first implemented during a period from 1992 to 1993. This technique was developed in response to the needs of a company which had become overwhelmed with regulatory guidelines, CASE learning curves, slipping schedules, reliability problems, and lack of requirements. The trans‐functional development approach takes these factors into account as it attempts to simplify and organize systems engineering management in a commercial environment. The company, that used the approach from 1992 to 1993, indicated that it has been the most comprehensive and understandable approach that they have been exposed to, and they will use it again on their next project.
ADVANCING SYSTEM ENGINEERING WITH A REQUIREMENTS PROBLEM REPORTING PROCESS
Authors: Agarwal Naresh K. , Jones James H.
Published: November 2014

This How‐To paper is for those persons newer to the global perspective of systems engineering. It describes adapting the formal software change control process of DOD‐STD‐2167A for use in improving a deficient hardware process as part of increasing its maturity of capability. After minor procedures and forms revision, while using identical computer support and physical paper handling to that of Software Problem Report processing, Requirements Management was improved. The experiment resulted in “earlier” correct specification of system design requirements, interface requirements, and design verification requirements for hardware configuration items.
The Allegory of the Humidifier: A case study of Return on Investment in Systems Engineering
Authors: Sampson Mark E.
Published: November 2014

Following is a case study of the down stream affects of short term decisions based solely upon short‐horizon cost savings. A case is made for “no decision is a island” and documents how a simple (<$10k) initial decision had million dollar impacts down stream. This allegory also points out the importance of getting our Systems Engineering right before launching into other productivity improvement programs–JIT, reengineering efforts, cycle time reduction, Continuous Improvement, and others‐all of which points out the key importance that Systems Engineering should be playing in our companies.
Landfill NIMBY and Systems Engineering: A Paradigm for Urban Planning
Authors: Lee G. Fred , Jones‐Lee Anne , Martin Frederick
Published: November 2014

A solid waste management crisis exists in many parts of the US as a result of the inability to site new landfills to replace the consumed capacity of existing landfills. Municipal solid waste (MSW) landfills can, and usually do, have a significant adverse impact on the individuals who own property in, reside in, or otherwise use, areas near the landfill. This leads those who stand to be adversely affected by a landfill to take a justifiable “NIMBY” (Not in My Back Yard) position against it. In the past and even today the approach that is used for siting landfills is to select one or more specifically rural areas as candidate sites and then through a contrived process, force one or more of those sites on those who own or use nearby properties. If those in the potential sphere of influence of the landfill, which is often several miles from its location, are sufficiently politically powerful or have sufficient financial resources to actively oppose the siting of the landfill in their region, they can usually be successful in stopping the landfill from being sited in their area.

Some jurisdictions purport to involve the public in the site‐selection process by appointing a “citizens advisory committee” (CAC). The CAC is then “allowed” to select and rank the parameters of concern with respect to the landfill. Based on an arbitrarily developed numeric scoring system, various potential candidate sites are ranked and those with the highest ranking are selected as the “best available sites. ” While the site‐selection process and the design of the landfill should be coordinated and concurrent activities, they are typically pursued sequentially which contributes to the unreliability of the process. While this process appears superficially to have a technical aura about it, and public participation components in it, it is highly arbitrary and frequently capricious in its implementation. Rarely does this process lead to “the best available site” that would enable the development of a particular landfill at the particular location without a significant adverse impact on the current owners and users of nearby lands, future generations who may own or use those lands, and those who would use groundwaters hydraulically connected to the area at some time in the future.

There is need to take a significantly different approach to landfill siting than is being used today. Systems engineering provides a potential methodology for rigorous incorporation of the various factors that need to be considered in developing solid waste management capacity for a region. This paper reviews the issues of site selection for MSW management, legitimate NIMBY concerns, and how systems engineering could be used to more appropriately select a site/method for MSW management for a region.
A LARGE‐SCALE SIMULATION MODEL OF A MAP PRODUCTION SYSTEM
Authors: Revesman Mark E. , Gambhir Sukhdeep S.
Published: November 2014

This paper describes a hybrid discrete‐event/continuous model of a Map Production System, encompassing all phases of the production process. The model was developed using an interactive prototyping methodology with Extend™, a commercially available simulation package for the Apple Macintosh. The modeling approach used a central hierarchical “Simulation Manager,” which distributed events and data to the appropriate submodels. The output of the model was validated using historical data and found to be generalizable for future system modernization. This modeling approach provides system engineers with information to aid in prediction and optimized design of future systems.
ProSimTM: A KNOWLEDGE‐BASED SIMULATION MODEL DESIGN TOOL
Authors: Benjamin Perakath C. , Mayer Richard J.
Published: November 2014

This paper summarizes the goals, results, and benefits of a research project focused on developing intelligent software support for simulation model design1. Our research approach uses qualitative reasoning techniques to provide intelligent support for designing simulation models starting from structured system descriptions. The main product of this project is PROSIMTM, a knowledge‐based simulation model design tool that automatically generates WITNESSTM simulation models from IDEF3‐based process models2. The functionality provided by PROSIMTM is briefly described, and the potential benefits of the technology are outlined. An inventory system example is described to demonstrate the utility of the PROSIMTM technology described in the paper. We expect the results of this research to have a significant impact on the use of simulation technology for systems analysis and design.
IMPROVING THE COMPUTER WORKSTATION INTERFACE FOR ENGINEERING AND A PROPOSAL FOR USER INTERFACE STANDARDIZATION
Authors: Sachs Humberto W.
Published: November 2014

Today's product development environment needs to use many Computer Aided Engineering (CAE) tools to reduce programs technical risk and reduce product life‐cycle‐cost. The tools should also provide a basis for implementation of non‐recurring cost effective engineering processes and practices. Twenty years of research across many companies compiled data that indicates current state‐of‐the‐art CAE is not cost effective. These findings have been validated by recent financial reports. While there are many causes for such burden, the user interlace with the CAE system was determined to be a significant productivity issue. This obstacle to productivity can be removed by the implementation of a User Interface Standardization (UIS).

Improvements to achieve a common user interface has fallen short of optimum results because of the lack of system engineering practices in the standardization methodology. This paper proposes the UIS and establishes the needed methodology for its success.