bluuebunny/crossref_metadata_2025 huggingface dataset:
CONDUCTING A SYSTEMS ENGINEERING PROCESS ASSESSMENT
Authors: Mackey William
Published: November 2014

One way to improve the practice of systems engineering is to baseline the best practices and assess organizations against the baseline. Computer Sciences Corporation (CSC) is one of the nation's leaders in both developing baseline models and conducting assessments. During March through June 1994, the CSC Central Engineering Board (CEB) initiated the first systems engineering process self assessment (SEPA) using the National Council on Systems Engineering (NCOSE) Capability Assessment Working Group (CAWG) Systems Engineering Capability Assessment Model (SECAM). This paper summarizes those SEPA activities.
3.4.2 An Early Start for Integrated Spiral Development
Authors: Terry William S.
Published: November 2014

The application of integrated system/product development approaches and the use of spiral development models is becoming more prevalent in practice today. However, generally these methods are applied to programs as the program is starting development. Loral Federal Systems‐Owego (LFS‐O) recently used the concept of Integrated System Development/Integrated Product Development (ISD/IPD) along with a spiral development approach starting in initial idea exploration and through the proposal phase of a major new program. This experience is described along with a summary of lessons learned from early in the development.
4.4.3 Development of an Approach to Alternative System Solution Capture and Evaluation
Authors: Baxter Michael J.
Published: November 2014

This document details the research and development effort entitled “Development of an Approach to Alternative System Solution Capture and Evaluation.” This research discribes the development of a computer aided systems engineering capability for integrated development and evaluation of alternative system concepts. The described elements of this procedure include the following: development and capture of system evaluation measures, requirements and performance models; utility function development; architectural element modeling, system alternative assembly; and alternative system evaluation and selection. The document consists of a number of sections which address the problem, the value of solving the problem, the approach, a background survey, a developmental prototype, the preliminary results, and process and software illustration figures.
4.5.3 ETHICS IN SYSTEMS ENGINEERING
Authors: Kasser Joe
Published: November 2014

Systems are growing larger and larger and are taking over the running of many facets of modern society, such as Automated Traffic Handling Systems, Intelligent Vehicle Highway Systems, and Air Traffic Control Systems. A failure in one of these systems can cause economic damage, as well as loss of life. An engineer who discovers such a problem or even the probability of such a problem faces an ethical dilemma concerning what to about the discovery. This paper discusses personal and corporate ethics in systems engineering; the ethical dilemma faced by a systems engineer and the possible consequences of abiding by one's principles.
4.5.4 Essential Systems Engineering: A Lifecycle Process
Authors: Azzolini John
Published: November 2014

A systems engineering process is presented which supports the project lifecycle with improved rigor. The incorporation of specific structure and discipline results in a process which is requirements based, with added value in the planning, execution and reporting of design, implementation, integration, verification, and validation activities.

The concept of the validation basis is introduced and discussed. It is a key concept in the development of this process.
5.5.1 Applying Systems Tools & Methods to the Development of a Quality Program Implementing Quality Standards such as ISO 9000
Authors: Bodi Robert F.
Published: November 2014

Tools and methods developed for the field of systems engineering can be used to provide effective support to a wide‐ranging set of manufacturing needs. One area that shows great potential application for these systems tools and methods is the development of a quality system to meet the requirements of quality standards such as ISO 9000. This paper briefly explores this potential application.
7.5.3 “If I Could Do That, Then I Could…” System Engineering in a Research and Development Environment ‐ As Illustrated by the Evolution of the Space Shuttle Tiles
Authors: Forsberg Kevin
Published: November 2014

Researchers and Project Managers in a research and development environment often resist the notion that a structured process such as System Engineering can be applied to their environment. While it is impossible to invent to a schedule, it is certainly possible and necessary to use good engineering practices in the research and development process. System Engineering is one of these necessary engineering disciplines.

