bluuebunny/crossref_metadata_2025 huggingface dataset:
4.1.3 Evolving to Intelligent Systems Engineering – Findings of the IS2004 Panel –
Authors: Ring Jack
Published: November 2014

Organizers of INCOSE International Symposium 2004 posed six themes regarding the future of systems engineering. In response a panel, “Evolving to Intelligent Systems Engineering,” took a position on each theme based on ideas already being explored in the Intelligent Enterprises Working Group, IEWG. Four panelists supported, or not, 23 specific assertions regarding the six themes. During the ninety minute session vigorous interaction with the panel audience occurred. At the end, 67 attendees kindly completed a poll designed to gauge the degree of consensus with the 23 assertions. The poll results are reported and analyzed in this paper. Also included are responses to the same poll by a voluntary subset of 18 INCOSE Fellows prior to the panel session. These results highlight several possibilities regarding the future of systems engineering for consideration by SE practitioners and educators.
4.2.1 Introducing the Role of Process Architecting
Authors: Kasser Joseph E.
Published: November 2014

The work done in the development of systems is currently split between the three interdependent and apparently overlapping organisational roles of systems architecting, systems engineering, and project management, which interdependently produce a product to (the correct) specifications within the constraints of resources, budget and schedule. This paper first identifies a reason for the overlapping roles, and then attempts to resolve the difficulties in defining the roles of systems engineering, systems architecting, and project management, and the difficulty in defining the body of knowledge for systems engineering by identifying a gap in the functions performed by the three organisational roles, when viewed from the perspective of planning and implementing the development of a system, via the Roles Rectangle. A gap, which when filled by the new defined role of process architecting, has the potential to bring some order into the current chaos and resolve many if not all of the current difficulties.
5.1.2 An Approach to Developing R&D Standard Processes
Authors: Hwang Young Ha , Park Jong‐Geun
Published: November 2014

With the increase of complexity of man‐made systems and software and the enlargement of the expected quality level for R&D outcomes in today's R&D environment, it has become increasingly necessary to effectively define the R&D standard processes tailored for our organization and projects. To meet these needs, we defined the R&D standard processes based on the international standards for systems and software engineering and on our traditional work methods and applied them to our ongoing projects. We will improve our defined R&D standard processes continuously by monitoring our processes and products and checking feedback from application results. In this paper, we introduce the R&D standard processes developed by our organization, the E Research Institute in Korea, and define the requirements and approaches used for their development. We compare our defined R&D standard processes with ISO/IEC 15288 which is the international standards for systems engineering.
5.4.3 Real Requirements: How to find out what the requirements really are
Authors: Gilb Tom
Published: November 2014

This paper gives advice to help you find the requirements that really matter to your stakeholders. It focuses on stakeholder value delivery as the appropriate level, rather than the technical solutions that so many specify as their requirements. It suggests several specific methods for determining what the real requirements are. This includes some technology unique to this author, such as the Impact Estimation method.
6.1.2 Systems Engineering Degree Programs in the United States
Authors: Fabrycky Wolter J. , McCrae Elizabeth A.
Published: November 2014

The authors have observed a widespread need for general information regarding the availability and characteristics of Systems Engineering (SE) academic degree programs. This paper provides a compilation of SE degree programs in the United States, giving insight regarding academic content, administrative structure, accreditation status, and establishes a benchmark for the continued advancement of these degree programs. Description and analysis is offered by the authors to set a baseline that may be utilized to assess the future of existing and developing degree programs. The model for description and analysis utilized in this paper will be extended to the international domain in the near future.
6.2.3 Modeling ISO/IEC 15288 & Tailoring Enterprise Systems Engineering Processes for an Organization's Success
Authors: Walker Loren Mark
Published: November 2014

Tailored and integrated organizational processes are fundamental drivers for organizations to achieve efficiency and success. The organization's processes represent the means to achieve the organization's business objectives in terms of communications, functionality and systems related products. Developing the organization's processes architecture model must integrate both managerial and technical systems development efforts to produce efficient tasks and products.

This document addresses the complexity of capturing the ISO/IEC 15288 “Systems engineering‐System life cycle processes” systems management and engineering processes and their outcomes in an integrated architecture model. Several significant issues and concerns are identified that relate both to the standard's contents and to tailoring the standard to an organization's processes. Assumptions for tailoring the model are identified, in addition to topics that developers of integrated and organizational processes need to consider prior to development of their integrated and tailored processes.

The four topics addressed are:

Systems Engineering Standards and ISO/IEC 15288's unique perspective

The importance of modeling a standard and an organization's processes

The modeling of ISO/IEC 15288 including tailored perspectives

