bluuebunny/crossref_metadata_2025 huggingface dataset:
4.2.2 Family‐of‐Systems Architecture Analysis Technologies
Authors: Jain Prem , Dickerson Charles
Published: November 2014

The United States Department of Defense (DOD) transformation initiatives have the potential to significantly improve operational effectiveness and efficiencies by having the right information at the right time at the right place to make critical time‐sensitive warfare decisions. Realizing these operational benefits requires interoperability among complex families of systems. New computer‐aided analysis technologies, methods, tools and simulation environments are needed to enhance understanding of the complex behavioral relationships among thousands of entities to 1) support DOD acquisition decisions to evaluate alternative Capability‐Based‐Acquisitions (CBA) 2) evaluate relative merits of multiple concepts of operations feasible in complex scenarios. This paper describes a set of executable model abstractions and a set of analysis technologies needed to build Family‐of‐Systems architecture analysis tools and the simulation environment. It proposes a CBA system engineering process linking the tools supporting these abstractions, analysis technologies and artifacts captured according to DOD Architecture Framework (DoDAF) standard.
4.4.1 A Hybrid Requirements Capture Process
Authors: Daniels Jesse , Botta Rick , Bahill Terry
Published: November 2014

Systems engineers traditionally produce a system requirements specification containing shall‐statement requirements. However, the rapid adoption of use case modeling for capturing functional requirements in the software community has caused systems engineers to examine the utility of use case models for capturing system‐level functional requirements. A transition from traditional shall‐statement requirements to use case modeling has raised some issues and questions. This paper advocates a unified requirements engineering method in which use case modeling and traditional shall‐statement requirements are applied together to effectively express both functional and non‐functional requirements for complex, hierarchical systems. This paper also presents a practical method for extracting requirements from the use case text to produce a robust requirements specification.
4.4.2 Quantifying the Evolution of Goals in Requirements Engineering: A Study on the Quality Assurance Review Assistant Tool
Authors: Chowdhury Tropa , Chung Lawrence , Cooper Kendra
Published: November 2014

Goal‐oriented requirements engineering is becoming increasingly important, as goals help to specify requirements, provide rationales to stakeholders, and detect causes behind requirements conflicts. Measuring and understanding the manner whereby goals are understood and modeled over time can have a vital implication to many aspects of software development. Despite the importance, however, there seems to be little help available in measuring the evolution of goals. This paper presents a scheme for quantifying the evolution of goals in requirements engineering. This paper also presents a case study for this scheme using a groupware application, called the Quality Assurance Review Assistant Tool (QARAT). The data collected are analyzed in relation to several conjectures regarding the structural evolution of the goals over 11 iterations. Ultimately, studies such as these can be used to help improve cost estimation, project planning, and risk analysis activities.
5.2.2 Addressing the System of Systems Challenge
Authors: Boardman John , Wilson Mark A. , Fairbairn Allen
Published: November 2014

The top‐down systems engineering strategies that worked well in the 20th century do not adequately address the complexity and interdependencies of today's higher‐order systems that often must operate seamlessly with huge and disparate legacy systems. Soft management issues, such as organizational culture, also play a vital role in the organization's system of systems, often called the extended enterprise. Strategy must be formulated—and appropriate deployment mechanisms designed—for the system of systems level.

System of Systems (SoS) has become a popular buzz word among systems engineering practitioners, but what does it really mean? Some professional literature traces the origins of SoS to problems with systems that “nobody owns,“1 while the U.S. Department of Defense has recognized that Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) systems must be seamlessly integrated with weapons systems in order to achieve optimal SoS effects. This paper offers an explanation of key SoS concepts and proposes some useful practices that the authors have found useful to address the complexities of large‐scale integration of SoS assets across the extended enterprise (EE).
6.1.1 Towards a Structure for Systems Engineering Research
Authors: Ferris Timothy L.J. , Cook Stephen C. , Honour Eric C.
Published: November 2014

This paper discusses the need for the development of a framework for Systems Engineering to facilitate recognition of Systems Engineering as a discipline and to provide a fundamental basis for advancing the practice of Systems Engineering. Systems Engineering concerns the development of systems that satisfy the real needs of those who call for the systems to be created. Such systems are not tangible things that can be analyzed as objects to be inspected and described, but rather these systems interact with their users and stakeholders in a complex manner, where the introduction of the system perturbs the pre‐existent situation, resulting in a need for sophisticated methodologies to analyze and predict outcomes of system creation and deployment. The paper exposes and discusses a range of research methodologies that are appropriate for contributing to the development of a coherent framework of research in Systems Engineering.
7.3.1 Managing Effectivity of SE Work Products
Authors: Smith Darold K.
Published: November 2014

