bluuebunny/crossref_metadata_2025_split huggingface dataset:
3.2.1 Task Teams – Meeting The Organizational Challenges of Systems Engineering
Authors: Shylanski Jennifer C. , Wilke Carol E. 
Published: November 2014

ABSTRACTThe organization required to engineer complex systems is complicated by many factors. The organization must ensure that the overall system requirements are understood, analyzed and allocated. It must also provide focus on the subsystems to which system requirements have been allocated to ensure cost effective design and implementation of the requirements. And, the organization must integrate the subsystems to form the system and ensure that system requirements are met. Often, organizations must also produce and support multiple configurations of the system simultaneously.To meet this organizational challenge, Boeing's F/A‐18 Avionic Weapon Systems team has established a formal organization of Integrated Product Teams focused on the avionic subsystems on the aircraft. Networked across that IPT organization, are project‐oriented teams, known as task teams, that are focused on a particular system configuration update of those subsystems that must work together to provide coherent, integrated capabilities to the F/A‐18 aircrew.The task teams face many challenges that come from operating outside the formal organization. Boeing's F/A‐18 Avionic Weapon Systems team determined, through an analysis of task team performance, that for the task teams to operate effectively, the teams and particularly the task team leaders must be well trained; there must be coordinated support from the formal organization; and the tools that support cost and schedule performance must provide insight into task team performance.This paper addresses the steps to help the task teams meet these challenges. For the current configuration update, the F/A‐18 Avionic Weapon Systems team developed a training program, a management support system, and PC‐based management tools to help the task teams operate more effectively. The training, management support, and tools are being utilized in the current configuration update. A description of these changes is provided, and results from a survey of the task teams and task team leaders that was recently performed to assess the effectiveness of these changes is discussed.
3.2.3 Implementation of a Government ‐ Contractor Leadership Team in an Integrated Product Team (IPT) Environment
Authors: Thornton John A. , Luczak Michael A. , Hutcheson Robert T. , Castor Ray A. 
Published: November 2014

ABSTRACTThe government and contractor program managers for the Navy's Advanced Deployable System (ADS) have implemented an Integrated Product and Process Development (IPPD) methodology for development of their system's Underwater Segment. A key element in the success of this methodology has been the effectiveness of the leadership provided by the government‐contractor Systems Engineering and Management Team (SEMT). The team's leadership approach is focused in three areas: leadership techniques, engineering and business management activities, and technical direction efforts. The team's effectiveness has been enhanced through an investment of resources to establish and implement a clear and executable program baseline, a disciplined development approach, effective communications, which are facilitated in large part by team collocation, and responsive decision‐making and course corrections. This paper describes the methods of the SEMT and how it contributed to the success of the Underwater Segment Integrated Product Team (IPT).
3.2.4 Social Networks of Systems Engineers in Integrated Product Development
Authors: Smyre Melford E. , Dooley Kevin 
Published: November 2014

AbstractCan an organization with low process skills reasonably expect to hire contract engineers to increase process skills within a project? This paper examines one large product development project where personnel strength was increased by the addition of contract systems engineers. The study focuses on the social networks formed by contract systems engineers with each other and with staff engineers, looking for clusters which correspond to product development teams and the system integration team. Using social network analyses, this paper examines propositions that team boundaries will be distinguishable through roles or positions of individuals, and that system integration teams will occupy more centralized positions than contributing product development teams.Although results of this study are mixed, social network analysis is emerging as a tool with potential to measure quality of team participation and predict team performance – key process areas for managing organizational maturity.
4.2.1 A Model For Planning And Managing Concurrent, Multi‐Disciplinary System Development
Authors: Hatley Derek J. 
Published: November 2014

ABSTRACTThe increasing size and complexity of modern systems makes concurrent, multi‐disciplinary development increasingly important. Integrated project teams (ipt) [1] and development (ipd) are now well‐understood and well‐recognized ingredients of system development. Less well understood are the implications of such development approaches on project planning and management. This paper introduces a straightforward technique for modeling development, allowing the flexibility necessary to accommodate concurrency and ipts. The technique, which readily can be implemented with a standard spreadsheet program, serves as a tool for management, project leaders, and developmeant teams alike.
1.3.2 Requirements Development & Management Using Models
Authors: Baker Loyd , Christian Ann 
Published: November 2014