To illustrate the use of System Engineering in its applications in R&D, this paper will follow the development of a new ceramic material from its origin in the research laboratories in the early 1960s through its application to the Space Shuttle thermal protection studies in the late 1960s and its production scale‐up as the Space Shuttle tile material in the 1970s, to its ultimate potential in the current exploratory studies as a matrix for repair of human bone in the 1990s.

The author was closely associated with the material throughout much of its history. In the mid‐ to late 1960s the author was deputy director of the Materials and Structures Laboratory (where the material was invented by Robert Beasley) in the Lockheed Palo Alto, California, Research Facility. The author later became program manager of the Space Shuttle Tile Program.
Designing Budget‐Tolerant Systems
Authors: Denzler David W. R. , Kasser Joe
Published: November 2014

In today's systems engineering environment, budgets are decreasing while needs are remaining constant or even increasing. This paper discusses the concept of designing systems so that in the event of budget reductions, there is no need to cancel the project and restart the development of a system with lower capability. Instead, the least‐important requirements are easily eliminated.
BARRIERS TO BRINGING SYSTEM ENGINEERING INTO THE COMMERCIAL MARKET PLACE
Authors: LaBudde Edward V.
Published: November 2014

It is evident to many that the commercial market place could benefit from a “systems discipline.” Thus far it has been difficult for system engineering to make much penetration into areas that clearly could use this discipline. This is not to say that the task is impossible. Scott Jackson (Smith, 1996) and Pat Hale (Hale, 1996) have reported success in bringing the systems discipline to commercial companies. Their experience makes it clear that some precautions must be exercised if success is to be ensured.

LaBudde Systems, Inc. specializes in installing “a systems approach” in the commercial arena. We have successfully installed our Accelerated Product Developmentsm System (APDsm) into 13 commercial companies in the last three years. During this time we have made adjustments to our marketing and sales approaches in order to accommodate the perceptions and sensitivities of the commercial markets. In order to get to first base in the sales cycle, one must approach the commercial market segment with the right sales story. Our experience may be helpful to others attempting to penetrate this market.
A Total Systems Approach To Automotive Development
Authors: Hatley Derek , Rushton Gary
Published: November 2014

We present an approach to automotive development that treats the automobile as a single system, interacting with its operating environment, data and signal sources, the occupants, energy sources, and service centers. The requirements and architecture of the vehicle are developed separately, but concurrently, interactively, and with their interrelationships clearly identified within a common framework. Every aspect of the system is developed within this same framework, including such things as maintenance procedures. The highest system levels include no assumptions about the vehicle technology, allowing, for example, gasoline, electric, solar, or any other energy source, and manual or mechanized subsystems.
SYSTEMS ENGINEERING FOR COMMERCIAL AIRCRAFT
Authors: Jackson Scott
Published: November 2014

The application of systems engineering (SE) to commercial aircraft presents a set of requirements and processes unique to the commercial aircraft industry. SE can be applied to new, derivative, and change‐based aircraft design. The concept of an aircraft system extends beyond the aircraft itself. The hierarchy of the aircraft architecture is embedded in present‐day processes. Aircraft life‐cycle functions follow the classical life‐cycle functions. The aircraft‐level functions can be flowed to aircraft and subsystem level functions and requirements. Requirements which receive more attention than others include performance, safety, cost, reliability, and weight, not necessarily in that order. Economic requirements include both market‐driven and particular customer requirements. Certification guidelines for the aircraft, including its software, incorporate SE principles. Strong SE management is required for the successful development of commercial aircraft. This paper is based on the author's book Systems Engineering for Commercial Aircraft (1997).
System Engineering Online Documentation
Authors: Etcheverry Candace , Eldridge Miriam , Bajema Bruce , Dytko Thomas
Published: November 2014

This paper describes how we successfully applied the principles of systems engineering to the process of creating online documentation for an existing commercial software product. Using systems engineering principles, coupled with a commercial systems engineering tool, we were able to reduce the time to market for our online documentation system from five years to sixteen months, which translates into a 50% saving in personnel and a 60% saving in product delivery schedule.
A Framework for a Decision Support System (DSS) Architecture for Air Traffic Management
Authors: Sinha Agam N. , Willingham Frank L.
Published: November 2014

