bluuebunny/crossref_metadata_2025_split huggingface dataset:
9.3.2 “Real Options and Value Driven Design in Spiral Development”
Authors: Dahlgren John W. 
Published: November 2014

AbstractThis paper proposes that the failure of many programs stems from inaccurate requirements development and failure to design for spiral development. The tremendous growth in the complexity of our society has led to a proportional growth in the number of requirements and requirements changes for many systems. This paper proposes the use of the Real Options and Value Driven Design paradigms to the system engineering, design, sprial development and program management processes. The paper also discusses how the use of the Pareto frontier with the purpose of optimizing the performance/cost ratio may actually lead to problems in fielding complex systems. This author has recently begun a research project in Real Options to determine the design tenets that make some systems flexible, adaptable, upgradeable, and scalable, while still reliable; thereby enabling these systems to last many more years than comparable systems. Research results will be discussed in a follow up paper.
The Architecture of Enterprise Architecture
Authors: Blevins Terence 
Published: November 2014

AbstractThe Architecture of Enterprise Architecture paper answers questions such as; what makes up enterprise architecture? where is enterprise architecture relative to other enterprise processes? and what is necessary to make enterprise architecture work in the complex environments where it is deployed? This paper presents a categorization of architecture offerings that can be used to position and describe the architecture space and provides summarized and supportive information to the main thesis including architecture in the value chain, the social framework in which architecture exists, the skills required for success, and a view of the roles and responsibilities of architects.
Improving the Structure and Content of the Requirement Statement
Authors: Scott William , Kasser Joseph E. , Tran Xuan‐Linh 
Published: November 2014

AbstractThis paper discusses the perennial problem of poor requirements and summarises an attempt to mitigate the problem using an object‐oriented approach by developing and using a software tool named Tiger Pro. Next the early results of using Tiger Pro in the classroom are discussed. The major outcome was the transition of the classroom discussion from a focus on the structure of the requirement sentence to a focus on the difficulty of writing a good requirement, or a focus on the content of the requirement sentence.The paper then considers the distinction of structure and content of a requirement and the levels of examination. This can be shown to classify the attributes of a good requirement. The classification of the attributes of a good requirement reveals that the content of an individual requirement is the focus of examination, but requirement management tools focus on the structure of the requirement set. The paper concludes by proposing a structure to capture the information in a requirement that facilitates the writing of better requirements.
Enterprise Analysis and Assessment
Authors: Roberts John J. 
Published: November 2014

AbstractAs military command and control (C2) applications evolve and become immersed within a growing net‐centric operational environment, the complexity of interactions among component C2 enterprise capabilities will rapidly increase. The adoption of a Service Oriented Architecture (SOA) approach to C2 development, coupled with the incremental fielding of Internet Protocol (IP) based Global Information Grid (GIG) capabilities, will serve as the principal catalysts for this scenario. As a result of the sheer number of anticipated web service interdependencies, analysis and assessment of C2 behavior at the enterprise scale will be both necessary and challenging. This paper will provide an initial discussion of the emerging need for such analysis and will suggest some important implementation concepts to be considered, each of which could significantly impact future enterprise systems engineering (ESE) processes.
7.6.2 “Damn the Torpedoes!” Lessons from Underwater Warfare
Authors: Fossnes Terje 
Published: November 2014

AbstractTorpedoes in underwater warfare have become an increasingly more sophisticated threat to the opponent over the past 150 years. Human ingenuity, creativity and advancements in technology have resulted in a very complex and intelligent system in its own right. This paper examines five cases where torpedo failures ended in more indignation for the weapon launchers rather than their targets, or caused severe consequences for the carrying platforms. The recent loss of the Russian submarineKurskis an example of the latter, examined in case 5. Cases from the history of torpedo failures provide cautionary tales: the failures are largely attributed to inadequate systems engineering performance and badly executed enterprise performance during different stages of the systems' life cycles. Experiences gained from these failures are applied in the torpedo industry today; intelligent enterprises have discovered that responsible systems engineering provides the key to safer product development and operations.
8.1.3 Towards an Integrated Model of Enterprise Systems
Authors: Kennedy G.A.L. , Siemieniuch C.E. , Sinclair M.A. 
Published: November 2014

