bluuebunny/crossref_metadata_2025 huggingface dataset:
3.2.2 Enabling Economics‐Driven Systems Engineering Through Reusable Software Architectures and Components
Authors: Selby Richard W.
Published: November 2014

Economics‐driven systems engineering integrates system design principles with measurement‐based analyses of value, options, and tradeoffs. This study helps enable economics‐driven systems engineering by describing an example of measurement‐based analysis of software reuse in large‐scale systems. Software reuse enables developers to leverage past accomplishments and facilitates significant improvements in software productivity and quality. Software reuse catalyzes gains in productivity by avoiding redevelopment and gains in quality by incorporating components whose reliability has already been established. The purpose of this study is to characterize software reuse empirically by investigating one development environment that actively reuses software. Twenty‐five software systems ranging from 3000 to 112,000 source lines have been selected for analysis from a NASA systems development environment. The amount of software either reused or modified from previous systems averages 32% per project in this environment. Non‐parametric statistical models are applied to examine numerous development variables across the software modules in the systems. This research focuses on initial results and graphical characterizations of the data. Four classes of software modules are analyzed: (a) modules reused without revision, (b) modules reused with slight revision (< 25% changes), (c) modules reused with major revision (≥ 25% changes), and (d) newly developed modules. The modules reused without revision had the fewest faults, lowest fault correction effort, and lowest fault densities. In conclusion, we outline future research directions that build on these strategies and ideas.
4.4.1 Rule‐Based Design Reviews
Authors: Gilb Tom
Published: November 2014

Design reviews would benefit from the support of Specification Quality Control (SQC). By the use of SQC with a set of relevant design review rules, it should be possible to ensure prior to a design 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.

In addition, this paper outlines the impact of Evolutionary Project Management (Evo) on the design review process.
4.4.2 Measurement‐Driven Systems Engineering Using Six Sigma Techniques to Improve Software Defect Detection
Authors: Selby Paige C. , Selby Richard W.
Published: November 2014

System developers and managers continually strive to identify, undertake, and realize improvements in system development methods. Measurement‐driven systems engineering guides the identification of improvement opportunities and enables the quantitative evaluation of progress and benefits. Six Sigma techniques provide a structured approach for using measurement‐driven methods to decrease the variances and shift the means of user‐defined metrics such as defect densities, development cycletimes, and resource expenditures. This research investigates the effectiveness of software defection detection using peer reviews across 12 system development phases on 14 large‐scale systems. This study analyzes 3418 defects from 731 peer reviews and benchmarks the defect injection and detection performance across the 12 system development phases. Six Sigma techniques including the define‐measure‐analyze‐improve‐control (DMAIC) method, root cause analysis, and control charts helped achieve inphase detection of 95 percent of defects and realize over 50 percent improvements in defect densities and closure cycletimes for certain peer review types.
4.4.4 Systems Architecture: A View Based on Multiple Impacts
Authors: Gilb Tom
Published: November 2014

In order to properly support the systems engineering process, the systems engineering profession needs to consciously adopt a more productive view of systems architecture. Many existing definitions of systems architecture are too narrow: they focus too much on ‘structure.’ The focus needs to be shifted to the impact on requirements.
5.4.3 Usability of formal verification on EFFBD models: Applying Petri nets to Systems Engineering issues
Authors: Seidner Charlotte , Lerat Jean‐Philippe , Roux Olivier H.
Published: November 2014

Assessing the safety and the dependability of a system is one of the systems engineer's main targets. Formal tools, however powerful they may be to meet these issues, are often too cumbersome and complex to use. In this paper, we show that efficient formal methods can be used on high‐level models used in Systems Engineering to achieve some verification and validation processes. We give an overview of ongoing work on the translation of EFFBD‐like models to time Petri nets, using model transformation and meta‐modeling. We also present some encouraging results obtained with a prototype translation tool.
6.2.1 From Foresight to Insight: A Strategic Alignment Model for New Product Development
Authors: Lee Hei‐Kuang , Liu Chih‐Ming , Lee Meng‐Hua
Published: November 2014

The most important roles of strategic management concern about the right “attention” and the right “execution.” Based on this idea, the research question of this study is “How to align the strategy of a company to new product development?” This paper will focus on the longitudinal deployment of strategy and try to provide a solid methodology of strategic alignment to penetrate the multiple management levels of a company. Based on Ansoff's gap analysis model of strategic management, roadmapping techniques of management of technology, Work Breakdown Structure of project management, a Strategic Alignment Model for New Product Development (SAM‐NPD) is proposed in this study. A Six‐Echelon model, including industry, market, product, technology, intellectual property and cost structure analyses, is also developed for guiding the implementation of the SAM‐NPD model. Finally, a longitudinal case study of the successful application of this methodology in Taiwan is illustrated. Keywords: strategic management; strategic alignment model for new product development; SAM‐NPD; six‐echelon model.
6.2.2 Requirements for Outsourcing
Authors: Gilb Tom
Published: November 2014