This paper describes an approach to embedding product effectivity1 in Object‐Oriented Systems Engineering (OOSE) databases that automatically generates effectivity information for objects in the database and has the potential for significantly reducing SE database size by reusing elements common to different product configurations2.
7.4.3 Integrated Communications Architecture for Homeland Security
Authors: Yeoh Lean Weng , Tan Kok Sin Stephen
Published: November 2014

The fateful event of September 11 in the US and subsequent terrorist attacks in many countries had changed the world. We now live in a world of troubled peace, a far more dangerous world for many of us. A well‐networked security force will have comprehensive situation awareness to respond to unconventional threats like terrorism, low intensity conflict and even SARS. Conventional military communications has proven to be ineffective especially in urban environment where high‐rise buildings hinder the electromagnetic wave propagation of VHF and UHF communications. In Singapore, a well‐defined and integrated network centric based communications infrastructure is being put in place to link military and homeland security forces into an integrated force.
8.1.1 Systems engineering of socio‐technical systems
Authors: Ottens Maarten , Franssen Maarten , Kroes Peter , van de Poel Ibo
Published: November 2014

In this paper we discuss how the increasing importance of socio‐technical systems affects systems engineering. We start with a clarification of the notion of systems engineering by distinguishing two ways in which engineering design is involved with systems characteristics: in the object of design and in the design approach. Next we focus on system‐like objects of design of a special sort: socio‐technical systems. After presenting two examples, we indicate several tensions between the systems engineering design approach and the design of socio‐technical systems.
8.1.3 A system‐of‐systems approach for application to large‐scale transportation problems
Authors: Kang Taewoo , Mavris Dimitri N.
Published: November 2014

There is growing recognition of a class of problems known as “System‐of‐Systems” that draws parallels to the characteristics and philosophy of Systems Engineering, but with unique complexities that deserve separate focus and study. This paper first seeks to outline defining characteristics of System‐of‐Systems problems, and discusses the progression of research in related fields as well as the direction for ongoing research in this area. A key aspect in System‐of‐Systems research is the dynamic propagation of uncertainty across the stakeholder network. To investigate this phenomenon, a system dynamics model of a Personal Air Vehicle (PAV) manufacturer is first developed. Using Monte Carlo Simulation, the variability of the manufacturer's yearly net income over a ten‐year period is calculated. Combined with the evaluation of uncertainty characteristics more prevalent in other stakeholders, this methodology provides guidance in determining robust strategies at the System‐of‐Systems level.
9.1.1 A Highly Automated CMMI‐Driven Self‐Organizing and Mapped (SOM) Document Library
Authors: Beshore David G.
Published: November 2014

Over the past 10 years, systems engineering standards and process improvement models have matured to CMMI, IEEE/EIA 12207, and ISO 15288. A novel automated technique for rapidly capturing systems and software engineering specialty knowledge by ‘relevance’ algorithms while displaying the data in three‐dimensional Self Organizing Maps (SOMs) has been developed. Tools are based on the author's REALM© (Requirements Enabled Automated Learning Method) process that is used to categorize and rank any size document set to any baseline document set, including websites. The examples in this paper illustrate a document set that represents nearly 3000 pages of content (past maturity models, process implementation procedures, handbooks, books, websites and tools). The highest scoring process definition documents related to the CMMI are a Systems Engineering Process Manual (SEPM) and IEEE/EIA 12207. REALM© has other applications: systems and software handbooks, standards, contracts, appraisals, assessments, audits, proposal requests (RFPs), proposals, design reviews, test plans, statements of objectives (SOO), work statements (SOW), business plans, etc.
9.1.3 Modular Building Blocks for Manned Spacecraft: A Case Study for Moon and Mars Landing Systems
Authors: Hofstetter Wilfried , de Weck Olivier , Crawley Edward
Published: November 2014

A method is presented for the selection of optimal modular building blocks for platforming of manned Moon and Mars landing systems employing modularity on the subsystem level; platforming shall here be defined as the reuse of designs across different systems. The motivation for platforming is the need to reduce overall Moon and Mars exploration architecture lifecycle cost by lowering spacecraft development, test, and fixed production cost, and to provide flexibility in system design to accommodate changes in the exploration architecture. The fundamental idea is to compute the surplus in functional attributes generated by using particular building block (module) sizes, then relate the surplus to a cost function, and finally select the building block sizes with minimal additional cost. Results are presented for modular crew compartments, propellant tanks, and engines. The proposed method is potentially helpful for platforming decision‐making, as well as subsystem technology selection in a broad class of engineering systems.
9.2.2 Design for Six Sigma (DFSS) Integrated with Systems Engineering Toolsets …Systems Engineering Quality Into Products
Authors: Gianacakes George , Sampson Mark E.
Published: November 2014

