bluuebunny/crossref_metadata_2025_split huggingface dataset:
6.3.2 TESTING KNOWLEDGE OF SYSTEMS ENGINEERING PROCESS FUNDAMENTALS
Authors: Bellagamba Laurence 
Published: November 2014

AbstractA method is presented for people to determine if they know the fundamentals of the systems engineering process as applied to aerospace systems. After considering optional methods, a series of proctored tests with post test identification of incorrect answers was selected as the optimal approach. A systems engineering approach was taken to develop the test. The test was verified to meet performance, functional and design requirements using focus groups consisting of an aerospace firm's management and staff. Sample questions are provided.
1.1.3 ENVIRONMENTAL IMPACT DESIGN TOOL FOR SYSTEMS ENGINEERS
Authors: Frisbee Eric 
Published: November 2014

AbstractWith new environmental laws and regulations come new requirements and responsibilities. It is the systems engineer's responsibility to establish and monitor these requirements. But the eruption of ever changing environmental laws has escalated the systems engineer's requirement duties to an almost unmanageable level. To help meet the multitudes of environmental specifications, the systems engineer has a need for environmental compliance tools.
1.1.4 SYSTEMS ENGINEERING OF RENEWALS AND EXTENSIONS IN MASS TRANSIT RAILWAYS
Authors: Williams John , Allan Jeff 
Published: November 2014

AbstractRapid Transit Railways have become complex and expensive safety critical systems involving a considerable range of technologies and a wide choice of implementations. Many of the older systems have now reached a stage at which renewals and frequently, further extensions have become essential in order to cope with the increasingly difficult commercial and legislative environment of the present and future. These tasks are far from trivial and as a consequence, an approach based on systems engineering has been evolved to deal with them. This paper covers aspects of a code of practice which has been developed in the context of the major renewal and extension projects.
2.1.3 DEVELOPMENT OF OPERATING CONCEPTS
Authors: Thompson T.E. (Ted) 
Published: November 2014

AbstractSystems engineering techniques, especially requirements collection and management, are well described in the literature but appropriate methods of determining and documenting operator requirements are not as widely discussed. The Canadian Airspace System (CAS) is a large, complex systems engineering task. This paper discusses the methods used by Transport Canada to elicit, review, discuss and document the operating concepts for the future evolution of the CAS.
7.1.1 Social Systems Engineering and Architecture
Authors: Maier Mark W. 
Published: November 2014

AbstractAlthough the methods of systems engineering were developed to build complex technological systems, many practitioners feel they can be equally well applied to social and political processes and problems. This desire to rationalize social systems, and to do so through the application of the principles of science and engineering, is not new. It clearly dates back at least 200 years to the French Revolution. Unfortunately, the history of these attempts is mixed. This paper surveys the engineering approach to human systems and examines general criticisms of such an approach. We propose a classification of problem types and suggest variants of the system approach that may be better suited to particular classes of social system problem. Many of these issues, and the resulting classifications, can be seen in the long history of civil architecture and its attempts to deal with the interaction of engineering and society.
7.1.2 A SYSTEMS ENGINEERING APPROACH TO LIFE EXTENSION PLANNING FOR THE STRATEGIC PETROLEUM RESERVE
Authors: Pikul Robert (Bob) , Schultz Daniel A. , Culbert Jon A. 
Published: November 2014

ABSTRACTThis paper addresses life extension planning for the Department of Energy's (DOE) Strategic Petroleum Reserve (SPR), the mission of which is to store crude oil and to maintain a 95 percent system availability to allow drawdown of the oil in the event of a national emergency. A key element of the planning approach is identification of those system components whose improvement from their current state of availability would have the greatest impact on increasing overall system availability. The approach includes: a) conducting a reliability centered life extension (RCLEX) planning analysis utilizing a failure modes and effects analysis (FMEA), availability modeling, and component aging in order to determine priorities for critical system components; b) identifying and assessing alternative methods for improving critical system components and analyzing their effectiveness using life‐cycle cost methods; and c) preparing an integrated Comprehensive Life Extension Plan (CLEP), showing projects, schedules, and budgets.
3.2.2 Aspects of System Engineering Environments
Authors: Tronstad Yngvar D. 
Published: November 2014

AbstractThe macro problem facing organizations that acquire and produce modern systems are complexity in both the process and the product dimensions. It is the scale of this multidimensional problem which requires a system approach which combines both the engineering and the management aspects as well as the process. However for all but the most trivial cases this need to be supported by an automated System Engineering Environment (SEE) where the life cycle processes, the product and the organizational elements with people using methods and tools to perform their tasks are linked together in a collaborative manner.
4.2.2 System Engineering and KBS Development
Authors: Sandral Jean‐Luc 
Published: November 2014