The current Air Traffic Management (ATM) system in the United States supports a wide variety of users in providing a safe and efficient air transportation system. The ATM system has to be responsive to the changing needs of its users. One of the challenges in the ATM system evolution is to design the evolution of a Decision Support System (DSS)/automation architecture. This paper proposes a framework and a common language for understanding the different aspects of a DSS architecture.
The Air Bag System: What Went Wrong with the Systems Engineering?
Authors: Buede Dennis M.
Published: November 2014

The air bag restraint system in automobiles has received a great deal of attention since the summer of 1996. The purpose of this paper is to review the successes and failures of the air bag since its introduction in 1988 and to relate these successes and failures to the requirements that led to the current air bag design. Finally suggestions are made about how the requirements development process can be improved for all systems, considering the obvious and not‐so‐obvious mistakes that were made during the development of the air bag.
Rebaselining of the Plutonium Residue Elimination Project at Rocky Flats Environmental Technology Site
Authors: Sailor W. C. , Catlett D. S. , Burns T. P. , Conner W. , Moody D. C. , Muscatello A. C. , Norris T. L. , Parker M. A. , D'Amico E. , Rivera M. , Sendelweck V.
Published: November 2014

Systems Engineering and Value Engineering principles were put into practice in rebaselining the Pu Residue Stabilization and Elimination Project at the Rocky Flats Environmental Technology Site. Tradeoff studies were conducted as to how to best rebaseline the system under the new Safeguards Termination Limits (STLs) issued by the Department of Energy. Through the use of a computerized database, the means by which Stakeholder values and other high‐level requirements have been included in the tradeoff studies were documented.
DEVELOPMENT OF THE ENVIRONMENTAL MANAGEMENT INTEGRATED BASELINE AT THE IDAHO NATIONAL ENGINEERING LABORATORY USING SYSTEMS ENGINEERING
Authors: Murphy James A. , Caliva Robert M. , Wixson James R.
Published: November 2014

The Idaho National Engineering Laboratory (INEL) is one of many Department of Energy (DOE) national laboratories that has been performing environmental cleanup and stabilization, which was accelerated upon the end of the cold war. In fact, the INEL currently receives two‐thirds of its scope to perform these functions. However, the cleanup is a highly interactive system that creates an opportunity for systems engineering methodology to be employed. At the INEL, a group called EM (Environmental Management) Integration has been given this charter along with a small core of systems engineers. This paper will discuss the progress to date of converting the INEL legacy system into one that uses the systems engineering discipline as the method to ensure that external requirements are met.
Department of Energy Environmental Management Complex‐Wide Integration Using System Engineering
Authors: Fairbourn Paul
Published: November 2014

A systems engineering approach was successfully used to recommend changes to environmental management activities across the DOE Complex. A team of technical experts and systems engineers developed alternatives that could save tax payers billions of dollars if the barriers are removed to allow complete implementation. The alternatives are technically‐based and defensible, and are being worked through the stakeholder review process. The integration process and implementing project structure are both discussed.
Lessons Learned from Use of a Computer‐based Requirements Management Tool in the Project Configuration Control Board Environment
Authors: Meilich Abe
Published: November 2014