This paper describes an approach to merging statistical design techniques with allocation relationships in a systems engineering design environment; actually associating statistical distributions and transfer functions with those relationships. This allows users to apply Design for Six Sigma (DFSS) techniques early in product development where systems engineers can develop conceptual designs that are “robust” or insensitive to change/variation—effectively systems engineering quality into products.
10.3.3 10 Golden Questions for Concept Exploration and Development
Authors: Surber Dan C.
Published: November 2014

Project engineers and development teams must be able to quickly understand the customer's need. There are many tools, methods, and processes suggested for conducting “Concept Exploration” and “Concept Development“. The author believes that there are “10 golden questions” which get the requirements elicitation done right. They apply to any Product (knowledge, good or service), system, or organizational structure. The “10 Questions” go a bit further than grammar school's: “who, what, where, when, why, and how.” Interaction with the customer/user illumines a key aspect of the system solution, “How does failure affect customer satisfaction?” Asking, “What if the product, (seen at its various levels of decomposition such as, “system/product/component”), FAILS to satisfy these ‘requirements‘?”, leads the designer to a better system solution. These answers take one to the next important discovery, answering, “How do we achieve mitigation and control of any critical failure modes and their effects on mission success, (through design, manufacturing, materials, and training).” This is the true purpose of the systems engineering lifecycle.
10.4.2 System Integration Frameworks
Authors: Simpson Joseph J. , Simpson Mary J.
Published: November 2014

An organizations ability to effectively create, deploy and use system integration frameworks is a discriminating technical capability which will continue to grow in importance for the design, development and deployment of future engineered systems. Engineering activities utilized in large‐scale systems integration processes are strongly associated with organized problem solving and complexity reduction. This paper outlines the relationships between systems, meta‐systems, and integration frameworks as well as complexity measures, reduction and management. The primary thesis of this paper relates to the design and use of integration frameworks as a fundamental means of complexity reduction. A system “abstraction frame” concept is presented and related to classical systems engineering mathematics and practices. A proposal for a systems engineering language completes the content of this paper. A formal systems engineering language will greatly reduce complexity in the practice of systems engineering, as well as facilitate the solution of even more complex problems.
10.4.3 Putting Leadership into Systems Engineering–A Model for Systems Engineering Leadership Development
Authors: Holzer Thomas H.
Published: November 2014

Systems Engineers, at all experience levels, need to be capable in more than the field of Systems Engineering. They require solid leadership competencies in order to gain essential support within an engineering or program team, properly influence the technical and programmatic direction, and achieve the best program outcome. Therefore, as a Systems Engineer advances (and in order to advance) in their career, the importance of being and demonstrating performance as an effective leader should increase. This paper is based on direct observations where weaknesses in leadership skills were noted in engineers. A structured leadership development program for systems engineers is providing the necessary competencies to perform in their work environment. The case study highlights the need for increased emphasis on systems engineering leadership training and provides a leadership development model. Survey results and findings provided validate the program's performance towards its objective.
11.3.1 What Are Levels?
Authors: Bahill Terry , Botta Rick , Smith Eric
Published: November 2014

The most common mistake in modeling systems is mixing elements of different levels in the same model. This paper explains levels, shows how levels can be obtained with decomposition techniques, and gives examples of level models, architectures and frameworks. Examples are given which show the confusion that results when levels are mixed.
11.3.3 Acknowledging Uncertainty in the Provision of Defence Capability: Insights from Literature
Authors: Rajabally Eshan , Snape Simon , Whittle Steve , Sen Pratyush
Published: November 2014

Uncertainty pervades the world we live in although its presence is not always acknowledged in systems engineering. Its influence on providing systems‐of‐systems defence capability is not only amplified by the aggregation of uncertainty through the systems hierarchy but also by the ambiguity in defining such capability. Worryingly, a failure to account for uncertainty can ultimately lead to a failure to satisfy the customer. Dealing with uncertainty must begin with acknowledging, understanding and synthesising the insight that literature has to offer on the topic. Such insight is summarised in this paper by reviewing the pertinent literature on the topic. A number of formalisms for expressing uncertainty exist and the pros and cons of each are surveyed. Traditional means of uncertainty analysis are also reviewed as a basis for dealing with uncertainty in defence capability. Despite the emphasis on the provision of defence capability, the topics presented in this paper are relevant to systems engineering in general.
1.1.3 Part Count and Design of Robust Systems
Authors: Frey Daniel , Palladino Joseph , Sullivan John , Atherton Malvern
Published: November 2014

