bluuebunny/crossref_metadata_2025 huggingface dataset:
Improving the Structure and Content of the Requirement Statement
Authors: Scott William , Kasser Joseph E. , Tran Xuan‐Linh
Published: November 2014

This 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

As 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

Torpedoes 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

An 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

Good 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

The 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

Emergent 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

In 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

This 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

This 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

This 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

In 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

Systems 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

The 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

In 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

According 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

Large‐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

ISO'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

Survivability 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.
8.3.2 Systems Engineering meets Knowledge Management: Introducing a ‘System of Knowledge Management Approaches’
Authors: Brown Samantha F , Ragsdell Gillian
Published: November 2014

This paper highlights the complementarity between systems engineering (SE) and knowledge management (KM); in doing so, it offers a platform from which the development of both disciplines could be accelerated. By drawing attention to some of the challenges in the practice of SE and, in keeping with Martin (2002), the authors suggest that embedding relevant KM practice within SE practice may assist ‘traditional’ SE in meeting the demands of engineering current and future systems. Specific attention is paid to the importance of creating a knowledge sharing culture in SE practice and guidance is offered as to knowledge sharing methods which might be used effectively in particular SE settings.

The paper begins by identifying some of the challenges that SE faces in contemporary practice. The focus then moves on to knowledge and its management. After an introduction to the distinctions between data, information and knowledge, and to a representative cycle of KM, emphasis is placed on the process of knowledge sharing and the characteristics of a knowledge sharing culture. Discussion moves on from the cultural dimension of knowledge sharing and into the contexts and environments of SE practice. Jackson and Keys' (1984) System of Systems Methodologies (SofSM) is introduced to trigger a taxonomical theme for the rest of the paper. In a similar way that Flood and Jackson (1991) link the SofSM to problem contexts, the authors overlay their taxonomy of SE contexts with knowledge sharing methods so as to guide the SE practitioner in an effective matching of method with context. The paper closes with reflections on the potential reciprocal relationship between SE and KM.
9.1.3 Development of a Framework of Research Topics in Systems Engineering
Authors: Ferris Timothy L.J.
Published: November 2014

This paper describes the method and result of developing a framework of research topics in systems engineering. The framework of research topics was developed as part of a project to develop a vision for research in systems engineering for use by INCOSE. This paper also describes the relationship of the framework of research topics and the description of the future of systems engineering presented in the INCOSE document: Systems Engineering Vision 2020. This paper shows significant agreement between the structure of systems engineering described in the Vision 2020 document and the framework developed in the vision for research in systems engineering. The processes used to develop both structures of ideas were conducted independently and were quite different. The agreement between them demonstrates the strength of the conclusion.
10.2.1 Implementing and Standardising Systems Engineering Practices within a Global Corporation
Authors: Berglund Fredrik , Böckmann Carsten , Cuklev Sasko
Published: November 2014

Developing new products is in many respects the process of identifying and envisaging user needs and bringing those needs into life in a cost‐efficient manner, either utilizing existing technologies and solutions, or developing new ones. Product developing organisations are constantly challenged since new products must exceed expectations on quality standards in form, fit, and function – and that they must stand out from competition. This requires people with knowledge in many areas. Consequently, it is a multi‐disciplinary process involving many parallel activities, such as product planning, design, production, marketing and after‐sale.

Systems Engineering (SE) has become increasingly important in these organizations in order to manage the shear complexity of managing large scale development projects and secure the quality standards for all emergent properties of a system. The main driver for introducing SE is that the complexity and interconnectedness of systems continues to grow and the growing shift of focus to the complete offer rather than the product itself. However, there exist little research summarizing experiences of implementing SE, and there remain uncertainties as to how SE should be tailored to specific settings in order to add value to a development organization. Especially, focus needs to be put on managing the complexity of creating product variety.

This paper summarises our experiences from the continuous work to implement and standardise Systems Engineering practices within a global corporation in the transport solution industry. This includes a review of reports on SE implementations, a short description of the Volvo Group, and a summary of our experiences when implementing SE at various units and organisational levels.
Agent‐Based Modeling the Emergent Behavior of A System‐of‐Systems
Authors: Hsu John C. , Clymer John R. , Garcia Jose , Gonzalez Efrain
Published: November 2014