This paper presents some lessons learned in Requirements Management (RM) utilizing a computer‐based tool in conjunction with a Configuration Management process and with the oversight of a Project Configuration Control Board. Computer‐based RM tools should help facilitate systems engineering on large complex system development projects. But, sometimes, the drive to either develop tools or purchase Commercial Off‐the‐Shelf (COTS) RM tools early in the life of a project is often pursued without a thorough understanding of the process, environment, or culture in which the tools will be used. The individual or group responsible for tool procurement is often not the same as those that will have to manage the tool as part of an overall systems engineering process. Those who are responsible for procuring the tool sometimes are overly attracted to the flexibility and number of features the tool provides (i.e., typical vendor selection criteria checklists), only to find that the flexibility adds more problems and choices than the requirements analyst was prepared for. Under this scenario, the final tool choice features must be severely constrained, to manage and report the requirements and their dependencies to the Project Configuration Control Board. While taken from experience, the specifics of the actual projects used as a model for this paper and the computer‐based tool vendor names have been deliberately removed to better focus on the issues addressed in the paper.
The Simulation Based Acquisition Vision and the Role of an Integrated Engineering Tools Environment
Authors: Karangelen Nicholas E.
Published: November 2014

The dramatic reductions required in complex system acquisition life cycle cost and development schedule cannot be achieved via incremental systems engineering process and method improvements. A bold innovative shift is required which includes a focused employment of emerging simulation and modeling technologies to the systems engineering challenge. This paper describes an emerging systems acquisition paradigm, referred to as Simulation Based Acquisition, which is embodied by three principal components: (1) an advanced SBA systems engineering environment which employs formal methods and automation to support efficient design synthesis, capture and assessment as well as other complex system lifecycle activities; (2) a refined system acquisition process which takes advantage of SBA engineering environment capabilities; and (3) an evolved culture where enterprise wide cooperation is the rule and individual technical contributions and innovations are encouraged and efficiently managed.
Lessons Learned Applying Model‐Based System Engineering Methods to a Strategic Planning Activity
Authors: Baker Loyd
Published: November 2014

A recent strategic planning effort at the Savannah River Nuclear Site successfully utilized a model‐based system engineering approach to develop a plan for the disposition of stored nuclear waste material. In the beginning, many team members, as well as program management, did not understand how system engineering methods and tools could possibly help the team accomplish its objectives. The perception was that a system engineering approach was overkill – all that was needed were domain experts, a facilitator, and a scheduling tool. Introduction of the model‐based approach improved the team's ability to communicate their ideas and intentions. This paper presents the lessons learned during the effort to produce a well received strategic plan, including the supporting information data package that justified our conclusions.
No Matter What The Application, It Is Still Systems Engineering
Authors: Bahill A. Terry , Gissing Bruce
Published: November 2014

Humans (individually, on teams, and in organizations) can follow simple processes to increase their probability of success. Many people, both technical and non‐technical, have recently described processes for doing diverse things like designing a system, reengineering a company, teaching a course and solving personal problems. This paper illuminates the amazing similarities in these processes.
A User‐Centered System Development Model Based on Facilitator‐Assisted Requirements Elicitation (FARE)
Authors: Gambhir S. S. Gulu , Scotti Richard S.
Published: November 2014

There are numerous examples of system developments which have not been entirely successful based on cost, schedule, and technical criteria. Many development problems have been traced to poor system requirements. This research introduces a user‐centered system development model which begins with user participation during the requirements elicitation phase. The Facilitator Assisted Requirements Elicitation (FARE) method is introduced, in which a technical facilitator acts as a neutral third party who bases discussion of requirements on concepts of operations (CONOPS) and use‐cases. User involvement continues throughout the system development lifecycle via participation in Integrated Product Teams, design reviews, and human‐machine interface reviews. End‐users take ownership of the System Requirements Specification (SRS); the system design; validation, transition, and training plans; and ultimately the delivered system.
A Process for Requirements and Architecture Definition
Authors: Martin James N.
Published: November 2014

A Requirements and Architecture Definition Subprocess has been defined that provides an orderly and iterative definition of the problem and development of the solution. This subprocess consists of 5 activities comprising 40 tasks. The subprocess is described in the context of a larger Systems Engineering Process that has developed over the last six years and was designated by AT&T as a Best Current Practice.
Implementation of the Systems Engineering Discipline
Authors: Bruno Michelle E. , Mar Brian W.
Published: November 2014

