bluuebunny/crossref_metadata_2025_split huggingface dataset:
4.5.1 The Capability Integration Framework: A New Way of Doing Enterprise Architecture
Authors: Conklin James H. , Evans John W. , Martin James N. , Robinson Charles T. , Diehl Jeff J. , Doggrell Leslie J. 
Published: November 2014

AbstractThe Capability Integration Framework was created to help Air Force Space Command leadership understand the relationships that existed within their organization. By following a modeling process developed by The Aerospace Corporation, the architecture team was able to deliver the first version of the tool after three months of work. This paper will briefly discuss the modeling process and will use the Capability Integration Framework as an example for applying this process. Some features unique to this model will also be demonstrated.
4.6.2 A Knowledge Management Approach to Change Management in Systems‐of‐Systems
Authors: Cropley David H 
Published: November 2014

AbstractWhen a complex entity comprises, for example, a set of individually complex, geographically distributed, evolving systems, the question of how to manage change to such a system‐of‐systems takes great significance. Not only must change be managed at the level of each component system, it must also be managed across the entire interrelated and interacting set. The solution presented in this paper is based on research that treats a class of warships in the Royal Australian Navy (RAN), along with the associated operational, production and support systems, as a system‐of‐systems (SoS) and examines the management of change in this complex entity. The paper describes a Knowledge Management (KM) strategy that can be used to plan, manage, coordinate and implement change across the entire lifecycle of the target system‐of‐systems and which may be generalisable to other systems‐of‐systems.
2 Panel: Evolving to Intelligent SE
Authors: Ring Jack , Lillehagen Frank , Alessi Sam , Aslaksen Erik W. 
Published: November 2014

AbstractNew technologies are enabling Model‐driven Approaches and Architectures, Model‐converged Methodologies, Model‐integrated Enterprises and Infrastructures, Model‐developed Collaboration Platforms, Model‐designed Solutions and Project Environments, Model‐generated Workplaces for work execution and management, and Model‐managed Enterprise Knowledge Spaces and architectures. Knowledge engineering platform providers will within 2006 offer a completely new approach to Systems Engineering and Enterprise Integration, embedding any system in one or more enterprise knowledge spaces. An Enterprise Knowledge Space is implemented as an Enterprise Visual Scene.
5.1.3 Requirements Completeness
Authors: Carson Ronald S. , Aslaksen Erik , Caple George , Davies Paul , Gonzales Regina , Kohl Ron , Sahraoui Abd‐El‐Kader 
Published: November 2014

AbstractThe INCOSE Requirements Working Group has attempted to define a process and methodology for producing a complete set of requirements. We first carefully define the problem statement and terms. Various approaches to completeness are reviewed, and a formal process is proposed to quantify completeness.
5.2.3 Product and Process – Student Learning in an Undergraduate Systems Engineering Course
Authors: Ferris Timothy L.J. 
Published: November 2014

AbstractThe University of South Australia program, Bachelor of Engineering (IT Option) contains a sequence of four courses in the field of Systems Engineering, comprising 12.5% of the program. This paper describes the content and teaching processes used in the last course in this sequence, scheduled for the undergraduate students in the final semester of their program. The paper discusses the evidence provided by students of the learning that they have achieved through the course in the assignment assessment, weighted 40% of the course. It is found that the learning about the practice of Systems Engineering developed by students is not correlated with the achievement in the technical aspects of the project. The kinds of learning achieved are discussed in the paper.
5.4.1 The Use of Integrated Architectures to Support Agent Based Simulation: An Initial Investigation
Authors: Zinn Andrew , DeStefano Greg , Jacques David 
Published: November 2014

AbstractArchitecture descriptions following the Department of Defense Architectural Framework (DoDAF) will be used to aid in the acquisition of all major defense information systems. One of the primary purposes of these architectures is to help conduct military‐worth analysis. Recent work in operations analysis of information driven combat is showing that agent based simulation technology is needed to understand the military value of Command, Control, Communications, Computers, Intelligence, and Reconnaissance (C4ISR) systems. This paper investigates the utility of architecture descriptions based on the DoDAF to provide the needed data for agent based simulation. This is accomplished by means of a case study where data from a DoD architecture is used in the combat model System Effectiveness Analysis Simulation (SEAS). The research concludes that the DoDAF, if implemented properly, does provide the needed information. A process for taking information from a DoDAF architecture and importing it into agent based simulation is proposed.
6.2.3 Understanding the Value of Systems Engineering
Authors: Honour Eric C. 
Published: November 2014