Net‐Centric Operations (NCO) is operated on a System‐of‐Systems (SoS) communication environment. Emergent behavior is one of the five SoS characteristics. Layered SoS architectures start from the top SoS‐level containing emergent behavior. Conceptual agent‐based modeling was presented to simulate the four principles of emergence. The simulations covered the condition of emergence, non‐linear behavior and coupling relationship between agents. The four principles are interrelated. The emergent behavior has impacts on traditional systems engineering process. Neural network artificial intelligence may be needed to assist the understanding of emergent behaviors for architectural model development. Agent‐based modeling needs further development and should be integrated with neural network and SysML.
10.4.1 Architected Agile Solutions for Software‐Reliant Systems
Authors: Boehm Barry , Lane Jo Ann , Koolmanojwong Supannika , Turner Richard
Published: November 2014

Systems are becoming increasingly reliant on software due to needs for rapid fielding of “70%” capabilities, interoperability, net‐centricity, and rapid adaptation to change. The latter need has led to increased interest in agile methods of software development, in which teams rely on shared tacit interpersonal knowledge rather than explicit documented knowledge. However, such capabilities often need to be scaled up to higher level of performance and assurance, requiring stronger architectural support. Several organizations have recently transformed themselves by developing successful combinations of agility and architecture that scale up to projects of up to 100 personnel. This paper identifies a set of key principles for such architected agile solutions for software‐reliant systems, and illustrates them with several case studies.
1.4.3 Simple SE Methods Deployed in Revitalizing the Nuclear Post‐ Irradiation Examination Capability for the Idaho National Laboratory
Authors: Zirker Larry R. , Hamelin R. Douglas , Braase Lori
Published: November 2014

The “crown jewels” of nuclear energy research facilities (i.e., hot cells, analysis systems, and scientists) have been centered at the Idaho National Laboratory for over 40 years, but in recent years, emphasis and funding for nuclear fuel research and development have declined to adversely affect the readiness and effectiveness of research facilities and equipment. Conversely, the current national nuclear renaissance forces the need for immediate enhancements in facilities, equipment, capabilities, and staff for the postirradiation examination (PIE) of nuclear fuel. PIE characterizes the “burn‐up” and structural integrity of fuel elements and defines the effectiveness of new fuels/alloys in search for optimum fuel burn‐up and alloys for current and next generation nuclear reactors. This paper details how a team of system engineers adapted simple system engineering tools and techniques for a customer unfamiliar with the power and effectiveness of system engineering, to achieve project success.
2.3.2 An Enterprise Systems Engineering Framework
Authors: Martin James N
Published: November 2014

Traditional systems engineering (SE) is performed on a development project with only one or a few related systems being developed. Enterprise SE, on the other hand, must deal with deciding among many enterprise opportunities that the enterprise projects will work on. This entails several processes that are not provided for in traditional SE practice. An Enterprise SE Framework was developed to characterize the full scope of SE at the enterprise level.1 This framework was used to evaluate several case studies as part of my doctoral dissertation. This evaluation focused on how they used knowledge modeling techniques identified in my dissertation for development of an enterprise architecture.2
3.3.2 Polymorphic System Architecture
Authors: Bryson Jeff
Published: November 2014

The complexity of tomorrows problems will be far greater then problems we face today. This complexity will only increase the importance of systems engineering and systems architecture activities. As the value of the activities rise, the cost of the activities must fall. Neither a Multi‐year analysis and development schedule nor a short term schedule with a high risk of failure will be acceptable solutions. The solution for solving these complex problems will be to move systems engineering and architecture artifacts from the Non‐Recurring Engineering cost over head to reusable company assets. A Polymorphic System Architecture (PSA) is one way of achieving this goal.

Run‐Time polymorphism (RTP) has been used in the software community for over 20 years to satisfy dynamic reconfiguration, plug‐n‐play, extensibility, and system redundancy requirements. RTP is also used to construct software Systems of Systems. Systems engineers now have the same requirements applied to system architecture. A PSA utilizes the same software technology but applies it to the system architecture (Bryson 2009). The goals of using a PSA are:

Reduce the complexity of the system architecture

Satisfy functional requirements within the system architecture

Define an architecture that has the potential to mature over time

Move the system architecture from cost overhead artifacts to company assets

Create an architecture library of reusable artifacts that can be reused to solve new problems
4.4.3 A Study of the Effects of Professional Society Development on the Advancement of the Profession: The Systems Engineering Example
Authors: Valerdi Ricardo , Deonandan Indira
Published: November 2014

The advancement of professions depends on global collaborations. Professional societies are enablers to this growth in a multitude of ways. Publication outlets to disseminate new ideas, collaboration mechanisms to form communities of interest and conferences to enable networking and recognition all play critical roles in defining and advancing disciplines. In response to this, INCOSE has made a conscious decision to hold its flagship event, the annual Symposium, at strategic locations around the world. At the moment, the majority of INCOSE members, approximately sixty percent, are based in the U.S. although the diversity of membership has increased over time. In this paper, we seek to analyze the impact of hosting a symposium in a particular location through the use of six retrospective case studies to determine how a professional society such as INCOSE can impact the systems engineering profession. We investigate the consequences of hosting a symposium in a specific region and analyze the impact of the symposium on the advancement of the profession of Systems Engineering
5.1.0 The Future of Knowledge Management in INCOSE
Authors: Forsberg Kevin , Roedler Garry , Ring Jack , Hodgson Ralph , Sillitto Hillary , Jorgensen Raymond
Published: November 2014

The goal of the Knowledge Management Working Group (KMWG) is to determine how technical INCOSE knowledge management needs are currently being met, and what the new state(s) should be. Input from the panel members, and most importantly from the audience for this panel discussion, will help shape the direction and future contributions of the INCOSE KMWG.

One of our panelists, Jack Ring, says, “I claim that the Future Direction of Knowledge Management in INCOSE is grossly under‐conceptualized. Three concepts that may merit further dialogue are:

We could get on with developing and sharing knowledge about modeling stochastic systems, non‐deterministic systems, agent‐aided design and even generative/autocatalytic systems,

The engine for the G2SEBoK will be the next generation SE tool. Things like CORE, SysML‐oriented tools, OpEMCSS, etc., become plug‐ins,

The G2SEBoK should do more than talk ABOUT systems praxis. It should give examples of the work products. These should be real examples that are prompted by posing typical problems, then posting work products as proposed by participants.

Currently the final product from most INCOSE Working Groups is a printed document (which is also available in electronic form). Should this change?

Another panelist, Raymond Jorgensen, says: “Wiki technologies have provided an excellent forum for encouraging improved communication and sharing across the community. At Rockwell Collins, a Wiki environment is being used to encourage sharing best practices across the enterprise. Instead of different business areas publishing unique practices in stale ”PDF“ files on local networks, one enterprise environment is being used to host the collective enterprise knowledge of best practices in engineering. Similar techniques could be applied at INCOSE.”

If a Wiki is so good, why did the SEHv3.1 Wiki lay dormant on the INCOSE web site for over two years? Is a Wiki suitable for the INCOSE environment? If so, who will control it?
5.4.2 Ontology‐Enabled Traceability Mechanisms
Authors: Austin Mark , Wojcik Cari E.
Published: November 2014

This paper describes new models and mechanisms for ontology‐enabled traceability where design concepts are inserted between the already connected requirements and engineering objects Looking ahead, we envision that ontology‐enabled traceability will play an important role in the development of network‐enabled platforms for analysis, design, and early validation and verification of information‐age engineering systems.
7.2.1 Robust Decision Making
Authors: Dieckmann Christopher A
Published: November 2014