The functions or roles of the systems engineering discipline are well documented in literature. However, the opinions vary with many overlaps and there is no focus on implementation of systems engineering based on the size of the company. This paper summarizes the results of a survey conducted across companies of various sizes that perform systems engineering to determine which systems engineering life‐cycle activities are supported, who performs these activities, and how does a company decide who should perform these activities. The survey data indicates large companies implement systems engineering differently than medium and small companies.
An Approach to Successful Integrated Product and Process Development (IPPD)
Authors: Thornton John A. , Luczak Michael A.
Published: November 2014

Today's Department of Defense (DoD) acquisition environment challenges program managers with seeking new, innovative and efficient ways to develop their systems. One of the ways in which the government and contractor program managers for the Navy's Advanced Deployable System (ADS) Program have responded to this DoD challenge is through implementation of an Integrated Product and Process Development (IPPD) methodology for their system development. This article describes the program's successful IPPD implementation for development of its Underwater Segment and offers recommendations to other program managers interested in embarking on such a path.
A Spreadsheet Implementation of QFD and Systems Engineering Approaches to Support Concurrent Engineering
Authors: Doukas Louis , Pollock Graham , Jeyaratnam Canestus
Published: November 2014

For an organisation to sustain its competitive advantage, there is a strong need for timely adjustment to ever rapidly changing customer demands. To achieve this goal, known customer needs must be prioritised and transformed into organised down stream design requirements. This paper describes how a spreadsheet framework has been developed which incorporates a modified Quality Function Deployment (QFD) and Systems Engineering Process (SEP) for product development and planning. The application of Analytic Hierarchy Process (AHP) is used as a means of ranking top level user requirements. The methodology provides a pro‐active means and a strong link between quantified user requirements that are prioritised and product design/performance requirements, by assuring that down‐stream design requirements are incorporated into trade‐off decisions. An example is also presented to test and evaluate the spreadsheet approach in heavy engineering projects.
Thoughts About Life Cycle Phases
Authors: Lake Jerome G.
Published: November 2014

The question “What are the life cycle phases that a system must go through?” has been one of interest and confusion to many folks involved with engineering systems. The problem is that a set of life cycle phases is established from the perspective of a singular domain without consideration or knowledge of other domain life cycles. Thus, when a discussion is held with someone outside a particular domain, the life cycle phases are found to differ significantly by number, name, and purpose. These differences create confusion, misunderstanding, and often conflict.

This paper is designed to put some order to the various domains of thought about life cycles. Four kinds of life cycles are discussed: Acquisition, Project, Development, and Product. The key life cycle of these four is Development. How this life cycle relates to the other three is a focus of this paper.

The Development Life Cycle is akin to the spiral model and incremental builds approach used for software development.

The premise is that life cycle phases are defined and implemented to manage the inherent risks involved with engineering a system.
Concurrent Engineering and more… A Systematic Approach to Successful Product Development
Authors: Wenzel Stefan , Bauch Thomas , Fricke Ernst , Negele Herbert
Published: November 2014

This paper describes the CE+ Model, a comprehensive and systemic approach to assess and change product development processes successfully. First, a general description of new product development processes is given (Cycle Model). The second part introduces the “hierarchical” CE+ Model which is derived from the uppermost goal of a company: economic success. Focusing the economic success four general levers are explained how to reach this target. An elementary part of the CE+Model are 17 Essentials (WHATs), which describe what has to be done in order to generate an effective development system. Depending on the characteristics of the industries and companies analyzed, specific Practices (HOWs) are related to the Essentials in the House of CE+. Finally, all methods and tools are used by human beings. They need a solid and sound environment (soil) where they are able to develop their strengths.
No Innovation Process without Changes, but…
Authors: Fricke Ernst , Gebhard Bernd , Negele Herbert , Igenbergs Eduard
Published: November 2014

There is no innovation process and no engineering of successful systems without any change, but it is absolutely necessary to understand and have a good grip on changes. Based on an analysis in German industry, five strategies are proposed to overcome problems and risks of changes in product development.
Systems Engineering Education Demystification: The Saga of Developing a University SE Certificate Program
Authors: Brown Charles F. , Kfoury Nicholas F. , Flowers Shirlee J. , Korman Howard F.
Published: November 2014