Modeling an organization's integrated processes to meet a customer's objectives
6.4.2 Capability Engineering Process within Canadian Defence: Some Engineering Issues
Authors: Couture Mario , Lizotte Michel , Dussault Geneviève , Mokhtari Marielle , Bernier François , Lam Sylvia , Lalancette Claire
Published: November 2014

Some managerial and technical problems related to the transition of the Canadian military acquisition from the Threat‐Based Planning to the Capability‐Based Planning are identified in this paper. A simplified example of military acquisition illustrates recommendations that were made in the Collaborative Capability Definition Engineering and Management (CapDEM) project to guide the work surrounding the conception of a new Capability Engineering Process. Some elements of solution for the support of such a process are also presented.
7.1.3 Accelerating the Development of Senior Systems Engineers
Authors: Davidz Heidi L. , Nightingale Deborah J. , Rhodes Donna H.
Published: November 2014

As more senior systems engineers are needed to handle the increasing complexity of contemporary systems, there is an increasing need to accelerate the development of these senior professionals. However, the process of efficiently developing a senior systems engineer is not well‐understood. To compact this problem, the skill set needed by senior systems engineers continues to broaden as system complexity increases and as system boundaries expand. In order to better understand the mechanisms that most effectively and efficiently develop these individuals, this article discusses enablers, barriers, and precursors to this development process. In addition to reviewing related literature, specific interventions currently used to accelerate systems thinking development are discussed. Findings from ongoing research related to this topic provide preliminary information about current understanding and practice. Better understanding of systems thinking development provides a foundation for educational interventions and employee development in systems thinking for engineering professionals across industry, government, and academia.
7.4.1 Methodology Selection for the Engineering of Defence Systems
Authors: Vencel Les , Cook Stephen
Published: November 2014

The nature of problems encountered in the system engineering domain has over the past thirty years grown in complexity. The integration of technology with human activity systems to produce complex capabilities has required a continual change in our definition and application of systems engineering. This paper examines the typology of problems associated with the development of modern complex systems and combines the ideas of system engineering and cognitive problem solving to propose a set of attributes that may be used to characterise system engineering problems. It is proposed that this set of attributes is sufficient to enable the selection of methods, tools and techniques necessary to solve the problem.
8.2.1 Agile Specification Quality Control: Shifting emphasis from cleanup to sampling defects
Authors: Gilb Tom
Published: November 2014

Traditional Inspection is often uneconomic and ties up valuable staff resources. Shifting the emphasis from cleanup (that is, from identifying defects and then removing them), to merely sampling the defect level of specifications, produces significant benefits. It enables the quality level of specifications to be determined more rapidly. Consequently, the QC can be carried out more frequently. Systems and software engineers rapidly learn, through SQC feedback, to take standards seriously, which in turn reduces defect injection. Further, by analyzing where/how the defects occur continuous process improvement can be supported.
8.2.3 International Standards for System Integration
Authors: Martin Richard A.
Published: November 2014

Missing from the repertoire of mechanisms for systems integration presented at past INCOSE symposia are the International Standards for process component integration being developed in the context of industrial automation. To improve the efficiency of beneficially constructed interactions between systems and system components, the international community is adopting a wide range of standards through formal development and review processes. For this presentation, the focus is on the standards efforts for industrial automation conducted by ISO TC184 SC5 working groups. The work products range from shop floor communication structures through enterprise level system concept management – all with a process centric orientation. Of particular interest are the enablers of interoperable supply chain components and support for systems throughout their lifetime.
8.3.3 Renovate WBS Planning with Technology Roadmap for New Product Development
Authors: Lee Hei‐Kuang , Liu Chih‐Ming , Lee Meng‐Hua
Published: November 2014

The new product development (NPD) project has been considered a challenging task in the management practice. In project planning, the Work Breakdown Structure (WBS) is one of the fundamental tools, but the terms “product” and “activity” are frequently confused and results in inefficiency in the support of project management tasks. By clarifying the nature of project planning and execution, an integrated method for WBS planning has been developed in this research. It includes the product‐oriented WBS (P‐WBS), the activity‐oriented WBS (A‐WBS), and the contract‐out WBS (C‐WBS). The technology roadmap is used to transform the P‐WBS into the A‐WBS. Using the proposed integrated WBS planning method as the basis, an integrated methodology for new product development has been given to align strategic management to project management. Finally, the successful application of this methodology to develop a project for the re‐host of a full scope training simulator of a nuclear power plant in Taiwan is illustrated.
8.4.2 Exploring Engineering Governance
Authors: Nendick J.V. , Callan K. , Ng G.A.L. , Siemieniuch C.E. , Sinclair M.A.
Published: November 2014