Outsourcing differs from other development because there is bound to be a contractual relationship, probably a geographic distance, a different sense of loyalty, language misunderstandings, cultural differences, reluctance to speak up to the client – and many other associated problems. Good requirements are always a problem, but outsourcing increases the problems, and makes even great demands on the requirements specification. The payoff for doing good requirements is greater, and the penalty for not doing them is more threatening.

I am going to argue that we need to make use of far more explicit background specification for each requirement, a page or more of specification for each requirement. I will argue that this is a necessary investment – because failure to do so will probably cost far more – sooner or later. I will argue that failure to be more detailed than normal will be counted in the clients disfavor in any legal proceedings trying to determine responsibility for failure of the project.
7.1.2 Analysis of Singapore's 1991 Strategic Economic Plan Using the Large‐Scale Systems Engineering Framework
Authors: Seng Eng
Published: November 2014

Planning for large‐scale systems such as a country's economy is a huge undertaking and fraught with difficulties. This paper explores how such an undertaking could be managed using the large‐scale systems engineering framework. It uses the Singapore's Strategic Economic Plan of 1991 to retrospectively examine how well the large‐scale systems engineering framework could have measured up to such a Plan. It was found that such a framework is effective in understanding the complexities of and planning for such a large‐scale system.
7.3.0 Panel 7.3.0: SysML Early Applications and Lessons Learned
Authors: Friedenthal S. A. , Brookshier D. , Obeid P. , Peak R. , Steiner R.
Published: November 2014

SysML is a general purpose systems modeling language that was adopted by the OMG in May 2006 (announced in early July). SysML is considered a key enabler to transition to model based systems engineering. The panel members will present what they have learned from their early experiences in implementing SysML from their diverse viewpoints, including end‐user, tool vendor and academic perspectives. Topics will include:

End user perspective: Highlight industry experience on projects including What works, What methodologies are being employed, What is difficult, What is the response from the various stakeholders (customer, PM, software and hardware developers, testers) and What are suggested areas of improvement?

Vendor perspective: Highlight tool vendor experiences including What SysML features are most requested, What has been difficult to implement, How well does SysML integrate with UML, What are suggested areas of improvement?

Academia perspective: Highlight Academia experiences with SysML including Where does SysML fit in the curriculum and in research, What is difficult to teach, What is the response from students and faculty, What do you feel they are learning, and What are suggested areas of improvement (both from an educational perspective and a modeling language research perspective)?

The moderator will also stimulate questions that cross the various viewpoints.
7.4.2 Development and Application of Abstract Relation Types for Use in Systems and System‐of‐Systems Design and Evaluation
Authors: Simpson Joseph J , Dagli Cihan , Miller Ann
Published: November 2014

Abstract relation types (ART) are developed to represent, describe and establish a computational framework for a system. An abstract relation type is closely related to and builds upon two fundamental ideas. The first idea is the binary relation and structural modeling techniques developed by John N. Warfield. The second idea is the concept of abstract data types. These two ideas are combined to create an abstract relation type that provides a structured representation and computational method for systems and system components. The complete system description approach is based on six abstract relation types: context, concept, functions, requirements, architecture, and test (CCFRAT). When combined with digraphs and other graphical representations of the matrix form, ART provides a powerful tool for the communication of complex system interactions to large system design teams.
7.6.3 Case Study in Establishing Systems Engineering Principles: One Organization's Experience
Authors: Reutzel Adria Liszka
Published: November 2014

Even within a well‐established systems engineering organization, formalizing the practice of systems engineering can be an arduous task. This paper describes one organization's effort to start this formalization by defining and documenting the very foundation of its practice: its systems engineering principles. Topics include the process for developing principles (augmenting organizational guidance with industry best practices), the final form of the principles (justifying terminology), and the connection to broader formalization efforts (associating the principles diagram to the systems engineering logo). The principles are divided into four categories that tie mainstream systems engineering definitions together: Stakeholder, Systems Engineer, Problem, and Solution.
9.4.3 Defining System Changeability: Reconciling Flexibility, Adaptability, Scalability, and Robustness for Maintaining System Lifecycle Value
Authors: Ross Adam M. , Rhodes Donna H. , Hastings Daniel E.
Published: November 2014