AbstractAn enterprise system consists of a number of components or building blocks. It is common to use views or models of the enterprise that contain a selection of these components (dependent on the intended usage of the model). The premise is that if these views are considered systems in their own right then the total enterprise system is actually a system‐of‐systems. Difficulty arises however when the boundaries between the systems overlap ‐ it is therefore necessary to have an integrated model of the total enterprise that can cope with these overlaps and hence interactions between the systems. Within this paper there will be two main areas of work described; firstly the development of models/tools of “soft” enterprise characteristics; and secondly how these characteristics may be included in an integrated model of an enterprise system. Case studies of UK organisations (primarily within the defence industry) were undertaken to provide context to the results.
8.4.3 Architecture Scenario Analysis – Estimating the Credibility of the Results
Authors: Gammelgård Magnus , Ekstedt Mathias , Närman Per 
Published: November 2014

AbstractGood decision support requires good information. A key aspect of good information is that it is credible. Presently, architecture frameworks and methods within systems engineering often lacks support for mediating the credibility of the analyses made. This paper presents a method for enterprise architecture analyses that employs an evidential reasoning algorithm for multi‐attribute decision analysis. By doing this, the quality of the analyses as decision support is demonstrated. The method includes an assessment framework, based on established theories, for evaluating architecture scenarios functional and non‐functional qualities. The paper also presents a full scale case study where method has been employed at a large European power company.
9.4.1 Lessons Learned From Industrial Validation of COSYSMO
Authors: Valerdi Ricardo , Roedler Garry J. , Rieff John E. , Wheaton Marilee J. , Wang Gan 
Published: November 2014

AbstractThe development of COSYSMO has been an ongoing collaboration between industry, government, and academia since 2001. INCOSE provided expertise as well as a forum for collaboration between stakeholders that led to the eventual development of the model. In 2004, we provided eleven lessons learned from experiences collecting systems engineering data from six companies in collaboration with the INCOSE Measurement Working Group and the Practical Software and Systems Measurement (PSM). These lessons were focused on the development of COSYSMO that was motivated by a similar model from the software domain, COCOMO II, but was a first of its kind for systems engineering. Now that the development phase of the model is completed we take a retrospective view of lessons learned during the ongoing validation phase of the model and present new lessons learned that should help cost model developers, academic researchers, and practitioners develop and validate similar approaches. These lessons include the need for more specific counting rules, an approach to account for reuse in systems engineering, and strategies for model adoption in organizations.
Modeling Emergent Behavior for Systems‐of‐Systems
Authors: Hsu John C. , Butterfield Marion 
Published: November 2014

AbstractEmergent behaviors exist in biological systems, physical systems and human performance. Little is currently known about constructing an interoperable network of systems and the incorporation of known emergent behaviors. Definitions of emergence are introduced. The four principles of emergence are outlined and discussed. Conceptual agent‐based modeling is discussed to illustrate possible modeling approaches for identifying and assessing emergent behaviors according to the emergent principles. The agent‐based simulation will be the inputs to system‐of‐systems (SoS) architectural models. Neural network artificial intelligence may be needed to assist our understanding of the emergent behaviors during operations of SoS and the associated system architecture model development. It is recommended that the integration of agent‐based simulation and neural network methods with SysML be considered.
Everything always works the way it's supposed to right?The importance of tool integration and customization in today's development programs.
Authors: Colwell Joshua L. , Dagli Cihan H 
Published: November 2014