Systems engineering efforts are frequently undertaken to reduce part count with the goal of cutting costs, enhancing performance, or improving reliability. This paper examines the engineering practices related to part count, applying different theories – the Theory of Inventive Problem Solving (TRIZ), Axiomatic Design, and Highly Optimized Tolerance. Case studies from the jet engine industry are used to illustrate the complicated trades‐offs involved in real‐world part count reduction efforts. It is shown that no current theory fully accounts for the realities of system design, but that part consolidation at the component level generally proceeds consistent with the TRIZ ideality principle and that system part count and coupling are generally increasing driven by escalating demands for system performance and robustness.
1.2.1 A Requirements Guide For All (REGAL)
Authors: Dick Jeremy , Fanmuy Gauthier , Thevenet Laure‐Hélène
Published: November 2014

This paper describes an INCOSE initiative to collect from the systems engineering community information about good practice in requirements engineering, management and development. This initiative is the brainchild of the INCOSE Requirements Working Group, and is intended to provide a living requirements “Book of Knowledge” accessible in electronic form on the web, through which practitioners can contribute, evaluate and debate good requirements practice.
1.2.3 Role of Flow‐Down Approach and Orthogonal Arrays in System Design and Testing
Authors: Jugulum Rajesh , Singh Jagmeet
Published: November 2014

Design of systems to perform their intended functions is a creative and challenging activity because many requirements need to be satisfied under all customer usage conditions. In order to perform their intended functions over wide range of usage conditions, the systems must be designed in robust manner with a systematic flow‐down of requirements at various levels of the design process. After completing the design they must be tested in various usage conditions and studying all possible main effects and interactions. This type of testing enables customers to have a robust product, which will avoid incidences of functional failures. In this paper we used axiomatic design's zig‐zag approach for requirements flow‐down and orthogonal arrays for testing the system's performance. Since software design is a good example of system design, we describe use of these techniques in system design by considering software design as an example.
1.2.4 How do we win this game when the rules keep changing?
Authors: Mackertich Neal , Cleotelis Dave
Published: November 2014

We all know the goal of the game: “Develop increasingly complex systems with smaller performance margins that meet the user's requirements in the shortest time, with high reliability, open and adaptable, and at the lowest cost”. The environment we are working in continues to push Systems Engineering challenges to the next level. As Systems Engineers, we all want to win the game i.e. beat our competitors, satisfy our customers, develop unprecedented systems to address political and economic challenges. We have a proven process and a common set of tools, which we use and refine. Yet as we begin to participate in the game, we find that not only do we have huge challenges, but the rules keep changing. The customer/user requirements change, the conceptual design needs modification, the analysis reveals design challenges, budgets are reallocated. So how do we win this game? This paper presents a case for the increased application of a suite of enablers, processes, and practices referred to as Design for Six Sigma at appropriate integration points during the Systems Engineering process lifecycle.
1.3.1 Quantifying the benefit of introducing Systems Engineering Processes ‐ Myth or Reality?
Authors: Knippel Erwin , Schulz Armin
Published: November 2014

In the past years the automotive industry had to face, especially in the field of electric/ electronic, an increase in complexity. To be able to keep highest quality standards BMW Group had to restructure its existing processes within electric/electronic development according to these new challenges. A Change Program was set up to shift those development processes towards a system orientated development.

For commercial driven companies an evaluation of cost vs. benefits is a prerequisite for approval and execution of such a change program. Therefore a business case was necessary. At the beginning of the change program a statement of anticipated likely impacts had to be made. At the end of the change program predicted impacts had to be validated. The approach taken was based on an aggregation of evaluations performed by the different subprojects of the change program. This paper is illustrating – based on the experiences of a subproject (Configuration Management) – the approach taken to model and evaluate a business case at the beginning and the end of the change program. An example using neutralized data from BMW Group is demonstrating the approach. Lessons learned and success factors implementing the approach are discussed. Evaluating or even quantifying the value of Systems Engineering Processes within product development is discussed within the SE community for quite a while, with very different positions. This paper aims at making a contribution to this discussion.
1.4.2 An Approach to Simulation Effectivenes
Authors: Gonçalves Duarte
Published: November 2014

Simulation is an important aspect of engineering complex systems. In the real world, numerous problems can prevent the effective use of simulation. This paper looks at the tough question: When is a simulation effective? How would we know? The context and purpose of simulation are important in answering the question.

If the simulation is viewed as a system, it follows that it has stakeholders and requirements originating from the creating system. An important result is that measures of simulation effectiveness include fidelity, time‐to‐answer, and resource usage. The importance of a referent (codified knowledge) in defining fidelity and related pitfalls are discussed. Simulation effectiveness assessment enables simulation designers to trade simulation effectiveness against cost and risk subject to constraints. A brief overview of how abstraction and simulation method selection can be used for this trade‐off is given. The impact of simulation effectiveness on risk is discussed. The benefits are balanced simulations with risk that is better matched to the problem at hand.
2.1.1 Feelings and Physics: Emotional, Psychological, and Other Soft Human Requirements, by Model‐Based Systems Engineering
Authors: Schindel William D.
Published: November 2014