Designing and maintaining systems in a dynamic contemporary environment requires a rethinking of how systems provide value to stakeholders over time. Classically, two different approaches to promoting value sustainment may include developing either alterable or robust systems. The first accomplishes value delivery through altering the system to meet new needs, while the second accomplishes value delivery through maintaining a system to meet needs in spite of changes. The definitions of flexibility, adaptability, scalability, and robustness are shown to be different parts of the core concept of “changeability,” which can be described by three aspects: change agents, change effects, and change mechanisms. Cast in terms of system parameter changes, flexibility and adaptability are shown to relate to the origin of the change agent (external or internal to a system boundary respectively). Scalability and robustness, along with the additional property of modifiability, are shown to relate to change effects. The extent of changeability is determined by the number of possible change mechanisms available to the system as accepted by decision makers. Creating changeable systems, which can incorporate both classical notions of alterability and robustness, empowers systems to maintain value delivery over their lifecycle, in spite of changes in their contexts, thereby achieving value robustness to stakeholders over time.
10.1.2 Simple Yet Profound Enterprise Impact
Authors: Mooz Hal , Forsberg Kevin
Published: November 2014

We of The Center for Systems Management are continuously frustrated to find that many enterprises and organizations view process and process improvement as something that must be done to compete (SEI CMMI Level Three, ISO 9000, etc.) rather than as cost efficient best practices that produce substantial return on investment. In fact, some venture capitalists have stated to us “we want no process as it will inhibit our creativity.” Other enterprises state that they want to take it slow and easy with process adoption lest they bog down in the minutia of implementation.

Unfortunately, these misperceptions are usually rooted in prior experiences where process improvement consisted of lengthy documentation and verbiage that ended up collecting dust on the bookshelf rather than being faithfully practiced by the enterprises' staff to produce exemplary and consistent results.

Some of the most beneficial processes are extremely simple to implement yet they can produce high value results to the quality and safety of the activity. This paper explores a few of a family of Simple Yet Profound Management Techniques that if faithfully implemented will improve an enterprises performance and return on investment. The ultimate goal would be to have these processes instilled in a systemic enterprise culture.
10.4.0 Panel 10.4.0: U.S. OSD Systems of Systems Engineering Guide: Status Report & INCOSE Support
Authors: Baldwin Kristen , Dickerson Charles , Meilich Abe , Osterholz John , Touchin Malcolm , Bratt Steve
Published: November 2014

In May 2006, a task was issued by the U.S. Deputy Under Secretary of Defense for Acquisition and Technology (DUSD (A&T)) to develop a Systems of Systems Engineering Guidebook. The Office of the Secretary of Defense (OSD) convened a small group of Government, Industry and Academia, and selected the Stevens Institute of Technology to lead the project. During the summer and autumn of 2006, the International Council on Systems Engineering (INCOSE) was honored to be invited to provide a global representation of the systems engineering community in support of the OSD writing of a Systems of Systems, Systems Engineering (SoS SE) Guide.

On 22 December 2006 the draft SoS SE Guide, version 0.9, was released for review and use by the systems engineering community. Industry and academia have been asked to submit their comments as part of the effort to pilot the recommendations in the Guide. In 2007, OSD has been actively engaging a sample of DoD SoS programs to pilot the Guide, especially with respect to the 16 OSD SE processes. The responses will become part of the first update to the Guide.

At this panel, OSD will present the background and motivation for writing the Guide, along with an update on the pilot. Both OSD and INCOSE will discuss their insights. As part of the broad SE community review, the Guide will also be viewed from the UK perspective of Capabilities Based Acquisition. Looking to the future, the concepts and practices of Net Centricity, Network Enablement of Capabilities, and Semantic Web will be considered and how they might be more deeply integrated into future versions of the Guide. This panel will provide opportunities for INCOSE to continue to work with OSD and collaborate on SoS SE.
A Research Agenda for Systems of Systems Architecting
Authors: Axelband Elliot , Baehren Thomas , Dorenbos Dave , Madni Azad , Robitaille Paul , Valerdi Ricardo , Boehm Barry , Jackson Scott , Nadler Gerald , Settles Stan
Published: November 2014

This paper documents the activity of a workshop on defining a research agenda for Systems of Systems (SoS) Architecting, which was held at USC in October 2006. After two days of invited talks on critical success factors for SoS engineering, the authors of this paper convened for one day to brainstorm topics for the purpose of shaping the near‐term research agenda of the newly convened USC Center for Systems & Software Engineering. The output from the workshop is a list of ten high‐impact items with corresponding research challenges in the context of SoS Architecting.

Each item includes a description of the research challenges, its link to contemporary academic or industrial problems, and reasons for advocacy of that area. The items were assessed in terms of value and difficulty to determine a prioritization both for the CSSE's future research agenda and for others in the field.
NCW – Nature's Predator‐Prey Abstraction
Authors: Gregg Michael L. , Miller Ann , Dagli Cihan
Published: November 2014