ABSTRACTGood program managers understand that a high pay‐off in cost savings and schedule reduction can be attained by early analysis of their system requirements. Programs employing a traditional text‐oriented requirements development approach experience significant numbers of misinterpretations and late‐detected design errors resulting in increased costs, schedule slips, reduced capability, and canceled programs. This paper discusses how a well defined model‐based approach to the development of requirements can eliminate or greatly reduce the incorporation of incorrect assumptions into system requirements.
2.4.2 Cost As an Independent Variable (CAIV) on the Joint Helmet Mounted Cueing System (JHMCS) Program
Authors: Kembitzky Bert 
Published: November 2014

ABSTRACTThe Cost As an Independent Variable (CAIV) process is the next evolutionary step in the Department of Defense's ongoing effort to continue to modernize, operate and support its forces within a shrinking Defense budget. The Joint Helmet Mounted Cueing System (JHMCS) program was one of the first development programs to implement the CAIV process. The objective undertaken by the JHMCS program was to establish in the integrated product teams the process to control the design factors affecting the production and life cycle costs. This was accomplished through the detailed breakdown of the costs, the open communication between Boeing and the U.S. Government and the active participation of the U.S. Government in reducing all cost areas. The incentive for Boeing to have a successful CAIV process on the JHMCS program was through its profit determination (award fee), but the criticality for the U.S. Government came through its program's budget projections. Program affordability goals must be realized in order to ensure the program's future. This paper presents some of the lessons from the JHMCS program. More importantly, it describes the significance and affordability related results of key actions and decisions made during the formulation and execution of the JHMCS program.
3.4.4 Systems Engineering to Sydney
Authors: Kasser Joseph E. , Weiskopf Marsha V. 
Published: November 2014

ABSTRACTSystems engineering a worldwide multi‐site real‐time tele‐conference using volunteers is a challenge worthy of any organization. This paper is an introduction to the proposed project. It outlines the goals and approaches to be taken over a four‐year period to develop the requirements, prototype communications techniques, and minimize the risks in developing the conference. The paper also describes a number of other benefits of the project to the International Council on Systems Engineering (INCOSE).
5.6.2 Engineering of Complex Systems: Understanding the Art Side
Authors: Newbern David , Nolte Jerry 
Published: November 2014

ABSTRACTThe engineering of complex systems is both science and art. Although the cause of many difficulties in development of complex systems is the “art” side, this side is frequently ignored since it can't be conveniently described and quantified. We recommend a conscious recognition of the appropriate role of the art, or judgment, side of systems engineering, especially in the key processes of abstraction and decomposition. Detailed documentation of rationale is a powerful mechanism for introducing repeatability into “art” side design and development decisions.
5.6.4 Applying an Activity Based Counting Technique to System Design Efforts
Authors: Shupp Jeffrey K. , Martin Lockheed 
Published: November 2014

ABSTRACTEstablished costing techniques applied to software based systems provide a reasonably accurate technique in predicting the implementation costs of projects. For projects with a firm design baseline, driven by well defined requirements, the systems engineering cost is typically based on a “tax” of x% of the total development hours.When the software system being proposed is large, or when the customer's needs are not well articulated in the specifications, a simple multiplier against the total development effort is insufficient to predict the systems engineering effort. Even predictions based comparing design artifacts from one project to another cannot be successfully defended during cost negotiations.This paper proposes a technique that assesses the scope of Systems Engineering work by examining the executing features of the design and their associated difficulty. Examining how the system runs early in the development cycle helps the project better understand where the unknowns and uncertainties are in the design, providing insight into technical risk management, as well as providing more defensible costs.
7.7. Integrated Control Process for the Development of the Mined Geologic Disposal System
Authors: Daniel Russell B. , Harbert Kevin R. , Calloway David E. 
Published: November 2014

ABSTRACTThe U. S. Department of Energy (DOE) Order 430.1, Life Cycle Asset Management begins to focus DOE Programs and Projects on the total system life‐cycle instead of looking at project execution or operation as individual components. As DOE begins to implement this order, the DOE Management and Operating contractors must develop a process to control not only the contract baseline but the overall life‐cycle baseline. This paper presents an integrated process that is currently being developed on the Yucca Mountain Project for DOE. The process integrates the current contract/project baseline management process with the management control process for design and the configuration management change control process.
7.14. Product Development That Reflects the Voice of the Customer: A Team Case Study
Authors: Wilson Donald G. , Kranz Joseph J. , Coffey Denis M. 
Published: November 2014