Over recent years a lot of effort has gone into improving corporate governance within public companies. But what about engineering governance? Companies which are involved in complex, systems engineering‐based projects face a lot of risk. This risk should be minimised as much as possible through the implementation of Good Engineering Governance (GEG). Improved engineering governance would assure the numerous stakeholders involved in large projects that controls are in place to effectively manage the engineering function.

The GEG project at Loughborough University is looking at the stages needed to introduce an engineering governance framework into a large defence systems integration business. This paper looks at the initial findings of the GEG project and what is involved in the next stage.
9.2.3 Successful Implementation and Application of Continuous Risk Management to Complex Systems Development in the Automotive Industry
Authors: Negele Herbert , Pfletschinger Thilo , Wenzel Stefan , Getto Gerhard
Published: November 2014

Currently, more than 90% of the innovation in the automobile industry is driven by new ideas in the electric and electronic sector (Frischkorn 2004). Due to the increased complexity of the electrics/electronics (E/E) system, car breakdowns today are more often not mechanical in nature, but are likely due to a defect in the electrics/electronics system (ADAC 2004). As a result the development of a more reliable automobile E/E system is a major concern for car manufacturers around the world in order to produce innovative and reliable cars and remain competitive.

Besides sound requirements engineering and effective project management, the key to dealing with the increasing complexity of E/E system development is to identify potential system problems throughout the development process and respond with appropriate actions to mitigate potential adverse impacts and thus achieve the project objectives. This issue can be accomplished by implementing a continuous risk management (RSKM) approach focused on the development of the E/E system.

This paper illustrates a practical, proven approach applied to new product development at the BMW Group. The approach enables proactive risk identification and mitigation to obtain more transparency in the development of the complex E/E system of an automobile.
9.4.2 Improving process evolution using ideas from the Venture Capital industry
Authors: Rogers Derek , Beukman Piet
Published: November 2014

This paper provides a coherent framework for process evolution and new product introduction. The approach overcomes common limitations with process evolution including:

Opportunity driven; rather than directly linked or driven by an organisation's strategic goals.

Non‐standard methods within an organisation, for example, in the approach used for calculating return on investment if such explicit calculation exists.

Neglect of resource availability, skill needs and organisational change management.

Neglect of the timeliness or window of opportunity.
10.1.3 Agile SYSTEMS ENGINEERING versus AGILE SYSTEMS engineering
Authors: Haberfellner Reinhard , de Weck Olivier
Published: November 2014

This paper explores recent developments in agile systems engineering. We draw a distinction between agility in the systems engineering process versus agility in the resulting system itself. In the first case the emphasis is on carefully exploring the space of design alternatives and to delay the freeze point as long as possible as new information becomes available during product development. In the second case we are interested in systems that can respond to changed requirements after initial fielding of the system. We provide a list of known and emerging methods in both domains and explore a number of illustrative examples such as the case of the Iridium satellite constellation or recent developments in the automobile industry.
11.3.2 Development of an Object‐Oriented Multi‐Leg Route Choice Model on Transportation Network Simulation
Authors: Yang Eun‐Suk , Garcia Elena , Mavris Dimitri N.
Published: November 2014

Due to its complexity, modeling of the transportation network involves a very large number of node choices for completion of a travel route. Conventional route choice models approach this problem from the mathematical point of view. In this paper, a System‐of‐Systems approach is used to model a Personal Air Vehicle (PAV) network, and a traveler's route choice model in a multi‐leg travel scenario is proposed. Both the network and route choice model are designed using Object‐Oriented (OO) programming techniques eliminating the usage of complicated matrix calculations as in many other mathematical models. The practical limitations of the shortest path problem are not usually in the solution itself, but in the application of it in the simulation environment. This paper also covers some of the most important concepts of the Traveling Salesman Problem (TSP) and an idea to tackle TSP is suggested with a modified model.
11.4.2 Managing Priorities: A Key to Systematic Decision‐Making
Authors: Gilb Tom , Maier Mark W.
Published: November 2014

A central concern of systems engineering is selecting the most preferred alternatives for implementation from among competing options. The selection process is sometimes called tradeoff analysis, and is often built on the methods of decision analysis and utility theory. The process can be loosely divided into two parts, a first part in which one determines the relative priority of various requirements, and a second part, a design selection phase, in which alternatives are compared, and the preferred alternatives chosen.

This paper discusses the means of determining the priority order for implementing system changes. It also outlines the implications on the selection process of evolutionary systems development.
1.1.2 Defining the “Trade Space” for CAIV Optimization Using a Cost Model Derived from Linear Regression of NASA Project Data
Authors: Krupa Joseph F. , Componation Paul J.
Published: November 2014