Traditionally, engineering encourages requirements statements that are objective, testable, quantitative, atomic descriptions of system technical behavior. But what about “soft” requirements? When products deliver psychologically or emotionally‐based human experiences, subjective descriptions may frustrate engineers. This challenge is important for products appealing to senses of style, enjoyment, fulfillment, stimulation, power, safety, awareness, comfort, or similar emotional or psychological factors. Automobiles, buildings, consumer products, packaging, graphic user interfaces, airline passenger compartments and flight decks, and hospital equipment provide typical examples. This paper shows how Model‐Based Systems Engineering helps solve three related problems: (1) integrating models of “soft” human experience with hard technical product requirements; (2) describing how to score traditional “hard” technology products in terms of “fuzzier” business and competitive marketplace issues; and (3) coordinating marketing communication and promotion with the design process. The resulting framework integrates the diverse perspectives of engineers, stylists, industrial designers, human factors experts, and marketing professionals.
2.2.1 Test time reduction by optimal test sequencing1
Authors: Boumen R. , de Jong I.S.M. , van de Mortel‐Fronczak J.M. , Rooda J.E.
Published: November 2014

Testing complex manufacturing systems, like ASML lithographic machines (ASML 2005), can take up to 45% of the total development time of a system. This test time can be reduced by choosing wisely which test cases must be performed in which sequence, without making investments in test cases or the system. With the test sequencing method, developed by (Boumen 2005, 2006), it is possible to make these decisions such that a time, cost and/or quality optimal test sequence can be constructed. This paper shows with two case studies that test time can be reduced up to 20% without loss of quality with this method. The first case study is related to the test phase during the manufacturing of a lithographic machine. The second case study is related to the reliability testing of a first of a kind lithographic machine.
2.2.2 Integration and test strategies for semiconductor manufacturing equipment1
Authors: de Jong I.S.M. , Boumen R. , van de Mortel‐Fronczak J.M. , Rooda J.E.
Published: November 2014

The complexity of semiconductor manufacturing equipment is growing. This growth results in a complexity increase of the integration and test phase of these systems. Simply adding more test resources is not possible anymore, because of the cost involved. A better design of an integration and test strategy can help to optimize this hectic phase. However, methods to design and evaluate integration and test strategies for multi‐disciplinary systems are hardly available. In this paper, we present a method to design and compare integration and test strategies. Following this method, an optimal integration and test strategy can be chosen from a set of possible strategies. A case has been performed where a system is integrated and tested using three different integration and test strategies: a time‐to‐market‐driven strategy, a quality‐driven strategy and a combined quality and time‐to‐market strategy.
2.3.1 A Practical Program of Research to Measure Systems Engineering Return on Investment (SE‐ROI)
Authors: Honour Eric C.
Published: November 2014

Past analysis has shown that there is a quantifiable correlation between the amount, types and quality of systems engineering efforts used during a program and the success of the program. For any given program, an amount, type and quality of systems engineering effort can be selected from the quantified correlations. The optimal nature of these selections, however, has not yet been explored. An ongoing project, Systems Engineering Return on Investment (SE‐ROI), aims to quantify the correlations by gathering data on current and completed programs. This paper describes the practical program of research being used in the SE‐ROI project and the current state of that development. The research program involves defining categorization sufficient to explore the correlations, implementing that categorization onto data sheets, gathering data from real programs through a personal interview process with the program leaders, and then performing statistical work to reveal the correlations. The project expects to achieve practical results in the form of (a) statistical correlation of SE methods with project success, to understand how much of each SE method is appropriate under what conditions, (b) leading indicators that can be used during a project to assess the project's expected future success and risks, and (c) identification of good SE practices that are appropriate to generate success under different conditions.1
2.4.2 A Proposed Paper Template for improving the Quality of Practitioner Written Papers at Conferences and Symposia
Authors: Kasser Joseph E.
Published: November 2014

Conference papers are a major source of information in postgraduate education and research. However, the quality of many practitioner‐written conference papers describing their experiences is less than optimal. This paper suggests a template to try to improve the quality of practitioner presentations and papers in the Case Study genre (prototyped at SETE 2004) to format practitioner papers as a way to link their experiences into the literature to provide data to assist researchers improving the practice of systems engineering. Examples of the use of the template are included.
3.1.1 COCOMO‐SCORM Interactive Courseware Project Cost Modeling
Authors: Smith Roger , Edwards Lacey
Published: November 2014