ABSTRACTThis paper describes an Integrated Product Team's (IPT) experience applying Concept Engineering™ (CE™) which is as a five‐stage, disciplined process that helps define the “fuzzy front end” of a program. The case study emphasizes the team's application of the CE methodology through the first two stages in order to first develop a shared understanding of the customer's environment and then convert that understanding into customer requirements. The team's experience with the last three stages of the process is only briefly described. The resource metrics compiled during the project validate that the CE process can improve the productivity of engineering teams when a clear understanding of the customer's environment of use is obtained.
7.17. System Engineering for Faster, Cheaper, Better
Authors: Forsberg Kevin , Mooz Harold 
Published: November 2014

ABSTRACTThe continued thrust to increase competitiveness and shorten time‐to‐market in industry, and the more recent effort to “reinvent” the procurement process in government, has created sustained pressure to adopt new paradigms for aerospace projects. The banner of “faster, cheaper, better” places emphasis on use of Commercial Off‐The‐Shelf (COTS) systems and components, Non‐Development Items (NDI) (previously developed products that are not commercially available), and advanced, lightweight components.This paper reviews two successful and two unsuccessful projects, examining the processes they followed compared to the “traditional” approach used from the 1960s through the 1990s. We use a model of the technical aspects of the project cycle (the “Vee”) to highlight the essence of the processes followed, as well as the risks to be managed. The results illustrate that, without a valid and comprehensive process, “faster and cheaper” does not automatically lead to “better,” and, conversely, that an intelligently tailored process can greatly improve the success rate for “faster, cheaper, better” projects.
7.19. The World Economic System
Authors: Caver Troy V. 
Published: November 2014

Abstract:The world social environment is made up of many systems. One of those is the economic system. When each nation was younger, with less ability to transport between nations, they could fashion their economies to accommodate the needs of the internal national population without much regard or risk from the economies of other nations. Now as we move into another century, the world is much more interrelated. The economy of each nation is influenced by the economies of others, especially trading partners. When the economy of any nation is not sound or is built on a weak foundation, it puts a larger segment of the world population at risk. This paper provides a means of examining the world and national economies from the perspective of a system. As a system, each economy is subject to systems engineering and optimization just as any other system. It is up to the economist to identify the elements that are most critical to the success of the world economic system and to provide a methodology by which each nation can evaluate its economic structure and to develop an economic system which will optimize the domestic economy and enhance the economy of the larger world system. As an optimized system, the economies of the nations will consume fewer resources and achieve greater gain from the resources consumed, thus permitting the populations to achieve higher standards of living.
Collaborative Engineering Environments – Two Examples of Process Improvement
Authors: Spee J.B.R.M. , Laan D.J. , Bijwaard D.J.A. 
Published: November 2014

ABSTRACTCompanies are recognising that innovative processes are determining factors in competitiveness. Two examples from projects in aircraft development describe the introduction of collaborative engineering environments as a way to improve engineering processes.A multi‐disciplinary simulation environment integrates models from all disciplines involved in a common functional structure. Quick configuration for specific design problems and powerful feedback / visualisation capabilities enable engineering teams to concentrate on the integrated behaviour of the design.An engineering process management system allows engineering teams to work concurrently in tasks, following a defined flow of activities, applying tools on a shared database. Automated management of workspaces including data consistency enables engineering teams to concentrate on the design activities.The huge amount of experience in companies must be transformed for effective application in engineering processes. Compatible concepts, notations and implementation platforms make tangible knowledge like models and algorithms accessible. Computer‐based design management make knowledge on engineering processes and methods explicit.
5.1.2 Automating Configuration Control in a Requirements Database: Balancing Data Protection with Productivity
Authors: Panek John J. 
Published: November 2014

AbstractAs part of a standard system engineering process, more programs are realizing the benefits of using a database to manage their requirements. This may be accomplished using a tool that can be tailored to automate a configuration control process. It is important that the configuration control process is well defined and balanced. The process must be well defined for it to be successfully automated to control and change the requirements. The process must also be balanced in the sense that it must protect the requirements baseline without hindering the engineer's productivity in the continued development of the requirements set.This paper will examine the implementation of a configuration control process that was automated within a requirements database. The focus will be on examining how the process enables protection of baselined requirements while simultaneously enabling the engineers to continue with the requirements development. As a justification for the implementation, the benefits of automating the process will be identified.
6.1.3 System Faults and their Diagnosis in Complex Systems
Authors: Moorhouse T J 
Published: November 2014