The Idaho National Laboratory is funded through the U.S. Department of Energy Office of Nuclear Energy and other customers who have direct contracts with the Laboratory. The people, equipment, facilities, and other infrastructure at the laboratory require continual investment to maintain and improve the laboratory's capabilities. With ever tightening federal and customer budgets, the ability to direct investments into the people, equipment, facilities, and other infrastructure that are most closely aligned with the laboratory's mission and customers' goals grows increasingly important. The ability to justify those investment decisions based on objective criteria that can withstand political, managerial, and technical criticism also becomes increasingly important. The Systems Engineering tools of decision analysis, risk management and roadmapping, when properly applied to such problems, can provide defensible decisions.
7.3.2 Frictionless, Predictive Enterprise Engineering
Authors: Mott Michael R. , Amaba Ben , Cantor Murray
Published: November 2014

“It would be naive to think that the problems plaguing mankind today can be solved with means and methods which were applied or seemed to work in the past.”

—Mikhail Gorbachev
7.4.1 Contributions Towards Unifying System Semantics
Authors: Lawson Harold “Bud” , Persson Mats
Published: November 2014

What is it that characterizes a system? Certainly as systems engineers this is a vital question to ask. While most will claim that it is a question of perspective (viewpoint and view), this does not help us in identifying key aspects that can lead to useful discipline independent semantics for systems. There have been several system experts that have expressed their perspectives in this regard. The current paper identifies and utilizes some of these contributions and then identifies a key set of concepts and principles as well as a unifying mental model collectively called the System Survival Kit. The survival kit generically identifies the relationship between situation systems, respondent systems and system assets in a manner that can be applied to any system related situation. These contributions are based upon experiences in teaching people from many disciplines to “think” and “act” in terms of systems.
7.4.3 Ontology‐driven Requirements Engineering —A case study of OntoREM in the aerospace context
Authors: Kossmann Mario , Odeh Mohammed
Published: November 2014

OntoREM is an Ontology‐driven Requirements Engineering Methodology (process, methods and tools) that aims to improve the quality of requirements while also reducing the time and cost needed to develop, maintain and re‐use requirements. In order to evaluate the potential of such an ontology‐driven approach, OntoREM was applied to the aircraft operability (AO) domain and generic AO requirements for the wing design were developed. These requirements were subsequently compared to corresponding AO requirements that were developed for the wing design of two different development contexts for which a traditional requirements process was applied. Similarly, the elapsed process times to develop the requirements were compared, as measured for OntoREM and estimated for the traditional requirements process. The preliminary outcomes of this case study strongly suggest that the application of the OntoREM approach led to better quality requirements in considerably less time and hence at less cost per requirement. Further saving potential exists through increasing automation of OntoREM. In addition, there are several, additional advantages of applying this methodology that, for example, enable the reuse of domain ontologies including requirements in even less time i.e. at lower cost in the future, not to mention the advantages of explicitly capturing domain knowledge. An industrial scale pilot application of OntoREM has been proposed in order to mature the methodology and its underlying IT infrastructure for the anticipated global use in the context of entire aircraft development programmes in order to prepare for full integration into the Airbus Product Development Process (PDP).
8.2.1 On the Need for a System Need Statement
Authors: Ryan Michael. J.
Published: November 2014

This paper proposes that, since the system need statement is the antecedent of all subsequent system requirements, it should possess the same attributes that are required of its progeny, including taking the form of a single sentence. A process to guide the development of a system need statement is also proposed.
8.3.1 Certainty, Risk and Gambling in the Development of Complex Systems
Authors: Pickard Andrew C , Nolan Andrew J , Beasley Richard
Published: November 2014

One of the few things certain about development of complex systems is the requirements for the system will remain uncertain late into the development program. Even though we recognize this, why do many programs assume that requirements will not change (gambling) or treat requirement change as a risk rather than a certainty? An analysis of gas turbine engine control systems requirements shows that typically 50% will change between Critical Design Review and Entry into Service. This requirements uncertainty manifests as technical risk to the programme. This paper evaluates the impact of not managing these uncertainties and describes how applying Systems Engineering principles can reduce this effect.

Design iterations produce rework, and without technical risk management, ~50% of the effort will be wasted in producing unacceptable designs. In turn, correction of these errors will create more rework. This results in much iteration and cumulatively twice as much work is required to produce a mature design. With technical risk management, less than 10% of the design effort will result in rework, giving a mature product with far less iteration.