AbstractThe practices of systems engineering are believed to have high value in the development of complex systems. Heuristic wisdom is that an increase in the quantity and quality of systems engineering (SE) can reduce project schedule while increasing product quality. This paper explores recent theoretical and statistical information concerning this heuristic value of SE. It explores the underlying theoretical relationships among project cost and schedule, technical value, technical size, technical complexity, and technical quality, summarizing prior work by the author. It then identifies and summarizes six prior statistical studies with conclusions that relate to the value of SE. Finally, the paper provides final results of a statistical study by the INCOSE Systems Engineering Center of Excellence (SECOE) that presents evident correlations supporting the heuristics. The results indicate that optimal SE effort is approximately 15–20% of the total project effort.
6.4.1 Creating Flexible Architectures for Systems Engineering
Authors: Hause Matthew , Thom Francis 
Published: November 2014

AbstractSystems Engineers have been modeling systems since the inception of the discipline. Reasons for modeling systems include among others: definition of the work to be done (requirements), allocation of responsibilities, documentation of the completed system, and communication with the various disciplines who will create, operate, and maintain the system. UML (the Unified Modeling Language) has recently been used by Systems Engineers to model systems. Many papers and articles have been written on various aspects of systems modeling with UML, most especially Use Cases, but little attention has been paid to system partitioning. Papers that address system partitioning do so with a “one size fits all” philosophy, by mandating a prescriptive structure that does not address the true needs of a particular system's development. Unfortunately, a badly partitioned system can be a serious handicap to the development of a system. The drivers for system partitioning include: process, product, team makeup, areas of interest, standards, physical boundaries of the system, legacy and COTS components, coupling and cohesion. A proper approach can also help in the establishment of a component based development approach, leading to reuse of requirements, design, test, and implementation artifacts. This paper will discuss these issues and illustrate their use by four case studies drawn from experience in consultation. Finally, it will give advice on lessons learned.
6.5.3 The Zachman Framework Populated with Baseball Models
Authors: Botta Rick , Bahill Terry 
Published: November 2014

AbstractThere are guidelines for making good models. Amongst these are frameworks, which help organizations develop integrated models of their businesses. Frameworks help people understand organizations and systems. The Zachman framework for enterprise architecture is a matrix (or schema), where the six rows represent different perspectives of the organization and the six columns illustrate the items, or models, viewed from each perspective. In this paper, a Zachman framework is populated with models for Baseball. These models should be easy to understand without a steep learning curve. Most of the cells are filled with quantitative simulatable models that have been published in peer reviewed journal papers. The other cells are filled with simple thought models. Jacques Barzun said, “Whoever wants to know the heart and mind of America had better learn baseball, the rules and realities of the game.” From the perspective of the Zachman framework, the way to learn Baseball is to define the models within the framework, as presented in this paper.
7.1.2 The Systems Engineering Sandwich: combining requirements, models and design
Authors: Dick Jeremy , Chard Jonathon 
Published: November 2014

AbstractAs Systems Engineering problems and solutions become more complex, it is harder for engineers to describe them and harder for reviewers and other stake‐holders to understand the descriptions. What is needed is a more powerful way of describing both problems and solutions, which combines the textual approach with the diverse world of modeling, including the use of visual representation. The result would be more accurate and complete system descriptions that are easier to understand and communicate for all stakeholders involved.In the Systems Engineering “sandwich”, requirements management is the “bread and butter” of the development cycle, and system modeling provides the “filling“. The role of the filling provided by modeling is to hold the requirements layers together, and provide richer rationale for relationships between those layers.In our opinion, the key to integrating requirements management with system model is the recording of design rational in an organized way. Such rationale explains why requirements have been decomposed in particular ways, and how one layer of requirements is intended to satisfy the layer above. The focus for such information is the “design document“.The following benefits are identified as accruing from an effective process integration of requirements management and system modeling:
System modeling adds formality to the design process that lies between each layer of requirements.
System modeling supports the construction of a consistent vocabulary for the textual expression of requirements.
The design rationale gathered around the system model becomes the rationale for tracing between layers of requirements.
The structure of the system model can be used to give structure to the requirements document.
System models can be embedded in system design documents. These can provide textual context for the system model, giving rationale for design choices, explanations of diagrams, etc.
Impact analysis can be carried out uniformly through requirements and models.
Non‐functional and performance requirements not captured in the model can be managed as textual statements.
7.3.2 Optimization of Research and Development Investment Strategies
Authors: Gormley Kevin , Fishenden James C. , Scherer William T. 
Published: November 2014