AbstractSystem fault diagnosis and remedy have long been the twin “Cinderellas” of the system design procedure. The failure modes of systems have been the subject of little study, and knock‐on effects have been largely ignored. By far the most common method of system diagnosis is “Wait until it breaks then call in the engineer“. The advent of systems of systems, with complex external interfaces, means that this state of inactivity can not continue.An initial, ad hoc study of current and impending causes of systems failure has been performed. The existing techniques have been found largely inadequate in the light of the expected expansion of system capability.The techniques of Virtual Reality (VR) have been explored to see if they can be harnessed to give an adequate solution to the perceived shortfall in diagnostic techniques. They have been found to be suitable, and provide a solid platform for the short to medium term of systems diagnosis.
4.2.3 From Process Aggregation to Process Integration
Authors: Browning Tyson R. 
Published: November 2014

Abstract1A process is a kind of system. As such, it derives its added value from the relationships among its elements (e.g., activities). For a group of activities to be truly integrated (versus merely aggregated), their interfaces must be well defined. In engineering processes, these interfaces usually indicate a flow of information. Engineering processes are extremely complex because of the large number of interfaces, as many types of information flow to many destinations. While the general structure of a process architecture is specified top‐down, the description of what actually flows must be extracted from the existing, implicit way work really gets done. Detailed descriptions of various processes must then be integrated into a process model that will have some prescriptive value. (The systems engineering “V” model applies to processes as well as to products.) This paper applies a powerful technique for representing and analyzing complex processes, the design structure matrix (DSM). The paper shows how to use the DSM to account for both internal and external inputs and outputs, providing the basis for process “puzzle pieces” that can be assembled to form large, integrated processes where value can flow.
7.2.2 Implementing A Cohesive Engineering Strategy Within A Corporate Matrix Structure
Authors: Williams Marcus , Duffin John 
Published: November 2014

AbstractTo achieve competitive advantage, an engineering enterprise adopting a matrix organisation needs to make the most of its engineering capability against a background of potentially competing project objectives and business imperatives.This paper explores the pursuit of engineering strategy through the complementary perspectives of system product and engineering process. It proposes that these facets should be facilitated, co‐ordinated and controlled through the business enabler of process improvement. In support of this proposal, the paper describes a CMMI‐based framework through which to increase engineering capability across such an organisation.
8.2.2 Systems and Supportability Engineering and Integration: Best Practices for COTS‐Intensive Development
Authors: Verma Dinesh , Strandberg Tom 
Published: November 2014

AbstractThe emphasis on utilizing commercial products/technologies to develop modern complex systems and to upgrade legacy systems has yielded relatively immediate returns in terms of reduced acquisition time and cost. In this context, examples of complex systems include weapon systems, telecommunication systems, train control systems. Such systems are generally characterized as being information and knowledge intensive, distributed, multifunctional, and software intensive.Prudent introduction and application of commercial technologies and products in the design and development of C4ISR systems has reversed the traditional pattern of increasing system acquisition costs. This is reflected in Figure 1 for four functionally equivalent systems. The same reversal of trends has also been realized during the system production phase. These, relatively short term benefits (in terms of reduced development and production cost) notwithstanding, unique challenges exist relative to the on‐going evolution in available technologies, relevant missions and threat scenarios, and customer requirements and expectations. This results in the need for multiple technology refreshment and technology insertion strokes over the operational life span of these systems. COTS‐intensive C4ISR system performance, cost, and schedule risk must be viewed and analyzed from this long‐term perspective if a reduction in the total cost of system ownership is to be realized. This technical paper outlines the tailoring of the systems engineering and integration methodology to enhance its relevance to a COTS‐based acquisition paradigm through focusing on selected systems engineering sub‐processes and practices, such as open systems architecture formulation, assessment and evaluation; COTS assessment/selection; and COTS supportability engineering.
2.3.3 Designing Systems‐of‐Systems Without Getting Trapped in the Subsystem Maze
Authors: Kaffenberger Ruediger , Fischer Juergen 
Published: November 2014

AbstractTrue systems‐of‐systems are one of the toughest challenges for system engineers. They face the problem to balance complexity of design and project structure against the product's cost during its lifecycle. The main cost driver is undesired redundancy in the product and/or the development process. Here we present a method that enables system engineers to shape the architecture of the system to the needs of the users and the development organisation. First we will give our definition of a system‐of‐systems, show why they are so important, and what makes them so demanding for the system engineer. After a look at the conventional way to solve the complexity problem and a discussion of its disadvantages we will present our method. We will give an impression how we derived it, and of the variants in applying it.