AbstractThis paper discusses connection principles for methods and tools, between traditional Requirement Engineering and Problem Domain Analysis, in order to be able to manage every kind of requirement: functional, non functional, knowledge and rule based. This paper is based on studies carried out at NCS‐FRANCE, part of the Naval Combat Systems Group (NCS) of Thomson‐CSF.Thomson‐CSF has set up a common policy for System Engineering at the corporate level, which includes a method called MIST (“M&#142;thode d'Ing&#142;nierie Syst&#143;me Thomson‐CSF”), based on Draft MIL‐STD‐499B standard, and a tool which is RDD‐100TM. The additional work performed at Thomson‐CSF/NCS focuses on the analysis of operational requirements in the area of C3I systems. A Problem Domain Analysis approach appears to provide a promising solution. The method used by Thomson‐CSF/NCS in this area is KADS (Knowledge Analysis and Design Support), which is a conceptual modeling language stemming from European research projects. The tool which implements this method is OpenKADSTM.
7.2.3 VIRTUAL PROTOTYPING: RESULTS ILLUSTRATE UTILITY IN DEVELOPING WEAPON SYSTEM REQUIREMENTS
Authors: Brown Phillip J. , Lavender Jack K. 
Published: November 2014

ABSTRACTThe Department of Defense, in response to excruciating budget pressures, recurring system integration problems, and the continuing remarkable growth in computer capability and high resolution graphics, has seized on the promise of advanced distributed simulation technologies (including virtual prototyping) as a means for improving efficiency in developing integrated defense system products. From the perspective of a weapon systems contractor, benefits of virtual prototyping include: (a) tighter coupling of operational requirements with developer implementation concepts, (b) introduction of a rapidly reconfigurable tool for refining system requirements early in the systems development cycle, and (c) a means for improving the visibility of the system requirements analysis process. Examples of requirements changes identified as a result of virtual prototyping activity are from Loral Vought Systems experience with virtual prototyping on the Line‐of‐Sight AntiTank (LOSAT) weapon system program. Also included is a vision of where these tools, in the context of a weapon system, can be used to abet the system requirements development process.
1.3.1 An Integrated Problem Reporting and Resolution System
Authors: Tilton Catherine J. 
Published: November 2014

AbstractWith few exceptions, all system development projects have a need to identify, track, and resolve issues, action items, problems and changes. Within an organization, many different mechanisms may be used to perform this function across projects. Indeed, on a single project, a number of different systems may be in place to track the various types of ‘problems‘. This paper describes an integrated approach for establishing a project problem reporting and resolution system which handles all categories of items, from identification through closure. This approach, which includes a process description and automation support, was successfully implemented and used on a $30M project over a two year period with the described results.
1.3.2 LIFE CYCLE RISK MANAGEMENT
Authors: Brekka Lawrence T. , Vlay George J. 
Published: November 2014

AbstractRisk management using available engineering, schedule, and cost data provides a means of integrating the process into the mainstream responsibilities of systems engineering, program control, and program management. The type and detail of data used in different phases of the program life cycle differ, and different tools are needed to assess the potential impacts of the risks. Careful selection of the data available at each phase of the life cycle insures that the integrated, real‐data approach is easily implemented and effective.
3.3.4 The Benefits of the Systems Engineering Process in Concurrent Engineering
Authors: Matty George E. 
Published: November 2014

AbstractWith the appearance of concurrent engineering (CE), Systems Engineers play a more vital role in the development process. No longer are Systems Engineers dealing with individuals from functional areas who do not have a vested interest in the program. Although the Systems Engineer interfaced with the functional organizational staff in the past, now he is interfacing with functional organizational team members who all have the same goal. Because of the cooperation and team work, more realistic program costs and schedules can be obtained because most of the individuals involved in the concurrent engineering team are stakeholders in the development of the project. The Systems Engineer as a team member is required to determine program plans, assess risks and program costs with input from all the concurrent engineering team membership.A CE team considers the product, customer, and all the processes associated with it simultaneously; in essences a ‘systematic’ approach. The difference now is that everybody affected in an organization understands the same thing at the same time. The CE team members voice issues from a variety of different perspectives based upon their background and experience. Marketing may be concerned with how the customer may perceive a particular design concept, design engineers are concerned with designing the product to meet performance capabilities, and manufacturing engineers are concerned with the producibility of the system. CE provides the forum for all these issues to be addressed. Systems engineers no longer have the sole responsibility of addressing the product issues. Now, the responsibility of the Systems Engineer is more of a facilitator. With the proper tools and guidelines in Military Standard 499B, a Systems Engineer can help the team to better determine program requirements from the customer to, ultimately, the product.
4.3.1 INDUSTRY PERCEPTIONS OF REQUIREMENTS SPECIFICATIONS FOR COMPLEX MILITARY SYSTEMS
Authors: Gabb Andrew P. , Henderson Derek E. 
Published: November 2014

AbstractThis paper presents the results of a survey of Australian companies involved in the development and supply of complex computer based systems for the Royal Australian Navy. The objective of the survey was to gain feedback from industry of the quality of Navy's requirements specifications leading to recommendations for improvements in specification practices. The paper summarises the industry perceptions and comments on the results.
4.3.2 SAFER ‐ A Case Study The Lessons Learned on a Flight Test Project
Authors: Hess Clifford W. , Hooks Ivy 
Published: November 2014

AbstractThe SAFER ‐ Simplified Aid for EVA Rescue – Flight Test Project captured the hearts and minds of the country in September when astronauts flew untethered for the first time in a decade. The SAFER, a small backpack worn by an EVA astronaut was designed and built as an in‐house project by the NASA‐Johnson Space Center.Following the very successful flight of SAFER a study was made to document the lessons learned from the participants. This paper focuses on the system engineering aspects of the project across its life‐cycle.
4.3.3 How Do I Keep Track of This Study
Authors: Bedocs Jozsef 
Published: November 2014

AbstractThe commercialization of Systems Engineering is causing us to rethink some of the more labor intensive activities such as requirements management. Commercial engineers are already involved in cost, testing, program planning, procurement, configuration management and other activities. Relatively few organizations exist only to perform selective functions (such as CAD/CAM, computer support, facilities, etc.) Requirements management is likely to become the responsibility of the every day design engineer and therefore cannot be a massive effort.For requirements management to be used by commercial engineers, the effort must be perceived to have added value and be an overall time saver. Most engineers are extremely busy supporting currently mandated processes. More work is a hindrance, a more efficient way of doing the work already required is most helpful.We have been fairly successful in making a sound case for doing requirements management. However, the way requirements management is traditionally done is just an incredible amount of work. To become commercially palatable, requirements management must become more efficient in use of time and resources to be effectively used by design engineers.
5.1.3 Management and Re‐Use of the Artifacts from the System Engineering Process
Authors: Tronstad Yngvar D. 
Published: November 2014

AbstractThis paper describes the results of a forward and reverse engineering effort, with the focus on how to plan, mange and control all the different artifacts (models, documents, issues and decision) in anticipation of their re‐use during the development of subsequent versions over the life cycle. A Model Configuration Management Facility (MCMF: a prototype extension to RDD(TM)) was used to keep versions of these artifacts separated and organized into consistent and complete system configurations. Change control procedures were used to ensure the integrity of these system configurations.
5.3.1 APPLICATION OF ANSI STANDARD TO SPACE STATION RESOURCES
Authors: Taylor Irene , Bassler Julie 
Published: November 2014

AbstractThe Space Station environment has created unique scenarios for allocation and management of critical technical resources. Integration of resource requirements of a Prime contractor with Product Groups and associated subcontractors, in concert with international agreements with European Space Agency, National Space Development Agency of Japan, Canadian Space Agency, and the Russian Space Agency (RSA) is complicated by the fact that several components of the Space Station design are carry‐overs from a previous version of the program. Costs associated with alterations of those design components prohibit normal resource allocation processes which would assign and control resource utilization from the embryo stage of a program. In order to methodically allocate the technical resources, while assuring adequate margin for nominal programmatic growth in demand against those resources, Space Station has developed resource reserve philosophies based upon the application of American National Standards Institute (ANSI) approved methodology. The methodology was sponsored by the American Institute of Aeronautics and Astronautics (AIAA) and was published in a paper titled “Guide for Estimating and Budgeting Weight and Power Contingencies for Spacecraft Systems.” The application procedures were adjusted for application to the diverse types of resources being controlled for the Space Station.
5.3.2 SPECIFICATION DEVELOPMENT WITHIN THE IPT: A CASE STUDY OF THE F‐22
Authors: Meyer Albert 
Published: November 2014

AbstractThe goal of this paper is to demonstrate how the concurrent engineering method embodied in the Integrated Product Team (IPT) philosophy has impacted the specification development process on the F‐22 program. The article will examine the concurrent engineering process as it applies strictly to specification development.[1] In particular, the success of the specification development process will be attributed to three main factors: (1) maintaining flexibility in the Preliminary Allocated Baseline (PAB) until Functional Configuration Audit (FCA), (2) Increasing communication and trust between the contractor and the customer by making the customer an integral member of the IPT, and (3) taking advantage of the automated technology to redesign the specification development process. While the F‐22 program is a multi‐corporate endeavor, these principles can be applied to any development effort.]
5.3.3 Requirements Mythology: Shattering Myths About Requirements and the Management Thereof
Authors: Martin James N. 
Published: November 2014