In 1995, Dr. Paul Kaminski, then Defense Undersecretary for Defense for Acquisition and Technology, established the principles of CAIV—“Cost as an Independent Variable”—to take advantage of aerospace's experience using Target Cost to battle the escalating cost of defense systems in a time of declining procurement and development dollars.

One of the key tenets of CAIV is to limit Key Performance Parameters (KPP) to the critical few, to establish thresholds and desired levels of performance, and to trade off performance, cost and schedule. This trade arena is called the “Trade Space”. Although a number of authors have proposed methodologies for performance, cost and schedule trades, a clear process has not emerged. One difficulty that emerged from study was how to use existing cost estimating systems to perform “Trade Space” optimizations. This paper presents the use of a cost model derived from log linear regression analysis of data from eighty‐six NASA projects, the Analytic Hierarchy process, and non‐linear optimization to show how CAIV “Trade Space” can be developed from cost data.
1.3.2 Context‐Based Measurement of Requirements Instability
Authors: Biddle Mark , Moritz Shelly
Published: November 2014

Requirements instability has always been and continues to be one of the more significant challenges for system development programs. Historical results across industry show that programs struggle and often fail to achieve stable and mature requirements baselines, and the impact of requirements instability on program cost, schedule and technical baselines is significant. This paper looks at some of the factors that affect requirements instability, and it outlines an approach for measuring requirements instability that takes contextual influences into account in order to provide insight as to why the requirements on a given program are unstable.
2.2.3 Directed Energy Weapon System Architecture to Meet Network Centric Operations Requirements
Authors: Marbach Phyllis R.
Published: November 2014

Network Centric Operational Warfare (NCOW), the Global Information Grid (GIG), a typical Directed Energy (DE) Weapon System, and elements within a Battlespace that the DE Weapon would communicate with, are concepts introduced in this paper. NCOW requirements are described as applied to a weapon system, a DE weapon in this application, but the requirements and the solution proposed could be applied to other systems as well. This paper introduces a general DE Weapon and an architecture that meets the attributes described in the DoD Net‐Centric Data Strategy.
2.3.2 Towards a Work Breakdown Structure for Net Centric System of Systems Engineering and Management
Authors: Wang Gan , Valerdi Ricardo , Lane Jo Ann , Boehm Barry
Published: November 2014

As the system engineering industry sees an increasing focus on the lifecycle development, acquisition, and sustainment of net‐centric Systems of Systems (SoS) and Family of Systems (FoS), organizations find the need to evolve current processes and tools to better handle the increased scope, scale, and complexity of these efforts. One such tool, the Work Breakdown Structure (WBS) is important in planning and execution of program activities as requirements and goals of the program evolve. This paper provides an overview of the limitations of current WBSs with respect to SoS efforts and presents a proposed WBS structure that more adequately reflects the evolving processes and cross‐organizational complexities.
2.3.3 Uniting Three Families of Risk Management–Complexity of Implementation × 3
Authors: Holzer Thomas H.
Published: November 2014

This case study presents how a government agency overcame difficult challenges to establish a solid foundation for the management of its three families of risk‐ program, enterprise, and joint enterprise. Establishing an efficient and effective risk management process in a single development program is very challenging‐ culture resistance to change and unwillingness to share information viewed as negative prevail. There is additional complexity convincing people to adopt a process that is part of the bigger organization and sharing information regarding their ability to achieve program objectives. Now convince two different organizations to share information with each other. The outcomes show how the process can be scaled, adapted, integrated and adopted across the complex systems and diverse organizations and enable program teams to identify, assess, and mitigate complex risks. For an organization aspiring to establish an internal or joint enterprise risk management program, these findings are a head start.
2.4.1 Evolution of a Standard EIA‐632 From 1994 to 2006
Authors: (Rich) Harwell R.M.
Published: November 2014

Process standards represent the best practices used by an industry or discipline. Most process standards are usually created by volunteer teams operating under the auspices of an authorized standards development body such as the Government Electronic and Information Technology Association (GEIA). This paper examines the evolution of one standard from its inception in 1994 to its current revision activities, noting the factors influencing scope, content, and structure. It also provides an insight into the latest decisions affecting the current revision efforts.
4.1.1 Ten Design Principles: Some implications for multidimensional quantification of design impacts on requirements
Authors: Gilb Tom
Published: November 2014

Designs have multiple impacts on requirements, and can only be fully understood in terms of their impact on requirements. In other words, the contributions of designs towards the set of performance and resource requirements must be considered, when evaluating designs, in addition to their contributions to the function requirements.

This paper sets out ten principles, and outlines their various implications for design. These are basic ideas about designs, which we should explicitly acknowledge, teach and use in practice. I would be surprised to find any serious disagreement about these principles, but I would be surprised to find serious conscious practice and teaching of them today!
4.1.3 i‐pub – Status, Insights and Visions
Authors: Herzog Erik , Pandikow Asmus
Published: November 2014