The Predator‐Prey ecosystem of the African savannahs provides a real‐world abstraction of network centric warfare (NCW). Prides of vultures scan the skies looking for dead or dying prey while packs of hyenas and lions fight it out on the ground to either track and kill their next meal or steal downed prey from their natural adversaries. Constantly observing and spying on each other, these incessant adversaries are always seeking a competitive advantage.

When one of the circling vultures sights either downed prey or possible scraps from a ground‐based struggle, it signals others to descend. By doing so, they inadvertently share their intelligence with other predators on the ground. Based on distance to the prey, number of other predators in the area, and ratio of adversaries to allies, the race to the kill‐site is swift and the outcome means the difference between survival to fight again and starvation.

Starting with the assumption that the Predator‐Prey ecosystem of the African savannah would be a real‐world abstraction of NCW, a study of the interactions between three representative species (lions, hyenas, and vultures) was initiated. Behavior, especially in regard to interactions with other species, pride or pack size, average ground or air speed, and territory size were investigated. During the investigation, it became clear that the interactions between the species could be clearly viewed as an analogy to a set of mobile combatants seeking to overthrow their adversaries; in this case the goal is food (i.e., survival) rather than social power, money, or property.

A portion of this work analyzes the behavioral characteristics of each species much like war fighters dissect the capabilities of their adversaries. These species‐based parameters were used to analyze how different distributions of prey, in relation to predator territories, influence which predator species gets to the prey first in sufficient numbers to get the majority of the food. The analysis was performed using a simple Monte Carlo discrete event simulation model and considered the nominal, aggregated behavior of each pack or pride as a single unit, not the behavior of individual pack members. Using these aggregated characteristics of speed and the ability to sense downed prey at a distance, a clear parallel could be drawn to the groups of armed forces in war zones relative to available surveillance and tracking systems. Albeit, the struggle in the African savannah is an on‐going, zero‐sum war game.
2.4.1 An investigation into how systems engineering can help preserve natural environments
Authors: Fossnes Terje , Haskins Cecilia
Published: November 2014

The INCOSE Systems Engineering Vision suggests that if systems engineering is to be adopted by small and medium enterprises then lean/agile process sets must emerge accompanied by multiple views that include socio‐technical, economic and political perspectives.

In this paper, the authors apply a lightweight systems engineering framework to analyze a socio‐technical problem domain with the potential to influence the quality of life in the Norwegian High Mountain Plateau. The results indicate that while many requirements of a vacation home are met by the architecture, providing modern conveniences while at the same time preserving the natural environment requires technological solutions, and systems engineering. In the opinion of these authors, this epitomizes the meaning of ‘Systems Engineering for the Planet.’
3.1.1 Working Towards a New Characterisation of Architecture
Authors: Bryant Peter , King Paul
Published: November 2014

The paper will discuss progress towards a new characterisation of architecture based on the activities of the recently formed INCOSE UK Chapter Architecture Working Group.

The focus of the paper will be on describing the diversity of opinion we have observed in discussions of the fundamental characteristics of architecture and progress towards resolving the various conflicts that arise.

We have made progress in refining the definition of architecture, the understanding of the role of patterns within architecting and how the conceptual underpinnings of architecture may be made consistent with the uses and types of architecture.
4.2.1 Software versus Systems Engineering, is there a difference?
Authors: Hadderingh J.N.
Published: November 2014

The topic for this paper is the question: should software engineering be considered a discipline of its own or is it identical to systems engineering. As software is becoming more and more important for systems this question becomes relevant as it addresses the approach towards software by the systems engineering community. This paper proposes to divide what is commonly called software engineering in two disciplines;

A specialty engineering discipline

A systems engineering discipline

The paper suggests the systems engineering discipline within software engineering to be identical to “normal” systems engineering. And supportive material is provided to support this statement.
4.3.2 Global Systems Engineering Competencies: A Business Advantage
Authors: Arnold Eileen
Published: November 2014

As market boundaries change, diversified corporations can no longer focus on end product markets. A competency system, flowed‐down from enterprise and business objectives and strategy to a workforce comprised of an individual's competencies with a global Systems Engineering focus, is proposed as a business advantage. Unexpected results, capitalizing on the synergies and combinations of competencies; the “whole is more than the sum of its parts” concept illustrates a newly introduced term, Emergent Competency behavior. A multi‐dimensional Systems Engineering Competency Model example, based on individual competencies with global and layer dimensions, is provided as a way to leverage the knowledge, skills, abilities, and attitudes of a workforce to achieve business success. Six categories of competencies are proposed to include Enterprise, Domain, Discipline, Cognitive, Environmental Sustainability, and Behavioral.
5.1.1 Conceptual Design to Cost: A new systems engineering tool
Authors: Hari Amihud , Shoval Shraga , Kasser Joseph
Published: November 2014