AbstractRequirements cannot be managed well if the true nature of these requirements is not understood. There are some misperceptions about requirements that lead to improper application of requirements practices and principles.For example, some believe that “all requirements must be verifiable” before they can be declared to be “good” requirements. If this were true, then we would have to ignore the “non‐good” requirements we often get from our customer and potential system users who are not usually literate enough in “requirements engineering” to give us verifiable requirements per se. In fact, the customer usually can tell you if a requirement is met “when they see it.” A more accurate statement is that all specified requirements must be verifiable. This is not an insignificant distinction.This example illustrates the danger of believing in certain “requirements myths”. Like all mythology, each particular myth has a degree of truth in it. It is this element of truth that encourages the persistence of these myths. It would be better to apply these truths to a better understanding of requirements management principles and application of its practices.This paper describes a dozen common myths about requirements. Each myth is examined to determine the true and the false elements and to identify the traps to avoid when performing requirements engineering tasks.
6.1.4 Methods and tools for the interactions between systems and software
Authors: Stevens Richard , McCaskill George A. 
Published: November 2014

AbstractSoftware forms an important part of almost every modern systems project. However, the development of software‐intensive systems (SIS) is plagued with well‐publicized problems. Often these problems are managerial rather than technical. Part of the problem is the interaction between systems and their software sub‐projects. This process is understood only weakly, partly because the systems and software development processes are themselves are poorly understood, often inconsistent and weakly followed in practice. This paper analyses the interactions between systems and software engineers during the course of a SIS project. These define the functions for interacting between requirements management and CASE tools. An interface between a requirements management tool (DOORS) and a CASE tool (Teamwork) has be produced according to these principles.
CONCURRENT ENGINEERING WITH INTEGRITY: THE ENVIRONMENTAL SOLUTION FOR THE 90'S
Authors: Zittel Randy C. 
Published: November 2014