The i‐pub project aims at making INCOSE Symposia and other conference publications available on‐line on the INCOSE intranet. In this paper we present the status of the project, insights gained from analysing the material collected and our visions for future extensions of the i‐pub system.
4.4.1 Fine‐grained Method and Tool Integration for better Automotive Software
Authors: Altheide Frank , Buhr Kerstin , Doerr Heiko
Published: November 2014

In the automotive field, software development methods and tools are used to cope with the high complexity of automotive software development. However, problems occur with the tracing of information, the assessment and monitoring of the development status, late and thus expensive changes, etc, which lead to increasing development costs and time as well as quality deficits. Our experience with recent projects have shown that the key to solving these problems lies in providing proper answers to the following questions: (1) How can development methods be assembled? (2) How can the use of a variety of development methods be supported by an appropriate tool?

To answer these questions, we introduce a tool integration approach that is strongly based on the integration of development methods.

The contribution of this paper is (a) a method integration approach that considers finegrained method objects and their specific structure in addition to the usually considered artifacts, (b) an approach to tool integration that overcomes the deficits of heterogeneous tool environments and utilizes the results of the methodical understanding.
5.1.3 Systems Engineering an INCOSE Chapter
Authors: Davies Paul
Published: November 2014

In this paper, the setup of INCOSE UK is used as a case study ‘infrastructure project’, an example of a ‘peopled system’. To begin with, the ad‐hoc developments in the typical formation stages of an INCOSE chapter are shown, and this is used to point out the relative immaturity of the processes from a systems engineering point of view. Then we look at how we made the Chapter more self‐sustaining, by a strategic overhaul of the ‘system’ using SE principles:

Business Case drivers

Stakeholder Identification

Stakeholder needs (requirements) analysis

Architecting the Organisation

Allocation of system requirements to organisational responsibilities

Decision analysis of likely return on effort invested

Validation and Verification via Event Q&A surveys

Comparisons are drawn with IEEE1220, EIA632 and CMMI. Finally, the Metrics that we have recently started to examine are presented, as evidence of increasing maturity of the process.
5.2.1 A National Approach to Systems Integration Skills Base Development in Australia
Authors: Cook S. C. , Sciacca L. , Bates B. , Nandagopal D. , Allison S. , Shackleton D. , Yates A.
Published: November 2014

Large‐scale systems, such as rail networks, air traffic control systems, and networked defence systems are vital to national well‐being. However, modern systems are becoming increasingly complex in nature and their development is proving problematical both in Australia and around the World. The paper opens by describing the nature of the problem and the best‐practice approach taken to overcome the difficulties. From here, the Australian needs for systems integration research and skills development are discussed. Finally, the paper outlines the approach taken to create a research concentration in systems integration that will form a coherent basis for a national response to the Nation's systems integration research and skill‐base capability requirements.
5.2.3 Capitalizing on Systems Engineering
Authors: Sherey Jason J.
Published: November 2014

Project managers often find it difficult to justify allocating significant resources and schedule to systems engineering tasks when “real” engineering has to be done. With ever‐decreasing time to market demands, systems engineering continually loses out to design, integration, and test. A new method of systems engineering called Pattern‐Based Systems Engineering (PBSE) enables companies to transfer portions of systems engineering costs out of project specific budgets and into company capital asset accounts. Such a change in accounting provides a series of benefits that include improved documentation and management of core corporate intellectual property, best practices, and standards as well as not having to reserve as much precious project money on tasks that need constant re‐justification to product development managers with typically constrained budgets. This paper reviews PBSE, relevant accounting standards, and how much of systems engineering can be performed as a company‐wide capital asset development program instead of as project overhead.
6.2.1 Tradeoff Studies and Cognitive Biases
Authors: Smith Eric D. , Bahill A. Terry
Published: November 2014

Tradeoff studies involving human subjective calibration and data updating are often distrusted by decision makers. A review of objectivity and subjectivity in decision making shows that Prospect Theory is a good model for actual human decision making. Similarities between the elements of tradeoff studies and the elements of experiments in cognitive science show that tradeoff studies are susceptible to human cognitive biases. Examples of relevant biases are given.
6.3.4 Impact of Embedded Software Technology on Systems Engineering
Authors: Doyle Laurence , Pennotti Michael
Published: November 2014