Incorporating cost considerations in the system design is a critical part of the system development process. However, since current methods of incorporating cost considerations into the design need knowledge of the cost of the actual components to be used in the system; the technique know as Design to Cost (DTC) is not suitable for use in the conceptual or in the preliminary design phase where it is most needed. This paper introduces a methodology for performing DTC in the front ‐ end design phase that has been used with some success to provide cost estimates. This methodology, Conceptual DTC (CDTC) fills a critical gap in the systems engineer's toolbox. This paper begins with a short review of DTC, and then describes the CDTC methodology which allows cost factors to be treated in the same manner as the other system factors such as functional, performance, reliability and safety etc. as an integrated part of the design process, rather than as an external bolt‐on.
5.3.1 A Safety‐Driven Systems Engineering Process
Authors: Stringfellow Margaret V. , Owens Brandon D. , Dulac Nicolas , Leveson Nancy G.
Published: November 2014

This paper describes a new systems engineering process for safety‐driven development that combines three state‐of‐the‐art techniques: 1) Intent Specification, a framework for organizing system development and operational information in a hierarchical structure; 2) the STAMP model of accident causation, a system‐theoretic framework upon which to base more powerful safety engineering techniques; and 3) STAMP‐based Hazard Analysis (STPA).
5.3.2 The Development of International Standards for Very Small Enterprises
Authors: Laporte Claude Y. , Renault Alain , Alexandre Simon , Crowder Kenneth V
Published: November 2014

Industry recognizes that there are very small enterprises that develop parts which contain software components. These enterprises are very important to the world‐wide economy, and the parts they develop are often integrated into products made by larger enterprises. Failure to deliver a quality product on time and within budget threatens the competitiveness of both organizations. One way to mitigate these risks is for all the suppliers in a product chain put in place recognized engineering practices. Many international standards have been developed to capture proven engineering practices. However, these standards were not written for very small development organizations, those with less than 25 employees, and are consequently difficult to apply in such settings. An ISO/IEC JTC1/SC71 Working Group has been established to address these difficulties.
8.1.1 Service Engineering
Authors: Kemp Duncan , Linton Robert
Published: November 2014

This paper describes the approach being used to introduce net‐centric solutions into service within the UK Ministry of Defence. It describes specific differences between engineering conventional systems (such as ships or aircraft) and engineering net‐centric solutions and the problems that they introduce.

The paper describes an approach to net‐centric systems development, which is based on the integration of three interdependent applications of conventional systems engineering: at the business, the service and component levels. The major focus of this approach is the extension of systems engineering from the design and manufacture of components into the delivery of services and the achievement of business effect.

The paper describes some key techniques used in the systems engineering of services. These include benefits realisation management, service level definition, service architecting, performance design and application characterisation, capacity management and service acceptance.

Finally the paper describes some of the cultural and behavioural issues that the authors have found essential to success.
8.1.2 Continuous Systems Development for Command, Control and Intelligence Systems
Authors: Yeoh Lean Weng , Teo Tiat Leng , Lim Horng Leong
Published: November 2014

The traditional software development model is no longer adequate to meet the challenges of fast evolving needs of Command, Control and Intelligence (C2I) systems. To enable the transformation of the 3rd Generation Singapore Armed Forces, continuous systems development approach has been adopted by Defence Science & Technology Agency (DSTA) to develop C2I capabilities for the Singapore Armed Forces (SAF). The key advantage of this approach lies in its flexibility to respond rapidly to meet changing needs and address emerging threats. The complexities of network centric operation entail the fielding of systems quickly for operational trials and to continuously discover capability gaps, so as to evolve systems capabilities over its lifecycle. This paper addresses the framework adopted by DSTA to develop C2I System‐of‐Systems.
10.3.1 Design with Overview – how to survive in complex organisations
Authors: Bonnema G. Maarten , Borches P. Daniel
Published: November 2014

Literature on how the design process should be conducted is abundant. Also literature on how the design process is performed in practice can be found. An issue that has received less attention is how to keep overview while the design project evolves. This article will look at several aspects of overview in the design process. Encapsulation is proposed as a means to avoid saturation of system designers, yet providing enough detail information. The notion of sampling the design process is introduced, as an equivalent to sampling a signal in time.