AbstractAmerica has become more environmentally conscious while cheering the military for its service and professionalism. Base closures and overseas withdrawal are now bringing to light the environmental consequences of our ability to parry so many military threats. To some, it appears that a new environmental process for the 21st century is needed, but in fact the existing process provides a highly effective framework when used properly with integrity.The DoD Instruction 5000 series requirements provide an excellent state of the art system for handling the environmental problems of yesterday, and preventing such problems tomorrow. Although the DODI 5000 series is 4 years old, the mandatory procedures have evolved, as in the use of the systems engineering (SE) management practices which now incorporates the use of integrated product and process development teams and concurrent engineering. And with the continuous evolution of the SE process, DOD's reliance on systems engineering has also evolved in the right direction.
OPERATIONS: THE MISSING THIRD OF SYSTEMS ENGINEERING
Authors: Denzler David W. R. , Vallone Antonio 
Published: November 2014

AbstractSince its inception, NASA's Goddard Space Flight Center (GSFC) has developed extensive ground systems to support unmanned scientific spacecraft. These systems are composed of large numbers of subsystems operated by a multitude of individuals. This complexity has demonstrated the need for documentation to aid the developers in addition to the traditional systems requirement documents (SRDs). GSFC has increased focus on operations by requiring that most new system development activities use both an SRD and a mission operations concept document (MOCD).This use of operations documentation accompanying requirements has provided the clarification of the reasons for and context of the requirements.The methodology of operations engineering used to develop operational models is closely related to the processes used in business process engineering. A discussion of the characteristics of business process reengineering shows this strong relationship between the newly developed reengineering methodology and the operations engineering subdiscipline of systems engineering.
2.2.1 SYSTEMS ENGINEERING AND THE BOTTOM LINE
Authors: Jackson Scott 
Published: November 2014

AbstractSystems Engineering (SE) cannot be viewed in isolation, but rather as a subset of, first, the Integrated Product Development process, and secondly, as part of a commercial or non‐governmental corporation's business enterprise. This paper discusses four ways in which the SE process directly affects the financial operations of a company and how SE can be employed to improve the financial performance. First, the design‐to‐cost process can be brought to bear to maintain predictable and affordable products. Second, the normal business cycle in commercial industries, presents cost and schedule constraints which can be treated by considering them as a natural part of the SE process. Next, the improved product quality through the SE process results in many direct and indirect financial benefits through reduced development cost, reduced unit cost, reduced operating cost, and improved sales. Finally, the SE process provides consistent methodology for obtaining superior products from suppliers, and hence enhances the business prospects for the product. Examples in this paper focus on the commercial aircraft industry, although the principles found in it may be applied to many industries.
LESSONS LEARNED AS A SE‐CMM AUTHOR
Authors: Kuhn Dorothy A. 
Published: November 2014

AbstractDeveloping a maturity model, as I had occasion to do with the Industrial Collaboration's Systems Engineering Capability Maturity Model (SE‐CMM), was a lengthy journey over partially charted waters. Some lessons our authoring and management team learned are described, a brief history of the effort is given, along with a short description of SE‐CMM and its future plans.