Systems such as aircraft and consumer electronics have included embedded computers in their designs for several decades now. In these systems, software was usually treated as a component inside a box much the same way you would treat a circuit card assembly or a power supply. Requirements would flow down to the box specification and the box specification would then flow down to the components inside the box. But recently, several trends are changing the relationship between embedded software and the system as a whole. Many embedded computer systems now use network protocols and infrastructures similar to information systems deployed on commodity hardware. Systems with embedded computers now have expectations and requirements for extensibility similar to those of information systems where methodologies for extensibility are well established. But unlike information systems, systems with embedded software often have complex non‐software elements and the software is not loosely coupled with the hardware. These systems require a synthesis of approaches.
8.1.1 Application of Systems Engineering to Industrial Supply Chains
Authors: Haskins Cecilia
Published: November 2014

This paper discusses the application of systems engineering alongside industrial ecology, systems dynamics and soft systems methodology to the study of industrial supply chains. As supply chains are ultimately a human activity, a multidisciplinary approach must include human‐centric investigation and knowledge‐sharing techniques. Systems engineering is seen as a proper foundation for defining a process for which the characteristics are unknown and for solving the problems found in cross‐organizational supply chains. Building on (Haskins 2003, 2004), Christopher Alexander's pattern language approaches are considered as a mechanism for sharing best practices. The paper closes with suggestions for the direction of further research.
8.3.1 Quantitative Analysis: Clawing your Way to the Top of the Maturity Pinnacle
Authors: Frenz Paul J. , Gurvin Anntoinette C.
Published: November 2014

Quantitative Analysis is discussed at length in text books and articles. Statistical Process Control (SPC) articles address how you apply these principles, but real‐world application is the ultimate challenge. This paper describes tools, techniques and methods used to institutionalize Quantitative analysis in a Capability Maturity Model Integration (CMMI) Level 3 environment.

General Dynamics Advanced Information Systems (GDAIS) Mission Systems achieved CMMI Level 3 rating June 30, 2004 using the CMMI‐SE/SW/IPPD/SS, V1.1, staged model.

The goal: achieve a CMMI Level 5 rating before the end of 2005.
8.3.3 Use of Architecture for Engineering Systems; The Good, The Bad, and The Ugly
Authors: Osvalds Gundars
Published: November 2014

Many programs have created architectures yet they have not been effective in producing viable results. The primary reason for this the ineffectiveness is derived from how programs are managed. While System Engineers perform engineering activities by developing artifacts; the complex relationships among engineering processes, the final products, and the creation of systems that meet customer expectations have not been well‐managed. Resolving this issue can be difficult. Even though Systems Engineering processes can provide guidance in Engineering Systems, it requires customer support and effort to make architecture actionable. To be successful in providing solutions, the Systems Engineer must apply Systems Engineering concepts to the customer's problems by educating the customer and assisting them to drive the system development effort. The author will present examples of “The Good,” “The Bad,” and “The Ugly” he has observed in U.S. Government Federal Agency and Department of Defense programs as it relates to the application of architectural engineering. Based on these tendencies, recommendations are presented to improve architectural effectiveness by urging a return to fundamental systems engineering principles and insuring that the customer is a solid stakeholder in upholding, supervising, and executing the architecture as an essential element of the new system or program.
9.1.1 Trade Study Cost Analysis Model
Authors: Casey Ed , Davis Desiree
Published: November 2014

The basic goal of a Cost‐Performance Trade Study is to find the optimum solution between several options that best balances cost, performance, risk and schedule given an agreed upon weighting.

The Trade Study Cost Analysis Model was developed to support the CAIV trade study process by providing a means for the user to quickly and easily analyze alternative options. The model computes a rough order Life Cycle Cost (LCC) estimate for each study alternative, which can be compared giving the user a powerful input to the decision making process. The output should be considered a comparative estimate that is not the bottom line number, but rather the relative cost relationships between the alternatives. This model is not a bidding tool.

The Trade Study Cost Analysis Model is primarily a predictor of Life Cycle costs and particularly Operation and Support (O&S) costs. Development and production costs are inputs to the model but not derived using the model. The Trade Study Model provides an estimate of the costs for the full life of the system/item being studied. While primarily hardware oriented, there is a software module embedded. The model has been designed to be used at the sub‐system and Lowest Repairable Unit (LRU) levels.

Life Cycle Cost (LCC) Analysis is helpful to engineers in making decisions for trade study alternatives. They (LCC Analysis) are extensive and often require a great deal of time and resources to prepare.

Included in this technical paper is the framework by which this model was created.
9.1.2 A Basic Primer in Life Cycle Cost Analysis
Authors: Redman F. Quentin , Crepea Andrew T.
Published: November 2014

Life cycle cost (LCC) has become increasingly important as systems are designed with longer useful technological lives. In addition, deferred modernization due to limited budgets is causing many aging weapon systems to be extended, thus incurring greater support costs. This paper will present an overview of the process of life cycle cost analysis (LCCA). It will address the basic concepts and applications, along with a review of methodologies and some aspects of engineering economics.