The paper proposes to use the Function ‐ Key drivers architecting tool (FunKey) as a means to keep overview. Using this tool, it is possible to encapsulate details, yet provide insight and overview where needed. Also, it is possible to sample progress in the design project at a much higher frequency than using the (document) reviews described in system engineering guidelines like the INCOSE handbook.
11.5.2 Systems Engineering the U.S. Education System
Authors: Wells Brian H. , Sanchez H. Alex , Attridge Joanne M.
Published: November 2014

This paper presents the recent and on‐going activities that are applying systems engineering to the U.S. education systems to identify potential improvements that will increase student proficiency and interest in Science, Technology, Engineering and Mathematics (STEM). Because applying the methods of systems engineering to a complex human system, like the U.S. education system, is somewhat novel, system dynamics modeling, which is not typically used in aerospace systems engineering projects, was required. Also, because of a lack of systems specific expertise and the need for new and diverse ideas, the project was performed as a student project with competing teams. The complexity of the U.S. education systems required an examination of the total system and then focusing on a limited portion of the system. This paper shows how the complexity was dealt with and how the particular area for detailed examination was selected. Current activities and plans are also presented.
11.5.3 Systems Engineering Education for Civil Engineering Students
Authors: van Nederveen Sander , Ravesloot Christoph Maria , Braat Karel , de Ridder Hennes
Published: November 2014

Civil infrastructure projects have become increasingly complex over the last decades. For that reason, systematic approaches such as systems engineering have been found very useful for making large and complex projects better manageable. This implies that civil engineers of the future must gain knowledge, insight and experience in systems engineering during their study. This paper discusses the use of system engineering concepts and methods in design project courses for civil engineering students. The use of system engineering‐related methods such as project decomposition, requirements management and interface management are discussed. Although only basic system engineering methods are used, it seems that students get a sound basis for the system engineering concepts that will be useful in their future lives as managers in civil engineering projects.
KR09 Using Historical Lessons‐Learned in the Systems Engineering Process
Authors: Ferreiro Larrie D.
Published: November 2014

Systems engineers often do not have a way to systematically apply historical “lessons‐learned’ in their day‐to‐day activities, especially when applied to non‐traditional areas of engineering management. Risk analysis has become the standard systems engineering decision‐making tool to evaluate uncertainties in cost, schedule and performance. Therefore, such historical insights need to be modeled within that framework to be mutually comprehensible and useful to both historians and systems engineers. To demonstrate this framework, I examine historical “lessons‐learned” in several relevant areas: the implications of operational flexibility on system design; complex system‐accident theory; and the considerations of technological “reverse salients”. The insights developed through historical analyses can be used as a decision‐making tool for systems engineers, by developing a subjective “risk rating” assessment as a part of the overall set of decision aids to estimate uncertainty in performance, cost and schedule. This interface between historical insights and the priorities of systems engineers can enrich the basis of programmatic decision‐making.
KR17 Risk Cube Data Biases
Authors: Smith Eric D. , Siefert William T.
Published: November 2014

Risk cubes used in industry characterize particular risks in terms of the likelihood of occurrence, and the consequence of the actualized risk. Human cognitive bias research led by Daniel Kahneman and Amos Tversky exposed systematic translations of objective probability and value as judged by human subjects. An examination of industry‐generated risk cube data reveals evidence of biases in the judgment of likelihood and consequence. In addition, other biases – including a ‘diagonal bias’ – are revealed in the risk cube data. The evidence presented could improve risk cube based risk analysis.
KR23 Value‐Focused Systems Decision Making
Authors: Parnell Gregory S. , West Paul D.
Published: November 2014

This paper presents the Systems Decision Process, a value‐focused systems engineering decision process used to support fact‐based decision making. The process provides analysis products to support major system decisions that are made at major decision gates in each system life cycle stage. The process has four phases: problem definition, solution design, decision making, and solution implementation. The process emphasizes defining, measuring, designing, and implementing solutions to achieve stakeholder and decision maker value. The process should be tailored to the system, the stage in the system life cycle, and the decision environment.
KR25 System of Systems Architecture Evaluation Using Evolutionary Computation
Authors: Simpson Joseph J , Dagli Cihan H.
Published: November 2014

Evolutionary computation and evolutionary algorithms represent a developing science and technology that can be effectively applied to the generation and evaluation of system of systems architectures. A general technique used by systems engineering professionals is a binary matrix representation of a system or system of systems. The specific meaning and semantics of the binary relationship depends of the type of representation used. Typical representations are, “N squared”, design structure matrix, dependency structure matrix, and implication matrix. A key feature of these typical representations is their direct relationship to the structure required in an evolutionary computational approach. Evolutionary algorithms can be applied to the evaluation and optimization of these matrix structures. A new evolutionary algorithm has been developed that applies specifically to the generation and evaluation of systems and system of systems. This new evolutionary algorithm incorporates a fuzzy inference system in the calculation of the best fit evaluation. The current industrial and social environment is populated with a vast array of existing and developing systems. Any new system must take this context into account. Evolutionary computation is applied to assist the system architect and engineer in the evaluation of these complex configurations and interface sets.