AbstractAn enterprise must make up‐front investments in applied research and development (R&D) to mature technologies to a point where they can be successfully deployed. These decisions are based on expected return from the investment and the cost, schedule and technical risks facing each R&D project. Periodically, the decisions are revisited to see if changes in project performance and cost/schedule/risk estimates warrant a change in project funding. Common approaches to this problem involve either Monte Carlo simulation of outcomes for a decision policy, or optimization of decision variables based on some objective. This paper outlines an approach to R&D project selection where both simulation and optimization are used to determine an investment strategy, given project interdependencies and uncertainties in utility, cost, schedule and technical performance. The problem is formulated as a discrete sequential stochastic decision problem and uses heuristics to narrow the solution space and find a reasonable (though non‐optimal) solution.
7.5.2 Testing a Requirements Pattern Language through Reverse Engineering
Authors: Merrick Peter , Barrow Patrick 
Published: November 2014

AbstractThis paper looks at a case study to reverse engineer an IT system that supports the Health and Safety Executive in making planning recommendations with respect to hazardous installations. It compares a Use Case model created from a requirements specification with a Use Case model derived from an inspection of the built system. The objective is to discover how accurately the final system could be predicted using a series of requirements patterns. Through the application of requirements patterns, it was possible to predict the functionality delivered to a high degree, which suggests this is a useful contribution to the prediction of functionality and thereby to system sizing. This work is part of a bigger project for the Health and Safety Executive investigating improvements to system sizing/effort estimation and its impact on the management of complexity.
8.2.1 Automated Test Generation and Execution for Automotive Embedded Software
Authors: Bouquet Fabrice , Lebeau Franck , Legeard Bruno 
Published: November 2014

AbstractThis article describes a model‐based testing approach that combines automated test‐case and test‐driver generation from Statecharts specifications. It focuses on how the test engineer can control the test generation process, and how he/she specify the relationship between model variables and the interfaces of the system under test. The Test‐driver mappings make it possible to support complete model‐based test automation: from requirement elicitation with Statecharts to test execution and verdict assignment using specific test execution environment. This approach has been used in the context of automotive embedded software validation. Three tools are used to completely support this model‐based test process: the I‐Logix Statecharts STATEMATE modeler, the LEIRIOS Test Generator and the National Instruments test execution environment TestStand. In this article, we illustrate this automated test process on a small car cruise control example.
8.2.2 Verification and Validation as it Applies to Simulation Based Acquisition
Authors: Gibson Ralph D. 
Published: November 2014

AbstractWeapon systems developed for the United States military are provided by government contractors with the hope that their system is selected for large‐scale production and use. In the past the contractor would build and provide to the military fully functional systems that were then tested to see how well they worked and whether they fulfilled the requirements. As weapon systems have grown more complicated, the ability of the contractor to build multiple systems to support testing has decreased dramatically due to the expense of those systems. In light of this fact, the Department of Defense, in cooperation with industry, has initiated a new procurement program that utilizes modeling and simulation (M&S) to augment weapon system testing. This program is titled Simulation Based Acquisition (SBA). An important factor involved with SBA is the verification and validation of the modeling and simulation models used to supplement system testing. In this paper I will describe the development of SBA, and how it augments system testing. Next, I will address the role modeling and simulation plays in SBA and how it supports system testing. I will then discuss how verification and validation is used for the M&S models as well as the results of system testing.
8.3.2 A Perspective on System Engineering Under the New US Department of Defense Acquisition Policy
Authors: Spenny C.H. , Jacques D.R. 
Published: November 2014

AbstractThe Department of Defense (DoD) acquisition policy, as stipulated in federal documents reissued in 2003, include substantive changes to the manner by which systems are to be defined and developed. Requirements have been replaced by integrated architectural views as the preferred means for documenting the capabilities of a system, and detailed procedures have been defined for converting user needs into required capabilities. The intent is to facilitate integration and interoperability and to assure technology development needs are identified and addressed at the appropriate time during the system development process. This paper provides the viewpoint of its authors on how system engineering might be applied at various times during the DoD requirements and acquisition process in support of these reforms. Challenges associated with implementation of the new policy guidance are highlighted, and tools that might facilitate development for each phase are listed.
8.4.3 Total Ship Design Approach
Authors: Neri Paolo , Dazzi Natalino , Mangiarotti Michele , Palazzo Luca Michele , Cirillo Marco , Traverso Stefano 
Published: November 2014

AbstractThe purpose of Total Ship Design (TSD) is to perform both, Cost and Mission Effectiveness analysis and Cost and Risks analysis. This paper presents a part of this process: the Value Analysis. In particular the discussion will be focused on the Value Analysis methodology set‐up and its main entities, Cost Analysis and Effectiveness Analysis.
8.5.3 Rule‐Based Design Reviews
Authors: Gilb Tom 
Published: November 2014