AbstractIn theory, the relationships between customer needs and requirements, design artifacts, and what is actually built are straight forward. In practice, it is not always as simple as one would think. Tools used to develop today's Architecture's cover a broad landscape that is complicated by a multitude of tools for requirements management, analysis and design, and development environments. Further complicating the issue can be customer mandates for usage of specific tools, toolsets, or Integrated Development Environments (IDE's). This paper describes how the overall requirements hierarchy and the traceability to design artifacts were established and implemented for a medium sized program. The integration of the requirements management tool,DOORS, withIBM's Rational Software Architect(RSA) using a third party tool,DOORKeeper, will be described. Finally, the development of customized tools for the standardization and automation of requirements and design metrics gathering will be described.
2.3.1 Proposed Modification to COSYSMO Estimating Relationship
Authors: Wang Gan , Boehm Barry , Valerdi Ricardo , Shernoff Alex 
Published: November 2014

AbstractThis paper proposes a modification to the Academic COSYSMO estimating relationship to remedy a critical limitation in its current implementation of the cost drivers. The effort multipliers defined for these drivers have an overdramatic impact on the nominal effort, which unrealistically amplifies or compresses the effort estimate. This problem severely limits its practical applications. The newly proposed parametric relationship is inspired by the COCOMO II modeling approach and based on the considerations of the life cycle impact of the cost drivers. Two additional cost drivers are also introduced. The feasibility of the new model definition is examined with a boundary analysis and validated by the analysis of historical data. This work is based on the practical implementation of COSYSMO at BAE Systems.In this paper, we present (1) an analysis of the problem with the current COSYSMO model definition; (2) a proposal of two new cost drivers added to the current fourteen cost drivers; (3) an analysis of life cycle impact of the cost drivers and a division of the drivers based on the impact; (4) the modified COSYSMO parametric relationship; (5) validation of the modified COSYSMO relationship through an analysis of historical data; and (6) conclusion and suggestion of future work.
7.2.2 Advancing Model‐Based Systems Engineering at a Small Space Agency
Authors: Piggott Stephen , Melanson Philip , Hartman Leo , Adourian Chahe 
Published: November 2014

AbstractThis paper reviews recent and current efforts to implement Model‐Based Systems Engineering at the Canadian Space Agency. A mission under concept development is being used both for demonstration purposes and also for real process design with SysML. Several support and bridge tools have been developed to help with key process issues. A number of technology issues have come out of our work, leading to a wish list of improvements we would like to see. Also, we have been dealing with organizational resistance that is preventing a wider acceptance of MBSE.
10.4.2 Application of systems engineering to optimize sustainable performance of gas export systems
Authors: Nørstebø Vibeke Stærkebye 
Published: November 2014

AbstractThis paper presents the use of systems engineering in analysis and optimization of gas export system operation. The Norwegian dry gas export system is selected as the subject for the analysis.There are two important factors that a gas export system shall satisfy. Firstly, the system shall secure that the customers receive the gas that they have ordered. Secondly, the system shall do this in as energy efficient way as possible, i.e. minimize operating costs and environmental emissions.For the operator of gas export systems it is of vital importance that equipment and pipelines in the system are optimally integrated. This will secure flexibility, capability, availability and energy efficiency of the system, and enhance understanding between different system operators.This work demonstrates how systems engineering and information models have been applied as tools for analyzing the integration in gas export systems and existing system operation, and further for developing models that optimize the energy efficiency of system operation. The impacts of gas export system operation on the society are investigated by means of a cost‐benefit analysis.
KR02 REALIZATION OF SYSTEMS ENGINEERING FOR THE FUTURE
Authors: Bausman Karen. B. 
Published: November 2014

AbstractIn the last five years, there have been numerous United States Department of Defense (DoD) initiatives to “Revitalize Systems Engineering.” In each case, a declaration identified that Systems Engineering was not broken, just not consistently applied! These initiatives targeted a quick turnaround of the problems during systems development and sustainment. These types of “fixes” usually take at least five years to show up and there is little evidence that existing systems, currently in development or sustainment, have shown any significant measurable improvements. To define what the implementation of systems engineering in the future will need, there must first be an evaluation of the SE issues of today; these issues need greater analysis and expansion. This paper will present these SE issues, and then recommend potential actions to resolve some of them.
KR05 Concepts of Modularity in Systems Engineering and Developmental Biology
Authors: Crabtree Timothy , Dagli‐UMR Cihan 
Published: November 2014

AbstractSystems Engineering and Systems Science are separate fields with some common ground. Systems Engineering generally deals with the creation of purpose‐built manmade systems. Its practitioners generally have engineering backgrounds. The prominent professional organization for Systems Engineering is INCOSE. The term “Systems Science” is often used to describe an interdisciplinary inquiry into the nature of complex systems, whether manmade or natural. Its practitioners may have backgrounds in biology, chemistry, social science, natural philosophy or economics, to name a few fields. A prominent professional organization for Systems Science is the International Society for Systems Science (ISSS). Systems Engineering and Systems Science both have the intent of being able to support informed interactions and decisions that affect the future. As an example of the common ground, expressions of the concept of modularity are compared from the standpoints of Systems Engineering and Evolutionary Biology.
1.2.2 A Risk‐Driven Process Decision Table to Guide System Development Rigor
Authors: Boehm Barry , Lane Jo Ann , Koolmanojwong Supannika 
Published: November 2014

AbstractThe Incremental Commitment Model (ICM) organizes systems engineering and acquisition processes in ways that better accommodate the different strengths and difficulties of hardware, software, and human factors engineering approaches. As with other models trying to address a wide variety of situations, its general form is rather complex. However, its risk‐driven nature has enabled us to determine a set of twelve common risk patterns and organize them into a decision table that can help new projects converge on a process that fits well with their particular process drivers. For each of the twelve special cases, the decision table provides top‐level guidelines for tailoring the key activities of the ICM, along with suggested lengths between each internal system build and each external system increment delivery. This paper elaborates on each of the twelve cases and provides examples of their use.
2.2.1 Towards a Holistic, Total Engineering Cost Model
Authors: Wang Gan , Turnidge Jon , Shernoff Alex , Valerdi Ricardo 
Published: November 2014

AbstractIn this paper, we explore a new approach for a unified and interdisciplinary parametric model for estimating the total engineering effort in developing and delivering a software‐intensive complex system. We begin by reviewing some of the limitations of using existing engineering discipline‐focused tools for estimating total engineering cost and by articulating the benefits of such a holistic model. Applying a two step method combining heuristic analysis and data validation, we propose three hypotheses to expand the basic cost estimating relationship of COSYSMO, a systems engineering model, to the total engineering scope by including software size drivers. The implementation of the hypotheses and the validation approach are also discussed. We conclude the discussion by outlining the future work required to realize such a model and to apply it to supporting successful system development endeavours.
3.3.3 A Standard Approach To Find Out Multiple View Points To Describe An Architecture Of Social Systems ‐ Designing Better Payment Architecture To Solve Claim‐Payment Failures Of Japan's Insurance Companies ‐
Authors: Shirasaka Seiko 
Published: November 2014

AbstractAccording to the definition of “System” in various standards and handbooks, a system does not necessarily have hardware‐software components. This means that a social system without hardware‐software elements is a kind of system. However, systems engineering techniques are not directly applied to define a solution of a non‐technical social system's problems. In this paper, we propose a standard approach to find out multiple view points to describe architecture, because the view points are one of the most important aspects of architectural design activities. And also we show one example that we applied our proposed approach to non‐technical social system: insurance system. It proved to be positive in applying architectural design technique with appropriate view points to design social system architecture.
4.3.2 Analysis of Cognitive Work for Large‐Scale Socio‐Technical Systems
Authors: Lintern Gavan 
Published: November 2014

AbstractLarge‐scale socio‐technical systems are cognitive systems and function as such through the individual and collaborative cognitive work of the humans in the system. As major systems have become more information intensive and more distributed, the difficulty of addressing cognitive challenges has become a troubling area for systems acquisition. The discipline of cognitive systems engineering has methods and tools that can be brought to bear on this problem. In this paper I outline two analytic frameworks that have been developed within cognitive systems engineering for design of cognitive work and illustrate how their tools and methods can be deployed to develop the cognitive content of products currently required by the US defense acquisition management framework. The strategy I propose for development of cognitively‐relevant functionality of large‐scale systems is to replace inadequate methods currently in use with the more effective and efficient methods from cognitive systems engineering.
6.2.4 On Systems Architects and Systems Architecting: some thoughts on explaining and improving the art and science of systems architecting
Authors: Sillitto Hillary G 
Published: November 2014

AbstractISO's process to adopt the IEEE 1471 standard on architecture descriptions has revealed of the order of 130 standards concerning or relating to architectures and architecting. Within the “enterprise architecture” theme alone, different people use the term to refer to mean quite different things: the “architecture of the enterprise as a system”; the enterprise context for the enterprise IT system; or the architecture of the enterprise IT system itself. A focus on tools and methods has led to confusion between the creative activity of “architecting”, by which I mean making or exposing the key strategic decisions about the purpose, organisation, behaviour and critical design features of the system, and the analytical and descriptive activity of architecture modelling, which supports and captures the results of architecting. The INCOSE UK Architecture Working Group established a “belief systems” methodology to explore and seek to reconcile the many conflicting views on architecting This paper expands on the views presented by the author at the IS08 Architecture panel session in an effort to identify and communicate a better understanding of the fundamental skills, principles, philosophy and approach underpinning effective systems architecting. It seeks to improve their integration by focusing on “purpose, context and process” of architecting with the perspective that “hard systems exist inside soft systems”, and to show that “lean pull” allows architecting to focus on the intended use of its products rather than adherence to process standard or frameworks.
7.1.1 Survivability Design Principles for Enhanced Concept Generation and Evaluation
Authors: Richards Matthew G. , Hastings Daniel E. , Ross Adam M. , Rhodes Donna H. 
Published: November 2014

AbstractSurvivability is the ability of systems to minimize the impact of finite‐duration disturbances on value delivery. Previous work developed and tested a set of seventeen survivability design principles spanning susceptibility reduction, vulnerability reduction, and resilience enhancement strategies. In this paper, a process is described for applying the survivability design principles to the concept generation phase of Multi‐Attribute Tradespace Exploration, a system analysis methodology integrating decision theory with model‐based design. Applying the design principles serves both to augment the creativity of system designers by ensuring consideration of a broad tradespace of design alternatives and to quickly screen a large number of candidate design variables before proceeding to concept evaluation.