The new evolutionary computing techniques are applied to system of systems architecting tasks using a well defined set of measures of effectiveness (MOE). The systems architecting task is divided into three general areas organized around the roles and responsibilities associated with the system architect, the system customer and the system engineer. The system architect is responsible for the complete system operation and MOE balance, focused on life‐cycle cost and risk. The customer is responsible for the mission profile and mission functions. Operational effectiveness and operational suitability areas are the responsibility of the systems engineers. Affordability, risk, operational effectiveness and operational suitability are the four MOE used to evaluate the candidate system of systems architectures.
KR26 A Systems Engineering Approach to Embedded Control System Implementation in Buildings
Authors: Yahiaoui Azzedine , Staal Rob
Published: November 2014

Systems engineering (SE) is a comprehensive and structured approach for analyzing, designing, creating, and operating a system in a cost‐effective way. SE concepts are therefore concerned with the overall processes of defining, developing, operating, maintaining, and ultimately replacing quality systems. Whereas the building environmental performance concentrates on the details of individual aspects of building components and equipments (civil, mechanics, electronics, ergonometrics, etc.), SE concept needs to be integrated with all aspects necessary to realize efficient control systems in buildings. To explore this potential, the paper proposes a systems engineering approach for the design of distributed control and building performance simulation by run‐time coupling, over TCP/IP protocol suite. In particular, this paper involves a case‐study with two important steps; first consists of experiments obtained in TU Delft test‐cell in order to demonstrate a potential ability of using advanced control strategies in buildings, and then simulation results are obtained with the run‐time coupling mechanism.
1.3.1 Microcosm – A Systems Engineering and Systems Integration Research and Learning Sandpit
Authors: Mansell Todd , Do Quoc , Cook Stephen , Relf Phillip , Campbell Peter , Ross Christian
Published: November 2014

This paper describes the Microcosm program established by DSTO and UniSA to research and to promote good systems engineering and systems integration practice. The initial focus of the Microcosm project is research into the application of Model‐Based Systems Engineering (MBSE) in complex systems engineering and systems integration programs. The paper outlines what Microcosm seeks to achieve with particular focus on the high‐level architecture of the Stage 1 solution. The paper concludes by describing the Stage 1 implementation of the Microcosm ‘sandpit’ including the information management environment, the simulation, modelling and control environment, and the physical systems including unmanned ground vehicles, sensors, communications infrastructure and effectors.
1.3.3 Conceptual Model for Space Mission Systems Design
Authors: Mandutianu Sanda , Moshir Mehrdad , Donahue Kenneth , Laboratory Jet Propulsion
Published: November 2014

Modelling tools and methodologies without concerns about human understanding may not be suitable for communicating with stakeholders, customers, or management. There are many factors that can increase understandability. Using a generic systems engineering modelling language certainly helps but is not always enough. The understandability of modelling can be improved by using better modelling techniques and strategies, which might be part of a coherent methodology with a deliberate emphasis on communicability. The paper describes the application of Systems Modeling Language (SysML) to the design of a JPL mission using the Object Oriented System Engineering Method (OOSEM). Complementary formal modelling using the Web ontology language (OWL) has also been investigated. Using only traditional means, under increased demands on productivity and decreased resources, system integration may become high risk, and lifecycle support is expensive and may result in rapidly outdated components. Model‐based systems engineering (MBSE) is showing promise as a solution to this problem in addition to and enhancing more traditional approaches. The space mission systems models represent sciences and technologies including astrophysics, physics, electronics, mechanisms, hardware and software. Representations of system architecture specification, requirements, evaluation of alternative architectures and trade studies, including static simulation of the performance are grouped into views that represent different stakeholder viewpoints. The human understandability of the resulting models and how the modeling process can increase communication and understandability has also been addressed and observations are reported.
2.1.1 A System of Systems Approach to Warfighter Training
Authors: Parkinson David
Published: November 2014