The U.S. Department of Defense has made significant investments in interactive courseware designed to train personnel distributed around the world. As these projects have multiplied, so too have the different approaches to estimating the schedule and staffing to create them. This paper presents the current status of a project that is creating a cost estimation algorithm for interactive courseware based on the COCOMO II family of software cost models. Our project focuses on specializing the COCOMO algorithm to account for the important variables to courseware development projects. We also will calibrate the algorithm to match historical data available from completed SCORM courseware projects.
3.1.2 Human Performance Modeling for Enterprise Transformation
Authors: Lintern Gavan
Published: November 2014

Satisfaction of current demands for increased efficiency in the use of human resources requires nothing less than a revolutionary transformation in how we structure complex socio‐technical systems. Human systems issues related to transformation of complex socio‐technical systems pose substantive design challenges that must be addressed with human–centric analysis followed by human‐centric design. In this paper, I integrate a cognitive work analysis strategy with a human performance modeling strategy which, when combined, constitutes a systematic, human–centric analysis‐to‐prototype design framework. I have described the cognitive work analysis strategy elsewhere and in this paper focus my discussion on cognitive workflow modeling. I illustrate the requirements of human performance modeling and methods of satisfying them with reference to a Brahms workflow model of time sensitive targeting based in part on a functional abstraction space developed within a cognitive work analysis and use that workflow model to motivate discussion of issues related to human‐centric design for enterprise transformation.
3.1.3 Strategy For the Composition and Development of the Authoritative System Representation (ASR)
Authors: Clayton Robert
Published: November 2014

Engineering a system in this era of hyper‐complexity and massive scale, necessitates modeling and simulation (M&S) application at nearly every step of the system's life‐cycle. The sequential nature of the Systems Engineering (SE) process provides opportunities to apply M&S that is particularly suited to each phase of the SE process. The credibility of M&S is strongly tied to the degree of similarity or fidelity of the M&S tool and its appropriateness in addressing the immediate engineering issues within the current SE phase. Correspondingly, engineering and developing the M&S tool requires a degree of specification analogous to the specification of requirements associated with the system. This specification serves to define what the tool is to do. It also serves to benchmark how well it is to do it so that it will be clear if the M&S tool was built correctly (through Verification and Validation). But unlike the larger system to which the tool will be employed, a majority of the M&S tool specification is not of the tool, itself, but rather the portrayal of the object of its employment— the system/element under engineering or scrutiny. This is referred to as the system representation or simply, the representation.

This paper focuses on the development of a formal representation product for M&S mandated in the Defense (more specifically, Army) Acquisition system entitled the Authoritative System Representation (ASR). The paper's perspective is strongly oriented on the M&S developer's challenge of providing, to the System Engineer, tools that fulfil engineering needs. Every attempt is made to correlate System Engineering practices with Software Development practices of sound M&S construction. The ASR is a critical, but previously unheralded, component of the Defense Acquisition concept of Simulation Based Acquisition. This paper strives to share insight into this M&S product which is deserving of understanding by System Engineers.
3.2.1 Corporate Social Responsibility (CSR) ‐ the System Perspective & the Systems Engineering Role
Authors: Zonnenshain Avigdor
Published: November 2014

During the last decade, we have witnessed companies exercising Social Responsibility (SR) in their business. CSR is the responsibility that is incumbent upon a company, its managers and workers in their activities and decisions insofar as it affects the society. CSR includes issues and solutions in different areas such as: Environment, Hygiene, Safety, Sustainability, Working Environment, Labor Relationship, Human Resources, Product Life Cycle, Ethics, Investing in the Community, Corporate Governance and Transparency & Reporting. Leading companies are incorporating CSR requirements and issues into their Corporate Management System. This system includes strategy, policy, practices, processes, procedures, action plans, and success measures. This paper describes how to build and conduct CSR as a System. We do this by presenting CSR as a Management System by describing the principles of this System and through the experiences of my company – RAFAEL. Also, we describe the role of Systems Engineering in introducing and implementing CSR. We propose a role for INCOSE and its Chapters in promoting CSR.
3.2.2 Cost As An Independent Variable Balancing Performance with Affordability
Authors: Casey Ed , Allen DeWayne
Published: November 2014

The US Department Of Defense (DoD) Cost as An Independent Variable (CAIV) initiative replaced their Design To Cost (DTC) requirements. These changes were caused by the continuing reduction in the DoD budgets and the requirement to maintain the country's war fighting capabilities as the best in the world. In this peacetime environment, cost is the overarching constraint, not performance. As system providers, we are required to identify the customer's cost driving requirements. The customer/user can then makes the program decision to reduce system performance to maintain program costs.