AbstractDesign reviews would benefit from the support of formal rules. By the use of relevant rules, it should be possible to ensure prior to a review that all the relevant information for a review is present in the design specifications, and that all the minimum review criteria are met. This will ensure management time is not wasted and aid better decision‐making. This paper recommends that the Specification Quality Control (SQC) method be used to do this additional quality control.In addition, this paper outlines the impact of Evolutionary Project Management (Evo) on the design review process.
10.6 How Many Systems Are There? – Using the N2 Method for Systems Partitioning
Authors: Bustnay Tamir , Ben‐Asher Joseph Z. 
Published: November 2014

AbstractAn algorithm for partitioning a complex system into its independent constituents is developed. The N2 method is used for the problem formulation whereby the objective is to obtain a system presentation in a simple flow. The development of the algorithm is based on graph theory techniques. The algorithm is formulated using graph theory and N2 charts. Several examples are presented to demonstrate the relative ease of the algorithm employment.
10.9 iThe Multi‐dimension Metric for the Assessment of Organizational Complexity
Authors: Song Hualing , Wang Jinli , Reiman Cornelis 
Published: November 2014

AbstractThis article applies the theories and methods of physics, mathematics, dynamics, information science, statistics and management science to develop concepts, definitions, basic theorems and research scopes in the area of management complexity; based on the theories of management entropy, it will establish a new metric for assessing management complexity and vectorial space, as well as mathematical modules. Some methods to enhance managerial effectiveness and efficiency have been proposed as a result of progress in this field. The researches so far have tried to enrich the complexity theories in management circles. As a case study of Shendong Coal Co. Ltd, the multi‐dimension metric assessment of the organizational complexity has been drawn up and verified.
1.3.1 Modeling DoDAF Compliant Architectures The Telelogic Approach for Complying with the DoD Architectural Framework
Authors: Kobryn Cris , Sibbald Chris 
Published: November 2014

AbstractNo industry is more demanding than aerospace‐defense when it concerns the complete integration of software and hardware architectures. Tasked with defending our nascent Information Age economy, the aerospace‐defense industry must be capable of waging Information Age warfare, whose key concepts include information superiority and network‐centric warfare. By most quantitative metrics, aerospace‐defense systems are among the largest and most complex ever constructed. The complexity of individual aerospace‐defense systems (e.g., an aircraft) is frequently compounded when we integrate many of them together to form a system‐of‐systems (e.g., an air traffic control system) that satisfies more global requirements.This white paper describes a technical approach for improving how we specify system and system‐of‐systems architectures using frameworks in general, and the Department of Defense Architecture Framework (DoDAF) in particular. The model‐driven approach to architectural frameworks explained here, which is based on UML™ 2.0, Telelogic TAU® Generation2™, and Telelogic DOORS®, can substantially improve productivity and quality.The information contained in this White Paper represents the current view of Telelogic on the issues discussed as of the date of publication. Because Telelogic must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Telelogic, and Telelogic cannot guarantee the accuracy of any information presented after the date of publication.This White Paper is for informational purposes only. Telelogic makes no warranties, express or implied, as to the information in this document.The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.2003–2004 Telelogic AB and PivotPoint Technology CorporationTAU, TAU Generation, TAUG2, TAU/Developer, TAU/Architect, TAU/Tester, TAU SDL Suite, DOORS, SYNERGY and DocExpress are either registered trademarks or trademarks of Telelogic.Unified Modeling Language, UML, Model Driven Architecture, and MDA are either registered trademarks or trademarks of Object Management Group.All other product and service names mentioned are the trademarks of their respective companies.
2.1.1 Revisiting the notion of system ‐ Organizations and Enterprises as systems
Authors: Faisandier Alain 
Published: November 2014

AbstractThis paper reports on a study performed for NATO about the opportunity to tailor and use the ISO/IEC 15288 standard as well as Systems Engineering concepts for such an Organization. The objective of applying the standard and SE concepts was to help prioritise, rationalise or align processes, activities and organisations.The result of this study was a report for NATO including explanations of the concepts and their potential application, rules for tailoring the standard, as well as a set of recommendations. The recommendations are not reproduced in this paper; only the “system aspects” are considered here, along with its application to NATO as a complex Organization. Some considerations about ANSI/EIA 632 are added to introduce the notion of “enabling product” and “enabling systems“.This paper discusses how the notion of System can be applied to an Organization and extends the application to Enterprises. The discussion revisits the concept of System in light of current engineering studies and coming back to fundamentals, provides a more precise and more complete definition of this notion. This enhanced definition of System rationalizes the engineering of any kind of system and particularly brings benefits to Organizations and industrial Enterprises viewed as systems. Whether the idea of engineering Organizations and Enterprises as systems is attractive to engineers or others raises questions of feasibility and relevance. Organizations and Enterprises are composed of human beings, hence, defined as “Human Systems“; so the paper ends with some words about human factors that could help or hinder the adoption of these useful rational ideas.