LCC is defined as the sum total of the direct, indirect, recurring, non‐recurring, and other related costs estimated to be incurred in the design, research and development (R&D), investment, operation, maintenance, and support of a system over its life cycle, i.e. its anticipated useful life span. It is normally organized into four phases: research, development, test, and evaluation (RDT&E); procurement (or acquisition), operations and support, and disposal.

Economic Decisions are often made solely on initial investment or RDT&E and procurement cost. But this is only the proverbial tip of the iceberg – a portion of the total cost of ownership. More and more customers (especially government) are emphasizing and requiring an LCC perspective. To make intelligent acquisition decisions to meet a specific need, it is necessary to look beyond acquisition. In defense systems O&S costs can encompass up to 80% of the total LCC.

LCC allows the evaluation of competing system proposals on the basis of total ownership cost and allows more effective budgeting of future funds such as O&S costs and disposal costs. A LCC perspective maximizes the benefit of applying strategies such as Cost as an Independent Variable (CAIV) and Design to Cost (DTC)

Most LCCAs require a mix of estimating methodologies. The methods may be applied individually or in combination. Analogy and parametric tend to be most useful in the early stages of product development. As program and system design stabilizes parametric estimating becomes more useful. A detailed design facilitates engineering estimate and projection of actuals.

In summary, this paper gives an overview of LCC as well as addressing many of the complexities of LCC analysis. More and more customers (especially government) are emphasizing and requiring an LCC perspective making LCC an increasingly important engineering design parameter. Total cost impact, not just initial near‐term cost, must be considered.
9.2.1 A Merlin Perspective Shines Light on Tough Issues
Authors: Carl Joseph W.
Published: November 2014

Shining light on tough issues requires leaders, including technical leaders, to commit to creation of a future that cannot reasonably be extrapolated from the place they are now standing. Fortunately, about a dozen years ago Dr. Charles Smith published an important paper (Smith, 1994) that has not received enough attention on the part of leaders responsible for solving the toughest issues of our time – affordable renewable energy, environmental health of the planet, failures of global cooperation, among others perhaps more mundane but of interest to systems engineers in their technical leadership roles. This paper reviews the advice in (Smith, 1994), and applies it to the establishment of visions for possible futures that are desired by a significant portion of the public, although the envisioned futures seem impractical to achieve. And that requires leaders to decide to identify with a future for which the way must be opened.
10.2.3 On the use of Semantic Web Technology for Requirements Satisfaction, or How do I find a good Bike?
Authors: Price David , Bodington Rob
Published: November 2014

This paper reports on an investigation into the use of Semantic Web technology in the Systems Engineering domain. In 2004 the World Wide Web Consortium standardized the Web Ontology Language (OWL). Software tools called Reasoners are available that support formal, logical analysis of concepts in a subset of OWL called OWL DL (for Description Logic). An approach to the use of this technology for the Systems Engineering task of identifying Systems that satisfy a set of Requirements is described.
11.1.2 Innovative Systems Engineering: A Creative System Development Approach
Authors: Powell Robert A. , Buede Dennis
Published: November 2014

The top‐level requirements for a system address the needs and objectives of the stakeholders and serves as a key input to the design process for a system's concept and detailed architecture. In today's systems engineering environment, the process of defining and choosing from multiple concepts is driven by top‐level (mission‐based) requirements. The use of requirements in engineering systems has gained such importance that an enormous amount of research focuses on various topics related to formulating, defining, and managing requirements. Recently, the US Department of Defense (DoD) and a few other organizations have moved to capability‐based systems engineering, which focuses on defining and trading off valuable capabilities rather than requirements.

We have not always relied on requirements to initially define systems. Beginning with goals or defined system capabilities instead of requirements has proven as effective, if not more effective in the design of systems. The use of goals has been proven to produce 1) requirements that can be implemented, 2) minimal changes to requirements throughout system design since requirements are not yet fixed, and most importantly 3) a successful system. The purpose of this paper is to explore the use of goals as a precursor to requirements in developing a DoD military system. Case study analyses, of system development projects occurring as early as the late 1940s, reveal the use of goals as preeminent in developing successful operational systems. Although these cases represent DoD systems, specifically aerospace and missile systems, the concept of the use of goals as a precursor to requirements may generalize more broadly. This paper explores one case: the development of the Sidewinder missile.
11.3.1 How Good Is A Process? Evaluating Engineering Processes' Efficiency
Authors: Gilb Tom
Published: November 2014

What is ‘best practice’ for an engineering process? How good is your current set of development, maintenance and service processes? How can we decide exactly which processes we are going to adopt in our organization, for example in a CMMI implementation?