CAIV is the trade‐off of total ownership cost (TOC), also known as life cycle cost (LCC), performance, schedule and risk for a product that is developed, produced, and supported within the customer's expectations.

In order to easily evaluate a program's performance in the area of CAIV, a small series of metrics can be established. Since CAIV seeks to find the optimum balance between Cost, Performance, Schedule and Risk, any set of CAIV Metrics should encompass these areas. These metrics would allow both senior management and the program manager a clearer picture of a program's status and progress, and, when applicable, be able to identify areas in which a program needs assistance or a concentration of forces.

This paper presents the CAIV process, program responsibilities, and a recommendation for a series of CAIV Metrics.
3.3.1 Network Centric Operation Implementations in Several Domains
Authors: Adler Charles , Dagli Cihan
Published: November 2014

A current focus in building military systems is the use of network based approaches. This is exemplified in the concepts of Network Centric Operations (NCO), Network Enabled Capabilities (NEC) or Network Based Defense (NBD). These concepts are, in part, inspired and motivated by the network based approaches that have revolutionized conducting business and operations in commercial domains across a wide spectrum of activities.

Network centric systems in the commercial domain display a number of interesting capabilities. These included the means to integrate extremely large groups of users into effective systems‐of‐systems with time constants measured on the order of hours/days. The basic network centric enablers used in these systems fall into several major categories.

This paper examines several high level architectures used in network centric operations for a number of non‐military network based systems; a ‘bricks and mortar’ retailer, on‐line ‘eCommerce’ businesses, and in software development. This examination is done by means of a literature survey and focuses on the interaction patterns that the systems must support, important capabilities the systems provide and important architectural enablers.
3.3.3 A novel modeling approach enhancing classic scenario generation techniques
Authors: Eelman Stephan , Föller Stephan
Published: November 2014

Scenario methods are deployed in strategic planning to generate alternative environments as a mean to deal with uncertainties imposed by factors, which are hard to foresee or control. Current mainstream methodological approaches produce descriptive, steady‐state scenarios with qualitative outcomes. For description of complex and unsteady environments they show deficiencies to reproduce dynamic behavior of systems and fall short to highlight scenarios of higher‐than‐average quality and value, restraining the efficiency to address uncertainty.

The paper presents an approach to comply with this need using established scenario techniques in an integrated way and incorporating a new technique to generate scenarios stepwise into the future. It utilizes procedures to cluster relevant scenarios and quantifies scenario quality with relevant indicators.

Results of a sample processes demonstrate that the approach behaves as complex system. Scenarios produced obtain a desired level of consistency and homogeneity within clusters while they establish high dissimilarity amongst one another. The achieved process quality contributes to an improved selection and assessment of relevant scenarios which form sound foundations for alternative strategy mappings and, thus, the understanding and treatment of system uncertainties.
3.4.2 Capability engineering for strategic decision making
Authors: Lizotte M. , Nécaille C. , Lalancette C.
Published: November 2014

The current paper summarizes the Capability Engineering Process (CEP) being developed to help decision making on strategic investments and divestments for the Canadian Forces and Department of National Defence. This effort is part of a technology demonstration effort called the Collaborative, Capability, Definition, Engineering and Management (CapDEM). The CEP introduces ways to increase strategic agility capability management in a world in constant evolution. A CEP application provides a set of options addressing a given capability gap. Among benefits, this process: (1) provides decision makers with timely strategic information through an iterative and incremental approach; (2) reduces time spent on unrealistic options by continuously pruning the solution space as early as possible; (3) provides operationally acceptable strategic options with direct involvement of the operational community into the solution development; and (4) provides feasible options by ensuring commitment and participation in developing solutions involving all of the organization's functional components: Personnel, R&D, Infrastructure, Concept development, Information management, and Equipment (known as PRICIE components in Canada).
4.1.2 Project‐driven adaptation of software life cycle model
Authors: Barnard E.M.
Published: November 2014

Due to ever‐changing technology and business requirements, the inefficiency and ineffectiveness of traditional plan‐driven software development life cycle models are being questioned. Software engineers have to find ways of improving software development processes by applying more agile principles to the traditional plan‐driven approaches. This paper addresses this issue and suggests how project and technical management can apply principles from the agile group of life cycle models to alleviate some of the problems encountered. Project characteristics that can be used to evaluate individual projects to determine the degree to which the software life cycle can be adapted, are indicated. Practices are also proposed for adapting traditional plan‐driven life cycle processes that can benefit from more agile approaches.
4.3.2 Platform identification using Design Structure Matrices
Authors: Kalligeros Konstantinos , de Weck Olivier , de Neufville Richard , Luckins Adrian
Published: November 2014