The Inland Empire Chapter (IEC) sponsored and created a Systems Engineering Certificate Program with the University of California, Riverside (UCR). The program outline and action plan was developed by the IEC and accepted by UCR College of Engineering and UCR Extension. The paper describes how the certificate program started in 1994 and the first series of courses was developed. The lessons learned from that Series I, ending March 1996, resulted in improvements made to the Series II courses which began September 1996. We will share our experiences and focus on the key areas that require the most attention in the hope that it will help other chapters when a systems engineering certificate program is developed in cooperation with a local educational institution.
A Guide to CASE Tools in Support of System Architecting
Authors: Hyer Scott A. , Kauffman Donald C. , Hatley Derek J. , Parker Thomas A. , Chasse John L.
Published: November 2014

The rapid pace recently established by the Computer Aided Systems Engineering (CASE) tools industry provides opportunities to constantly look ahead and challenge tools to do more in support of complex systems development. This situation also forces CASE tools users to cry out for guidance in defining tool capabilities and selecting from among the growing list of candidates. The INCOSE Systems Architecture Working Group (SAWG) has produced version 1.0 of “A Guide To CASE Tools in Support of System Architecting” (dated May 1997) to address such a need for guidance. The guide is written to give the CASE tool novice a starting point and to give the more experienced CASE tool user some considerations for advanced capabilities.
TOOLS INTEGRATION INTEREST GROUP REPORT: SCENARIOS FOR A CONCEPT OF OPERATIONS FOR AN INTEGRATED SYSTEMS ENGINEERING ENVIRONMENT, Part II
Authors: Schier James , Nallon John , Arnold Eileen
Published: November 2014

The Tools Integration and Interoperability Working Group (TIWG) is developing a Concept of Operations and a Specification for an Integrated Systems Engineering Environment (ISEE). Last year's TIWG Report (Reference 1) focused on the development of an initial set of scenarios leading toward the development of the full Concepts of Operations. This paper collects the next set of three scenarios which have been developed. The scenarios presented address: (1) the process of defining an organizational systems engineering process; (2) the set of processes associated with administration of an ISEE as part of an organization's information infrastructure; and (3) the process of assessing an organization's systems engineering capability. Based on these process oriented scenarios, we discuss the requirements which an integrated tool suite will have to meet to provide user's with the desired capabilities. The discussion also addresses the technological needs and feasibility of developing an ISEE.
Principles Working Group 97–98 Summary Report
Authors: Alessi Sam , McCumber William H.
Published: November 2014

This paper reports the activities and current state of the INCOSE working group on principles. The working group approaches systems engineering principles as a trichotomy – three distinct views of principles: mathematical, philosophical and pragmatic. Working sessions at the 1997 INCOSE symposium developed an outline for a text, “Logical and Mathematical Principles of Systems Engineering,” a framework for foundation philosophy and two sets of pragmatic principles, all of which are reported in this paper.
2.1.2 Contingency and Disaster Recovery Engineering: A Discipline within A Discipline
Authors: Botten LeRoy H. , Riggs Donald A.
Published: November 2014

The adaptation of accepted systems engineering methods to contingency and disaster recovery (C&DR) engineering applications is described. A recent C&DR planning project is briefly discussed, and lessons learned in applying the C&DR engineering method are provided. The structure of a decision support tool (implemented as a Microsoft Excel spreadsheet) used to aid in assessment of and response to C&DR emergencies is described.
3.2.1 Task Teams – Meeting The Organizational Challenges of Systems Engineering
Authors: Shylanski Jennifer C. , Wilke Carol E.
Published: November 2014

The 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

The 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

Can 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

The 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

Good 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

The 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

Systems 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

The 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

Established 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

The 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

This 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

The 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

:

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

Companies 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

As 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

System 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.