Investigation into the source of the product development lifecycle problems indicates many escapes occur during requirements definition and review. Around twice as many changes are driven by errors in requirement definition by the developer, compared to customer‐driven requirements changes. In addition, many of these escapes are detected later in the product development lifecycle than they could have been found, resulting in further escalation of the cost of product development. This paper compares and contrasts the root causes for these escapes during system, software and hardware development and looks at the differences in consequences.

The role of the Systems Engineer is critical in addressing these problems. In addition to effective elicitation of requirements from stakeholders, the Systems Engineer must manage volatility and apply robust design principles to protect against the impact of requirements changes. The Systems Engineer must flow requirements effectively from system to sub‐system, from sub‐systems to components and provide the “glue” that results in the integrated system being more than the sum of its parts.

Some tools and techniques are presented to help Systems Engineers identify probable sources of uncertainty and provide effective mitigations. An approach is also presented for assessing the technical risk management “maturity” of a project, based upon ‘best practice’ approaches taken from those projects achieving low levels of engineering scrap and rework during their development phase.
10.3.2 A SYSTEMS APPROACH TO ARCHITECT COHERENT SYSTEM OF SYSTEMS CAPABILITIES
Authors: Weng Yeoh Lean , Seng Chia Ban
Published: November 2014

Architecting of coherent system‐of‐systems (SoS) capabilities is complex due factors such as the diverse range of stakeholders and evolving requirements. Left to themselves, these individual stakeholders at the system requirements definition and implementation stages may demand for optimization of individual systems of their interests. This would collectively result in local optimization at the system‐level at the expense of SoS‐level or even enterpriselevel effectiveness. This paper proposes an approach to coherently architect SoS capabilities. This approach is premised on the assumption that a “top‐down” leadership approach is applicable to establish the required reporting structures and relationships in the technical community. The approach attempts to weave in the considerations of limited shared resources and common technological solutions across the national defense enterprise into the process of architecting an SoS that would fulfil a large‐scale mission capability.
11.3.1 Systems Engineers' Perceptions on the Adequacy of Project Management Methods for Systems Engineering Management
Authors: Sharon Amira , Dori Dov , de Weck Olivier L.
Published: November 2014

Systems Engineering Management (SEM) is being developed hand in hand with the maturation of systems engineering, emphasizing the management of the joint project‐product ensemble.Most SEM applications use traditional Project Management (PM) methods and tools, including Gantt chart, PERT, Critical Path Method, System Dynamics, Earned Value Method, and Design Structure Matrix. Object Process Methodology has also been recently studied as a vehicle for Project‐Product Lifecycle Management. We examine how systems engineers perceive the extent to which PM methods support SEM. We verified that project and product are viewed as two complementary facets of SEM, and that certain PM methods address both domains better than others with respect to particular examined factors.
11.4.1 An Experience Report at Thales Aerospace: “The Lean Journey”
Authors: Baujard Michel , Gilles Harry , Terrien Olivier
Published: November 2014

This experience report illustrates the implementation of ‘Value Streams’ in Systems Engineering and Product Development at Thales Aerospace. It explains how non‐added value elements are eliminated thanks to these value stream mappings.

This paper is based on one of our real experiences. Therefore, it could be considered as a concrete example of Lean Principle 2 of Lean Enablers for Systems Engineering developed by the INCOSE Lean Working Group:

This experience report describes an achieved example of value stream mapping and its positive impacts on Systems Engineering. It also offers an overview of this pragmatic methodology and the training courses for implementation. Current worldwide deployment status and achievements in terms of performances and customer satisfaction are also provided. Finally key success factors and upcoming steps are described to further improve the performance.

“have cross functional stakeholders work together to build the agreed value stream”

“use formal value stream mapping methods to identify and eliminate Systems Engineering and Product Development waste, and to tailor and scale tasks”.

image

This experience report describes an achieved example of value stream mapping and its positive impacts on Systems Engineering. It also offers an overview of this pragmatic methodology and the training courses for implementation. Current worldwide deployment status and achievements in terms of performances and customer satisfaction are also provided. Finally key success factors and upcoming steps are described to further improve the performance.