This paper introduces a methodology and algorithm for the qualitative identification of platform components at multiple levels of system aggregation, among variants within a family of systems. We assume that the architectural concept and the functional requirements for the variants are pre‐determined, and use Sensitivity Design Structure Matrices (SDSM) to represent the sensitivities between the design variables of the variants. We then introduce a novel algorithm for the identification of platform variables given the SDSM for each variant. Finally, the methodology is extended to the qualitative identification of platforms at various levels of system aggregation, i.e., between systems, subsystems and components. The process is demonstrated in an example of platform identification among topsides facilities of Floating Production, Storage and Offloading (FPSO) units.
5.1.1 Enterprise Opportunity and Risk
Authors: White B. E.
Published: November 2014

In traditional systems engineering (TSE) environments, and particularly in recent years, many are concerned about risk management. So much so that risks are identified early and often, and mitigation techniques are aggressively pursued. In contrast one does not hear as much about opportunity management. What about enterprise systems engineering (ESE) environments? Do traditional methods of handling risk and opportunity carry over, or should we be concerned about potential changes in the way we view the problem? Assuming there are new perspectives to bring to bear on this topic, what are they, and what principles might be discovered and applied to the enterprise to better deal with opportunity and risk? This paper offers some answers to these questions

There is duality in treating risks and opportunities.

In ESE, be aggressive with opportunity and accepting of risk.

The greatest enterprise risk may be in not pursuing enterprise opportunities.
5.1.2 Cross‐Cultural Issues Associated with the Application of ISO/IEC 15288 Standard
Authors: Ferris Timothy L.J.
Published: November 2014

This paper reviews the history of systems engineering standards documents from the perspective of the interaction of the standards with culture. The early standards were largely prescriptive procedural documents arising from concerns of the defense and aerospace industries, largely in USA. The latest standard, ISO 15288, follows an issues related approach and is designed to be flexible enough to address the systems engineering needs of a broad range of industries in many countries. The paper argues that the new standard presents different cultural challenges than the earlier standards. The cultural analysis of Hofstede is used as a theoretical construct with which to assess the interaction of the change from earlier standards to ISO 15288 with national and organizational cultures.
5.3.1 Lessons Learnt From the Applications of QFD to the Definition of Complex Systems
Authors: Hari Amihud , Kasser Joseph E. , Weiss Menachem P.
Published: November 2014

Quality Function Deployment (QFD) has been used to elucidate and negotiate requirements for at least 20 years. QFD has a lot to offer but when used to specify complex systems, has been found to have a number of deficiencies, has been perceived as a time consuming process and has been found as being difficult to apply to complex systems. This paper summarizes the top five lessons learned from 15 years of experience in using QFD in the elicitation, elucidation and negotiation of requirements for complex systems.
5.3.2 On the Systematic Use of Budget‐Based Design
Authors: Freriks H.J.M. , Heemels W.P.M.H. , Muller G.J. , Sandee J.H.
Published: November 2014

In the majority of the engineering projects, the most important design decisions are taken at the early stages of the design. As these decisions have a considerable impact on the final implementation of the product, they ought to be made in a well‐considered manner. The usage of higher‐level methods to support making balanced decisions in initial stages of a design is considered very helpful. This paper deals with one of these methods: budget‐based design. It is claimed that the systematic usage of budgets helps to speed‐up the development process, to better assess project risks and results in better‐founded design tradeoffs.
6.2.2 Systems Engineering Model for Integrability (SEMI): A Three Step Process for the Continuous Development of Highly Integrated Enterprise Applications*
Authors: Lewis JW
Published: November 2014

Stovepipe analytic applications are the norm for the complex organizations involved in product design, law enforcement, and government. However, to be effective, these analytic applications must now rely on services provided by other organizations, exchange data with those organizations, and standardize on components defined by multiple integration architectures. Stovepipes are no longer adequate.

There is a bewildering array of technologies for developing integrated applications. Alternatives range from procedure libraries and relational databases to object‐oriented databases and service‐oriented architectures. Design decisions can have order‐of‐magnitude impact on performance, integrability, and maintainability. SEMI is a three‐step process for structuring the decision making involved in the continuous development of integrated applications. The first step in SEMI is modeling the integration architectures; the second step is assessing the level of integration, and the third step is an integrated decision model.
6.2.3 Conflict in Systems Engineering Product Data Exchange Standardisation
Authors: Eckert Roland
Published: November 2014

Interoperability is the most critical issue facing business that need to access information stored in different CASE tools or information systems. Industry and the arch community have developed several standards and methodologies to facilitate interoperability among distributed and heterogeneous information systems.

The paper compares several available standards for the exchange of systems engineering data. As an example, the enormous overlapping between the available solutions for the exchange of requirements data and the resulting disadvantage for industry is shown. A better organised way for developing new standards is proposed.