This paper explores the traditional Systems Approach to Training (SAT) for the Warfighter, suggesting improvements for complex large‐scale, live, and virtual training systems. Such systems are required to deliver military effectiveness and enable Readiness & Sustainment (R&S). It has long been accepted that the proper way to design training is by adopting a systematic approach to assessing the training gap, the design of the syllabus, and the evaluation of the performance improvement. This Systems Approach to Training (SAT) parallels Instructional Systems Design methodology, the latter also being a model to aid in the design, development, and delivery of a training program. The paper discusses the complexity of such large‐scale military training systems and presents a case for designing them using Systems Engineering (SE) principles. The traditional SAT method applies, but does not cope with the overall requirements capture, architecture design or interoperability; nor was it designed to do so. Complex large‐scale training systems are human centric and consequently should be designed using the most appropriate Systems Engineering (SE) processes, methods and toolsets.
2.3.2 An Architecture‐Centric Approach for Systems Design
Authors: Neill Colin J. , Sangwan Raghvinder S. , Paulish Daniel J.
Published: November 2014

The most critical requirements for the lifetime value of a system are its non‐functional requirements such as reliability, security, maintainability, changeability, etc. These are collectively known as the ‘ilities’ and are typically addressed in system design once the functional architecture has been developed. In this paper we propose the use of architecture‐centric design that modifies this standard workflow so that those non‐functional requirements, which actually reflect the true business needs, are addressed first. This ensures that the final system better reflects and embodies those architecturally‐significant requirements rather than having them addressed secondarily. This is an important change since the ‘ilities’ are systemic properties (properties of the system as a whole) rather than systematic properties (properties of individual components or sub‐systems) and are therefore difficult to address once the functional architecture has been determined and the separation of concerns is already somewhat completed. We provide an example of the approach based around a simplified case study of an online, on‐board health monitoring system for shipboard gas turbine electricity generators that collects, filters, analyzes, transmits, and mines sensor data from the generators subsystems.
3.2.4 Study on the Influence of Component Uncertainty on Reliability Estimation of Multi‐State Systems with Continuous States
Authors: Zhang Chi , Mostashari Ali
Published: November 2014

Existing reliability evaluation methods rely on the availability of accurate component states data. They will become ineffective when the states themselves are uncertain or unknown, which usually happens during the early stages of the development of new systems. In such cases it is important to understand how uncertainties will affect the system reliability measures. Another drawback of current methods studying reliability of Multi‐State System (MSS) is that they only considered the systems whose components have several discrete states. For those whose components have continuous states, these methods are not effective either. This paper considered the continuous distribution of components states during the approximation of Multi‐State System (MSS) reliability and proposed a method to assess the reliability of this kind of system using Monte‐Carlo simulation. This method will also be useful when we have no enough data to know the exact discrete states and related probability, and can only estimate components states distribution types and related parameters. Two examples were employed to illustrate the method. Comparison of the two examples shows that component state uncertainty has significant influence on the assessment of system reliability. Our effort will make the reliability approximation more realistic compared with existing methods.
3.3.1 Divergent Thinking in Systems Engineering Practice: Is There a Shortfall?
Authors: Armstrong James R.
Published: November 2014

Divergent thinking produces an expanded definition of both problem and solution space. Convergent thinking leads to the selected solution. A balance of the two is an essential element of effective systems engineering practice. A significant predominance of convergent thinkers and shortage of divergent thinkers has been noticed in a group of systems engineering students. A negative impact on exercise results was also noticed. If this is a valid observation of the general systems engineering field, there are serious implications that must be addressed in training and at work. This paper outlines the initial observation, impact, and potential for future research.
3.5.0 Can We Engineer the Emergent Behavior of A System‐of‐Systems?
Authors: Hsu J. C , Axelband E. , Madni A. M. , Dagli C. , McKinney D.
Published: November 2014

Emergent behaviors exist in biological systems, physical systems and human performance. It is an inherited nature of a System‐of‐Systems (SoS). SoS displays a global complexity that cannot be adequately managed by hierarchical structures and central control; therefore, traditional systems engineering and management approaches are necessary but insufficient for a SoS.

Little is currently known about constructing an interoperable network of systems and the incorporation of emergent behaviors. The purpose of this panel is to explore the possibilities of developing an architecture model including the emergent behavior.

The challenge is how to understand the initiation mechanisms of the emergent behaviors for a particular system architecture model so that the resident beneficial or harmful emergent behaviors can be enhanced or mitigated with selected changes in the model. Is model‐based the only feasible approach to develop the architecture model with emergent behavior? If this is the answer, what kind of modeling methodology? Should it be solely based on agent‐based modeling or a combination of SysML and agent‐based? Is SysML ready to deal with emergent behavior?

For a non‐modeling consideration, can we plan for the beneficial or harmful emergent properties? How do we overcome development friction that is bound to arise when there are complex, independent, overlapping governances, for example, the customer requirements for a SoS evolve over time, etc.? There may only be SoS modeling at the level of the government agency, which actually procures but does not build, and not at the level of contractors who build the next generation of technologies.