bluuebunny/crossref_metadata_2025_split huggingface dataset:
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

AbstractConference 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

AbstractThe 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

AbstractSatisfaction 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

AbstractEngineering 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

AbstractDuring 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

AbstractThe 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

AbstractA 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

AbstractScenario 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

AbstractThe 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

AbstractDue 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

AbstractThis 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

AbstractIn 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

AbstractThis 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

AbstractQuality 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

AbstractIn 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

AbstractStovepipe 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

AbstractInteroperability 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.
6.3.3 Application of Patterns to Systems Engineering and Architecting
Authors: Cloutier Robert J. , Boardman John , Verma Dinesh 
Published: November 2014

AbstractA system architecture pattern constitutes a high‐level structure that has been used multiple times in the same or multiple system architectures, appropriate to the design of the major components of a system. It expresses the relation between the context, a problem, and a solution. It documents attributes and usage guidance. It should be time‐proven in solving problems similar in nature to the problem under consideration. The existence of patterns is almost universal, and their use is evident in many domains. The human mind seems to perceive patterns without conscious thought ‐ we notice an individual's personal habits because they form patterns. Patterns are also used in a number of engineering disciplines – software engineering, requirements engineering and mechanical engineering to name a few. The purpose of this paper is to discuss motivations for using patterns in architecting complex systems. Further, research relating to this subject is examined and summarized.
7.2.2 Performing Functional Analysis/Allocation and Requirements Flowdown Using Use Case Realizations – An Empirical Evaluation
Authors: Eriksson Magnus , Börstler Jürgen , Borg Kjell 
Published: November 2014

AbstractThe FAR approach (Functional Architecture by use case Realizations) is a use case driven methodology for functional analysis/allocation, and requirements flowdown. The FAR approach is tailored towards the development of long lived software intensive defense systems, for example vehicles. In this paper, we present an empirical study where FAR is applied and evaluated in two large‐scale defense projects. Our results indicate that the FAR approach performs better than the previously used approach in the organization.
8.1.2 A Study of Applying Game Theoretic Concepts on Distributed Engineering System Design
Authors: Wang Hungjen , Frey Daniel 
Published: November 2014

AbstractThis paper considers the application of game theoretic concepts to the dynamics of interactions among the designers in an engineering systems design problem under a distributed decision making environment. Among all the possible distributed frameworks, we focus on two types of frameworks in the system design field, the simultaneous and the sequential response frameworks. In the investigation of the simultaneous response framework, we apply the concepts of learning theory to construct insights into the dynamics among the designers and to address convergence and other challenges of the decentralized design problems. We use a special class of games, the potential game, to demonstrate the effectiveness of the sequential response framework which points out a prospective application of game theoretic concepts to future distributed engineering systems problems.
8.3.2 Use of Technical Business Practices by Geographically Separated Teams to Facilitate Concurrent Engineering of Ultraquality Systems (LA‐UR‐05‐8500)
Authors: Neff Warren , Dagli Cihan 
Published: November 2014

AbstractIn 1997, the National Nuclear Security Administration (NNSA) undertook the development of an architecture of standards and requirements to standardize the engineering design and manufacturing of ultraquality weapon systems. This architecture, known as the Technical Business Practice (TBP) system, was implemented in 1999. The TBP system is centered around a concurrent engineering philosophy and based on a Product Realization Process methodology which is broken into four process steps: Definition, Development, Delivery, and Support.The four‐step concurrent engineering approach is accomplished through multi‐disciplinary teams known as Product Realization Teams (PRT) which are comprised of managers and subject matter experts from across the Nuclear Weapons Complex. Depending on the breadth and complexity of the engineering tasks being executed, PRTs can be subdivided into sub‐PRTs or Task Teams. Both sub‐PRTs and Task Teams tend to have a “component‐focus” versus the “system focus” of the PRTs. Using the architecture of TBPs, focused around a concurrent engineering philosophy employed by PRTs, execution of nuclear weapon programs has become more efficient, consistent, and comparable across the Nuclear Weapons Complex.