It is the assertion of this paper that such questions are often dealt with without explicit and quantified regard to the full set of real, and well‐defined business needs, as well as often not taking into consideration the current processes and the issues of changing them. We too often carry out and change processes because we are told to, not because there is a clearly defined need to do so.
11.3.2 Using Fuzzy Decision Support to Compare Systems Modelling Tools
Authors: Rajabally Eshan , Whittle Steve
Published: November 2014

The use of modelling in systems engineering is growing both in terms of model complexity and the importance attributed to model results. In accepting a model as fit‐for‐purpose, there are numerous considerations or criteria to be fulfilled and this acceptance is complicated by a number of issues, as reviewed in this paper. Consequently, model evaluation, comparison and selection may benefit from formal Multiple Criteria Decision Support (MCDS) and this benefit is explored here through application to a systems modelling case study. Specifically, an existing MCDS technique based upon fuzzy logic is used to compare five aerodynamics tools across fifteen key criteria in a typical context. An overview of the case study is presented in this paper and several benefits of fuzzy MCDS are identified. Despite the considerable effort required from model experts to conduct such MCDS, a more rigorous means of comparing models is provided than typical ad hoc efforts.
11.3.3 Enabling Measurement‐Driven System Development by Analyzing Testing Strategy Tradeoffs
Authors: Selby Richard W.
Published: November 2014

Measurement‐driven system development focuses on using quantitative data to evaluate capabilities, benefits, progress, and tradeoffs as well as identify improvement opportunities. This paper describes a controlled study that addresses software testing effectiveness and focuses on the combination of individual testing techniques into team‐based testing strategies. This analysis is intended to enable measurement‐driven process improvement by characterizing how testing effectiveness relates to several factors, including testing strategy, software type, and developer expertise. In this study, a representative group of software development professionals applied common testing techniques to different types of software. This study compares the six possible team combinations of three testing techniques: (1) code reading by stepwise abstraction, (2) functional testing using equivalence partitioning and boundary value analysis, and (3) structural testing using 100% statement coverage criteria. Thirty‐two professional developers applied the techniques to three unit‐sized programs in a fractional factorial experimental design.

The major results of this study are the following.

The six combined testing strategies detected 17% more of the programs' faults on the average than did the three single techniques, which was a 35% improvement in fault detection.

The highest percentages of the programs' faults were detected when there was a combination of either two code readers or a code reader and a functional tester. However, a pairing of two code readers detected more faults per hour than did a pairing of a code reader and a functional tester.

The pairing of two individuals of advanced expertise resulted in the highest percentage of faults being detected.

The most cost‐effective (number of faults detected per hour) testing strategy overall was when code reading was applied by an individual. The most cost‐effective combined testing strategy was when a code reader was paired with either another code reader or a structural tester.

Both the percentage of faults detected and the fault detection cost‐effectiveness depended on the type of software being tested.

In conclusion, we outline future research directions that build on these strategies and ideas.
11.4.1 Generating Predictive Models Using Decision Trees and Neural Networks for Large‐Scale Systems Engineering
Authors: Selby Richard W.
Published: November 2014

Systems engineering must tackle the challenges of computational systems that are increasingly large‐scale and software‐intensive in terms of system size, component breadth and maturity, and development heterogeneity. This research describes and empirically evaluates techniques for generating predictive models for enabling large‐scale system development and management. We describe two types of metric‐driven decision models, decision trees and neural networks, which classify software components in large systems according to their likelihood of having user‐specified properties such as high fault‐proneness or high development effort. The metric‐driven decision models enable coarse‐grain analysis of large‐scale multi‐component heterogeneous systems, and they identify high‐payoff areas for directing the application of fine‐grain analysis techniques for fault detection or redesign. The decision models serve as metric integration mechanisms that enable the synergistic use of numerous metrics simultaneously and integrate measurements collected by development tools or infrastructure. Model generation techniques automatically generate the decision models to calibrate them to new projects and organizations.

We evaluate the predictive effectiveness of the decision models in terms of correctness, consistency, and completeness using fault and effort data from large NASA systems. Correctness is defined as the percent of components correctly identified, consistency is defined as 100% minus the percent of false positives, and completeness is defined as 100% minus the percent of false negatives. On average, the decision models had 83.44% correctness, 71.96% consistency, and 65.25% completeness in predictions of high fault and high effort software components. The network models had 89.63% correctness, 79.49% consistency, and 69.09% completeness, while the tree models had 77.25% correctness, 64.42% consistency, and 61.40% completeness. Non‐parametric ANOVA comparisons showed that the network models were statistically more accurate than the tree models (α < 0.0001).