bluuebunny/crossref_metadata_2025 huggingface dataset:
7.3.1 The Impact of Technical Regulation on the Technical Integrity of Complex Engineered Systems
Authors: Edwards Michael
Published: November 2014

The explicit aim of the application of technical regulation is to ensure that the requisite Technical Integrity of the developed system is achieved. Technical Integrity encompasses fitness for service, system safety and minimised environmental impact. The beginnings of a program of research to test the hypothesis that “The application of technical regulation yields improved technical integrity of the complex engineered system” are established. It is shown that only the intended emergent properties of a complex engineered system and its unintended hazards are directly addressed by technical regulation. A candidate set of measures to assess technical integrity is proposed. The methods that may enhance technical integrity of complex systems are reviewed. The degrees to which technical regulatory frameworks actually enforce methods known to have a contribution to technical integrity are also reviewed resulting in a list of corollary questions to be considered by future research.
7.3.3 Claim‐Payment Failures Of Japan's Insurance Companies And Designing Better Payment Architecture: Finding A Standard Solution To Socio‐Critical Systems By Applying the System Engineering Vee Model Approach (First Report)
Authors: Yasui Toshiyuki
Published: November 2014

Sociology, political science, economics and international relations traditionally deal with social systems. However, they have not proposed a solution to fix problems when they fail. This paper identifies the scope of social systems in which we can find a solution to cure such failures through three tests; the externality test, mission‐criticality test and controllability test. We name these a socio‐critical system (SCS). Architecture Vee Model can be applied as the standard method to fix failures in an SCS.

Massive claim‐payment failures were found in Japan's private insurance companies and they became big social issues in 2005–2008. Japan's financial services supervision authorities identified failures to the full extent and issued successive administrative actions against most insurance companies to encourage them to improve their governance and overall solicitation‐to‐payment systems. This FSA's action, even though it was not necessarily aware of such methodology, proved to be positive in applying Architecture Vee Model to solve failures in those claim‐payment systems, which are typically categorized in SCS.
8.1.1 People, Policy and Technology: Considerations in Designing a Robust Security Framework
Authors: Reed Michael
Published: November 2014

This paper analyses the process which was employed in defining the security architecture for a latest‐generation Electronic Toll Collection (ETC) system. It focuses on one fundamental operational requirement – the non‐repudiation of transactional data and the evidence of travel in support of the enforcement of tolling events – and uses this to highlight the essential integration between technological capability and operational processes in delivering a secure solution.

Put simply: in a market of off‐the‐shelf security “solutions”, it is essential at the enterprise level to recognise that security is a process, not a product.

The interactions between technical and technological capabilities, operational policies, people and business processes must be tightly aligned in order to demonstrate that the enterprise has achieved the non‐repudiation of transactional data, and has a sound basis for tolling.
8.1.2 Overrepresented and Underrepresented Patterns in System Architectures Across Diverse Engineering Systems
Authors: Shaja A. S. , Sudhakar K.
Published: November 2014

Recent years have witnessed new research interest in the study of complex systems architectures, in domains like biological systems, social networks etc. Seminal works covering each of these systems have appeared in high impact journals like Nature, Science, etc. Unifying principles have emerged and helped in gaining new understanding in a domain by extending the understanding gained in other domains. These developments in complex systems open up possibilities in the research into architectures of complex engineering systems. Complex engineering systems are synthesized from large number of components giving it a physical architecture. We abstract the physical architecture of different engineering systems as a network/graph, where the nodes/vertices correspond to components and edges correspond to interconnections between them. Complex systems research in biology defines motifs as recurring sub‐graphs from which the network is built. They also argue motifs as simple building blocks of complex networks, offering a way to understand the basic functionality of a system. In this paper, we explore 32 arbitrarily chosen engineering systems architectures for motifs. We discover motifs within each system and also interesting motif templates across systems.
8.1.3 Resiliency Assessment of the Global Internet Infrastructure System
Authors: Omer Mayada , Nilchiani Roshanak , Mostashari Ali
Published: November 2014

Resilience is the ability of the system to both absorb shock as well to recover rapidly from a disruption so that it can return back to its original service delivery levels or close to it. Recent manmade and natural disasters such as 9/11 incident and Hurricane Katrina have introduced an increasing interest in infrastructure resilience. The global submarine fiber optics cable network that serves as the backbone of the internet is a particularly critical infrastructure system that is vulnerable to both natural and man‐made disasters. In this paper, we propose a model to measure the base resiliency of this global network, and explore the node to node and global resiliency of the network using existing data demand, capacity and flow information. The base resiliency of the system can be measured as the value delivery of the system after a disruption to the value deliver of the system before a disruption. We further demonstrate how the resiliency of the global internet infrastructure is enhanced through reducing the network vulnerability and increasing its adaptive capacity.
8.2.1 A System Design Process Tailored for Reverse Engineering
Authors: Yoon Taehun , Park YoungWon
Published: November 2014

This paper discusses a system design process using a reverse engineering. The Reverse Engineering approach, if possible is a cost‐effective and easy approach to use in a system design. All industries use this approach consciously or unconsciously to reduce the system development risk. It can be a part of formal process, simple requirements reuse, or adoption of industry standard. The reverse engineering approach can be considered as an effective system design method in immature systems engineering environments. This paper proposes a system design process using reverse engineering which can be tailored for large complex system development projects. The proposed process composed of two stages to product system specification generation. The reverse engineering stage is performed to define functional and physical architecture of legacy system used as reference model when they are not available. The reengineering stage takes outputs of the reverse engineering stage to define the rest of logical and physical solutions.
8.2.2 Improvements to DSM Clustering Approach for PBS Construction
Authors: Kim Chan Mook , Park Young Won
Published: November 2014

A top‐own scenario based approach is a typical method generating the product breakdown structure (PBS) in systems engineering. While it takes time and effort to perform the scenario based PBS construction, it is the safest approach not to omit any functions. On the other hand, a design structure matrix (DSM) approach to PBS construction is a bottom‐up approach based on modularization concept that provides a merit of quick PBS construction while the sanity of its results may not be assured.

Accordingly, this study presents trade‐off results between the two approaches to uncover problems in the DSM‐based clustering method and proposes improvement approaches to enable the interfaces with external systems, static elements, as well as a new capability to handle the large number of clustering elements.
9.1.2 Demographics in Measuring Systems Engineering Return on Investment (SE‐ROI)
Authors: Honour Eric C.
Published: November 2014

Research work continues into Systems Engineering Return on Investment (SE‐ROI) following prior work on Value of Systems Engineering and Systems Engineering Effectiveness. In the current work, 1.5‐hour interviews are being held with the leaders of completed system development programs to obtain extensive data on systems engineering activities, program success measures, and possible correlative parameters. The resulting information is being examined statistical to determine empirical knowledge about the return on investment of systems engineering activities. As of this writing, interesting results in the demographics have been observed based on 30 program interviews. This paper provides information showing (a) source information on the interviewed programs, (b) observed quantitative breakdown of systems engineering effort into eight activities, (c) histogram spreads of the observed characteristics of the source programs, and (d) histogram spreads of the observed correlative parameters. The paper also provides initial indications of the differences between successful and unsuccessful programs.
9.2.1 Reference Framework and Model for Integration of Risk Management in Agile Systems Engineering Lifecycle of the Defense Acquisition Management Framework
Authors: Crowe Portia , Mostashari Ali , Mansouri Mo , Cloutier Robert
Published: November 2014

Risk management is a requirement for success of any enterprise. Despite this fact, there have been limited solutions for integrating risk management in agile life cycles. On average, 70% of all IT‐related projects fail to meet their objectives which have caused 80% of companies to reassess their process. One of these processes includes risk management where studies have shown that risks should be assessed in all dimensions of a program. We found that risk management was being conducted on the overall program with concentration in the software development phase which leaves other life cycle phases with no risk assessments and mitigation strategies. Agile systems engineering is more complex than traditional systems engineering due to events happening concurrently and non‐sequentially during the life cycle of a program. This paper will propose a framework and model for risk ‘managility’, management in an agile environment, specifically in systems engineering life cycle. We use the Department of Defense's Evolutionary Acquisition and Management Framework as a bridge to define and illustrate an agile systems engineering life cycle (ASEL) framework and an agile risk integrated engineering lifecycle (ARIEL) model.
9.2.3 A Rationale and Framework for Integrating Systems Engineering and Software Engineering
Authors: Turner Richard , Pyster Arthur , Pennotti Michael
Published: November 2014

As illustrated in the harmonization of ISO 15288 and ISO 12207, the disciplines of systems engineering and software engineering share many processes, methods, and concerns. In most systems of interest, software now provides a significant majority of functionality and increasingly is a significant component in determining non‐functional attributes. Failures in system acquisition and implementation are often attributed to systems and/or software engineering shortfalls. The need to apply systems engineering to software design and development, as well as the need to incorporate software engineering concepts into systems engineering decisions, implies that a closer relationship between the two disciplines is appropriate. This paper states a clear rationale for integrating the two disciplines, defines a framework that establishes a vocabulary for discussing integration, and presents initial findings in using that framework to describe systems and software integration in ongoing defence programs.
10.1.2 Integrating Systems and Business Engineering in an International Context: The SpaceTech Postgraduate Program
Authors: Gill E. , Kreisel J. , Verma D.
Published: November 2014

Successful education of engineers needs continuous adaptation to track the changing needs of industry. The adaptation is not limited to technological advance or to the changing mentality of new students but also to end‐to‐end engineering approaches using Systems Engineering. However, industries today require more and more engineers with profound knowledge of business engineering to arrive at successful products – a fact which universities typically have not sufficiently taken into account yet.

The SpaceTech program of the Delft University of Technology is an international postgraduate program for experienced high potentials seeking expertise in space systems and business engineering. The program centres around a Central Case Project where a group of international participants exercise space systems engineering fundamentals together with marketing and business engineering tools to create a financially viable virtual business.

Based on more than 10 years of experience from the SpaceTech program, the learning objectives of Systems Engineering and business engineering and their interrelations are analyzed. Topics of past Central Case Projects are summarized and trends are extracted. The potentials of integrating Systems and Business Engineering are identified and their limitations in an educational environment are addressed.
10.2.2 Initial Experience in Contracts Based Systems Engineering
Authors: Herzog Erik , Andersson Henric
Published: November 2014

Engineering process efficiency is the target of any systems engineering organisation. In this paper we review initial experience from applying the Contracts based systems engineering method developed by the SPEEDS project. The method is outlined along with experience gathered from pilot projects performed at SAAB Aerosystems. Outlines for adapting the method to mainstream tools as well as future adoption activities are also presented.
10.2.3 ELICERE: A Process for Defining Dependability Goals for Critical Computer Systems
Authors: Lahoz Carlos H. N. , Camargo João Batista
Published: November 2014

This paper introduces the ELICERE process: a dependability requirement elicitation process applied to critical computer systems, based on a goal‐oriented requirements engineering technique i* (pronounced i‐star), and safety engineering techniques. After creating the system model using i* diagrams and their relationship components, such as goal, soft‐goal, resource and task, these components are analyzed through guidewords based on HAZOP and FMEA. This process is applied to some critical elements of the system model, from where goals related to dependability are extracted. The authors believe that this interdisciplinary approach will allow promoting the identification of goals that meet the quality requirements related to safety, reliability and other dependability factors still in the project conception phase. Also, ELICERE intends to facilitate the communication between system and software engineering communities, during a project requirements engineering phase.
Adaptive Activity Driven Multi‐Level Hierarchical Prediction of Complex Systems Through Profiling and Feedback
Authors: Hammami O.
Published: November 2014

Complex systems composed of multi‐level hierarchical systems exhibit complex interacting dependences which affects the performance of the overall system. Although, one solution is to tightly monitor each system activity and feedback to the next step level in order to take appropriate measures and actions to improve the system this solution is costly and too systematic. In addition, a dependency chain exists between low level systems and higher level systems this dependency chains being as long as the number of levels of the system. We propose in this paper an activity driven adaptive hierarchical prediction technique for complex systems which minimizes monitoring and prediction resources requirements and still keep efficient overall systems performance prediction.
1.3.2 Enterprise Capability Assessment and Prioritization
Authors: Bryan Jeffrey D. , Caliva Robert M. , Murphy James A.
Published: November 2014

The Idaho National Laboratory (INL) is a science‐based, applied engineering national laboratory dedicated to supporting the U.S. Department of Energy's missions in nuclear and energy research, science, and national security. This paper describes the development of a qualitative approach (and tool) for assessing and prioritizing capability gaps of an enterprise (i.e., based on similar effort for a U.S. Army Brigade Combat Team) along with the assessment of potential solutions for reducing or closing those gaps. It discusses the effort to create a common information model (i.e., within a qualitative process and toolset) that can assist an enterprise to capture and visualize relationships between its mission(s), required capabilities, performance objectives, gaps and potential solutions. Key to this effort was the establishment of an analysis framework containing unique (i.e., mostly independent) capabilities organized within a hierarchy which allows for appropriate visibility into problem areas while eliminating redundancy that would bias assessment results. Finally, the paper presents the tool developed to manage and display relationships between multiple required capabilities, their gaps, and the solutions proposed for gap closure, such that the enterprise can better fulfill its mission(s).
1.2.1 System Engineering Competency The Missing Element in Engineering Education
Authors: Wasson Charles S.
Published: November 2014

The “engineering of systems” performed in many organizations is often characterized as chaotic, ineffective, and inefficient. Objective evidence of these characteristics is reflected in program performance metrics such as non‐compliance to requirements, overrun budgets, and late schedule deliveries. Causal analysis reveals a number of factors contribute to this condition: a lack of technical leadership, a lack of understanding the user's problem / solution spaces, point design architectures and solutions, a lack of integrated decision making, et al. Further analysis indicates these factors are symptomatic of a much larger competency issue traceable to undergraduate engineering education ‐ the lack of a course in Systems Engineering fundamentals taught by seasoned instructors with robust, industrial experience acquired from a diversity of small to large, complex systems.

This paper explores the ad hoc, chaotic, and dysfunctional nature of technical planning and execution. We trace its origins to the industrial Plug and Chug … Specify‐Design‐Build‐Test‐Fix Paradigm and its predecessor Plug and Chug … Design‐Build‐Test‐Fix Paradigm acquired informally in engineering school. Whereas these paradigms may be effective for academic application, they are not suitable or scalable to larger, complex system, product, or service development efforts.

The solution is to bolster the competency of the engineering workforce at two stages: 1) upgrade undergraduate engineering education to include a System Engineering fundamentals course and 2) shift the industrial System Engineering paradigm through education and training to employ scalable SE problem solving / solution development methodologies for projects ranging in size from small to large, complex systems.
1.2.2 A Maturity Model for the Competency of Systems Engineers
Authors: Kasser Joseph E. , Frank Moti
Published: November 2014

This paper proposes a maturity model for the competency of systems engineers that instead of measuring years of experience is based on an assessment of an individual's skill against ability in each of three broad dimensions – knowledge (systems engineering and domain), cognitive characteristics (systems thinking and critical thinking) and individual traits. The maturity model is designed in such a manner so as to be a generic maturity model for assessing competency in many practitioner professions simply by changing the knowledge requirements.
1.4.2 Systematic Discrimination of Advanced Hydrogen Production Technologies
Authors: Park Charles V. , Patterson Michael W.
Published: November 2014

The U.S. Department of Energy, in concert with industry, is developing a high‐temperature gas‐cooled reactor at the Idaho National Laboratory (INL) to demonstrate high temperature heat applications to produce hydrogen and electricity or to support other industrial applications. A key part of this program is the production of hydrogen from water that would significantly reduce carbon emissions compared to current production using natural gas. In 2009 the INL led the methodical evaluation of promising advanced hydrogen production technologies in order to focus future resources on the most viable processes. This paper describes how the evaluation process was systematically planned and executed. As a result, High‐Temperature Steam Electrolysis was selected as the most viable near‐term technology to deploy as a part of the Next Generation Nuclear Plant Project.
2.2.1 Graduate Program in Multi‐Disciplinary System Design and Management
Authors: Kohtake Naohiko , Maeno Takashi , Nishimura Hidekazu , Ohkami Yoshiaki
Published: November 2014

“System Design and Management” program, a study that integrates humanities and sciences by crossing many disciplines, is essential to foster talented persons who can lead in the development and operation of large‐scale complex systems. A graduate school of this program was established at Keio University in 2008. The subject of the education is large‐scale complex technological and social systems, with an education curriculum constructed and practically oriented lectures provided such that students can acquire a capacity of system thinking, a design faculty in line with system life cycles and system management abilities. By collaborating with industries and related stakeholders such as domestic and international educational research institutions, we designed an educational curriculum and recruited faculty members, developed educational facilities and research centers, recruited students, provided education, and moreover designed the method of publishing accomplishments. As for the establishment of the graduate school in April 2008, the educational curriculum was formed to provide students with opportunities to acquire must‐learn capability and knowledge that were classified into six groups. The validity of the education method was confirmed based on verification of the students' self‐evaluation, evaluation by the external evaluation committee and accomplishments by students such as papers, after the first two years of graduate education.
2.2.2 Getting Design Right: Systems Engineering for the Non‐Engineer
Authors: Jackson Peter L.
Published: November 2014

Our goal is to disseminate the systems engineering process to as broad an audience as possible. This audience includes freshmen engineers, students from non‐engineering majors, as well as working managers and staff from a host of different occupations. Reviewing the impediments to the dissemination effort and the success of the Six Sigma movement, we articulate the requirements that a curriculum for non‐engineers should satisfy and we propose a particular blended curriculum that satisfies these requirements and highlight its features. We point to three implementations of the curriculum. Experience with this form of the curriculum is still in its infancy.
3.1.2 Exploring Resilience Measurement Methodologies
Authors: Erol Ozgur , Henry Devanandham , Sauser Brian
Published: November 2014

The new paradigm, known as “resilience engineering”, emphasizes the importance of measuring resilience and suggests the development of methodologies to analyze and prepare to improve the resilience of systems. In this paper we review existing resilience measurement methodologies, and provide a detailed discussion on the resilience measurement methodologies, challenges, and further implications. We define system's resilience as the capacity to decrease vulnerability, the ability to change and adapt, and the ability to recover quickly from disruption. Using this definition, we identify metrics which evaluate, more specifically: (1) a system's capability to decrease its level of vulnerability to expected and unexpected events, (2) its ability to change itself and adapt to changing environment; (3) its ability to recover in the least possible time in case of a disruptive event. Based on the discussed enterprise resilience metrics, we use several examples and evaluate a set of illustrative responses to common disruptions.
3.2.1 System Security Capability Assessment Model Development and Application
Authors: Simpson Joseph J. , Endicott‐Popovsky Barbara
Published: November 2014

The INCOSE Systems Engineering Capability Assessment Model (SECAM) has been adapted to apply to the system security domain. Service organizations that do not produce an industrial manufactured product are the initial target of this new variation of capability assessment model. The primary goal of this work is the deployment of an adaptive set of organizational security assessment tools that provide the basis for controlled, structured organizational improvement of the existing security context. A new quick look assessment method is also presented to help an organization minimize the cost and time associated with this type of activity.
4.2.3 The Impact of Understanding the Need and Available Products in COTS Selection
Authors: Ferris Timothy L.J. , Do Quoc
Published: November 2014

Nowadays, more and more engineering solutions are built by integrating Commercial‐Of‐The‐Shelf (COTS) products rather than building subsystems from scratch. The selection of COTS for defence acquisition and upgraded projects presents a great challenge to systems engineers due to the rapidly changing nature of electronic systems, particularly those related to sensors, combat and mission systems, weapons and countermeasures, avionics, and communications. This paper explores the issues associated with the selection of COTS subsystems to be integrated into a larger system. When the total number of COTS components of the same kind to be procured is very low, such as one unit, there are additional constraints impacting the selection and procurement process. A case study is presented based on the development of the Systems Integration Sandpit (SIS) for exploring systems integration issues, fostering model‐based systems engineering and systems engineering education.
4.3.3 Integrating Testability and Diagnosis methods into Airbus Systems Development Process
Authors: Doumbia Fassely , Laurent Odile , Robach Chantal
Published: November 2014

This paper exposes methodologies, based on testing strategies (Start‐Small and Multiple‐Clue), able to support two main steps of Airbus systems development process: formal specification validation activities and systems testing activities on Airbus Final Assembly Line (FAL). The experiments show that these methods can quantify testing efforts, guide functional tests definition, facilitate detailed design coverage activities and ease fault location.
4.4.2 INCOSE Systems Engineering Handbook v3.2: Improving the Process for SE Practitioners
Authors: Hamelin R. Douglas , Walden David D. , Krueger Michael E.
Published: November 2014

The INCOSE Systems Engineering Handbook is the official INCOSE reference document for understanding systems engineering (SE) methods and conducting SE activities. Over the years, the Handbook has evolved to accommodate advances in the SE discipline and now serves as the basis for the Certified Systems Engineering Professional (CSEP) exam. Due to its evolution, the Handbook had become somewhat disjointed in its treatment and presentation of SE topics and was not aligned with the latest version of International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 15288:2008, Systems and Software Engineering. As a result, numerous inconsistencies were identified that could confuse practitioners and directly impact the probability of success in passing the CSEP exam. Further, INCOSE leadership had previously submitted v3.1 of the Handbook to ISO/IEC for consideration as a Technical Report, but was told that the Handbook would have to be updated to conform with the terminology and structure of new ISO/IEC15288:2008, Systems and software engineering, prior to being considered.

The revised INCOSE Systems Engineering Handbook v3.2 aligns with the structure and principles of ISO/IEC 15288:2008 and presents the generic SE life‐cycle process steps in their entirety, without duplication or redundancy, in a single location within the text. As such, the revised Handbook v3.2 serves as a comprehensive instructional and reference manual for effectively understanding SE processes and conducting SE and better serves certification candidates preparing for the CSEP exam.
4.5.2 Model‐ Based System of Systems Engineering with UPDM
Authors: Hause Matthew
Published: November 2014

The Unified Profile for DoDAF and MODAF, (UPDM) initiative was started by members of INCOSE and the OMG. UPDM provides a consistent, standardized means to describe DoDAF 1.5 and MODAF 1.2 architectures in SysML/UML‐based tools as well as a standard for interchange. The concepts found in the Systems Modeling Language (SysML) such as parametrics, blocks, complex ports, enhanced activity modeling, and cross‐cutting constructs improve the state of the art for systems engineers and architects. The formal meta‐model basis of UPDM also provides a basis for trade‐off analysis, model execution, requirements traceability, and the transition to systems development and implementation. Finally, the interconnections between views can help combat stovepipe development and improve communication. This paper looks at the current direction of UPDM, how it is improving the state of the art for system architects, and enables interchange of architectural information. We will also examine some of the latest concepts found in DoDAF 2.0 and how the UPDM Group is addressing these.
5.3.1 Organizational Risk Management — The Balanced and Unbalanced Portfolio
Authors: Weiler Moshe , Arbetman Yaron
Published: November 2014

Many organizations encounter problems in constructing the organizational risk management from the projects' risks information in a bottom‐up approach. The main problem dealing with the bottom‐up approach, i.e., to collect the risks values from the projects, and accumulate them to the organization level, is how to reflect both, very high‐edge risky projects and “more of the same” projects as well as “Mega” projects and small ones, on the same scale. In this article, we have suggested a new methodology that will give the organization's management this unique view on one chart. It will also help defining the norms of that organization in respect to which projects are within the “normal behavior” (Balanced Projects), and which projects are outside the “normal behavior” (Unbalanced Projects).
5.3.2 Risk Cube Data Biases
Authors: Siefert William T. , Smith Eric D.
Published: November 2014

Risk cubes, actually a 5times5 matrix, 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.
6.2.2 Applicable Documents
Authors: van Gaasbeek James Robert
Published: November 2014

It is a common practice to refer to applicable documents in both programmatic and product‐specification documents in contracted development. The practice permits inclusion of a vast amount of lessons‐learned and Government and commercial standards and best practices that can be referenced without the need to include the information directly in the document, or to maintain the referenced information. Product requirements documents often specify interfaces and interoperability characteristics by reference to interface control documents included in the list of applicable documents. Benefits accruing to the product from the use of applicable documents are reduced overall cost, better products and better interoperability. Costs accruing to the product development effort are the cost of maintaining visibility on changes to applicable documents outside the control of the Program and the cost of verification of all included requirements.
6.3.2 Organizational Assessment Models for Enterprise Transformation
Authors: Perkins L. Nathan , Nightingale Deborah , Valerdi Ricardo , Rifkin Stan
Published: November 2014

Organizational assessment is becoming increasingly important, both as a cross‐time and cross‐industry measurement and as a guiding force in enterprise transformation. Assessments provide crucial information about strengths, areas for improvement and potential investment strategies for achieving performance benefits. As performance is being recognized as a complex and multifaceted construct, assessment tools seek to incorporate and reflect a holistic measurement of performance across multiple dimensions such as stakeholder value, leadership, culture and quality.

With a growing range of tools available, this paper examines four prevalent assessment strategies as examples of different approaches to organizational assessment. We compare these tools in terms of use cases, principles measured, outputs and contextual factors. Due to a lack of causal evidence between the principles assessed and objective evidence of improved organizational performance, organizations should utilize the assessment tool that best aligns with key transformation values or goals. By committing to a relevant and useful assessment tool and fully integrating it into strategic processes, organizations are able to achieve the internal knowledge and historical data necessary to improve performance and drive ongoing transformation efforts.
6.4.1 Value Engineering: A Systematic Team Approach for Strategic Planning
Authors: Braase Lori , Grgich Jodi , Conner Alison , Jeffs Margie , Martinson Darcie
Published: November 2014

The Value Engineering (VE) Methodology is an effective tool for business or strategic planning. While there are many viable strategic planning processes, the “Balanced Scorecard” approach (formally developed by Robert Kaplan, PhD, and David Norton, PhD), is highlighted here using VE and function analysis to develop strategy maps and scorecards. As part of the VE Methodology, Functional Analysis System Technique (FAST) diagramming offers an integrated approach and structure to strategy map development by formulating a cause and effect relationship and establishing the “how” and “why” behind the strategy map. By holistically utilizing the VE Job Plan, one is able to move from strategic thinking all the way through to measurement and execution of a strategy.
6.5.1 Maintenance Performance Modeling to Sustain System Operational Requirements for Complex Military Platforms
Authors: Kerr Glen , Nesterov Sergey
Published: November 2014

Both military and commercial asset management practices are receiving renewed scrutiny to reduce the logistic cost of ownership. Asset managers are being asked to analyse and improve on maintenance practices. This paper describes the application of computer modelling techniques to evaluate the effectiveness of existing and alternate maintenance solutions. Modelling using computer simulations is widely applied to new system development and allows complex processes and structures to be analysed and quantitatively evaluated. However, less work has been undertaken in applying modelling techniques to analyse existing in‐service maintenance systems performance against potential alternatives.

Specific characteristics of a stochastic model for complex military platforms have been identified to assure that model implementation accurately represents suggested maintenance processes. Systems Engineering methodology is used to create and analyse targeted maintenance models in question: reactive and proactive variants. Existing maintenance process has been described and performance measurement criteria have been identified. In conclusion the models' effectiveness has been evaluated and complemented by its sensitivity analysis. The objective is to present the case study of maintenance modelling applied for the complex military platform.
7.1.0 Lean SE: Who Can Afford to Ignore it?
Authors: Secor Deborah , Oppenheim Bohdan “Bo” W. , Malotaux Niels , Sillitto Hillary , Zonnenshein Avigdor
Published: November 2014

In the last several years the emerging field of Lean Systems Engineering has matured to a actionable body of knowledge. The Lean SE Working Group of INCOSE is one of the fastest growing Working Groups, now at 115 members. In 2009, 14 experts from the WG released a major product called Lean Enablers for Systems Engineering (LEfSE). It is a list 194 best SE practices, the do's and don'ts of SE.

SE is regarded as a sound practice but not always delivered efficiently. Lean SE applies the wisdom of Lean Thinking, the management paradigm of hugely successful Toyota, to SE.

Lean SE does not mean “less SE”; it means “more SE, better SE, for streamlined execution of the program”. The Value in Lean SE is “Flawless Mission Assurance delivered with minimum waste in the fastest possible time”.

The four panelists will present differing perspectives on Lean SE, and the challenges that inhibit the implementation.

A summary of Lean SE and LEfSE

Human behaviors that inhibit Lean implementation

The need for urgency in applying Lean, and open questions;

Experiences from applying Lean elements in SE

The presentations will be followed by a short discussion among the panelists, and by a Q&A session.
7.2.2 Mental Mistakes Made by Systems Engineers While Creating Tradeoff Studies
Authors: Bohlman James , Bahill A. Terry
Published: November 2014

Designing a system requires evaluating multiple architecture design alternatives against multiple evaluation criteria. This is called a tradeoff study. This paper presents common mental mistakes that people make when doing tradeoff studies. The authors examined tradeoff studies created by system analysts and excerpted examples of these mistakes. There are suggestions to help systems engineers avoid making these mental mistakes while doing tradeoff studies.
7.2.3 Decisions in the Face of Risk
Authors: De Spain Mark
Published: November 2014

The author of a popular book on risk and decision analysis made the statement that “The revolutionary idea that defines the boundary between modern times and the past is the mastery of risk: the notion that the future is more than a whim of the gods and that men and women are not passive before nature.” (Bernstein 1998, 1) While this book was written primarily from the perspective of economics and finances, the premise that the tools for making a reasoned prediction of the future, based on past experience and present decisions, goes to the heart of what it means to “do” systems engineering. This paper examines the nature of uncertainty, risk and decision analysis, particularly as understood within the historical context and the continuing development of the “art and science of decision.”
7.4.2 “Meta” Matters
Authors: Martin Richard , Robertson Edward
Published: November 2014

Misunderstandings related to “meta” often cause serious problems in systems engineering. This paper attempts to elucidate some of those misunderstandings, particularly as they apply to systems architectures. It examines how standards can provide discipline and clarity, suggesting how standards themselves must be done without falling into similar “meta” traps.
8.4.1 Infusing Healthcare with Resilience
Authors: Nemeth Christopher , Cook Richard
Published: November 2014

Resilience engineering strives to build the adaptive capacity of systems that is essential to continue operations in the face of substantial challenges. The healthcare enterprise provides a compelling opportunity to consider resilience as a desirable trait of systems. Clinicians, from physicians to nurses and technicians, are a source of resilience and develop and rely on artifacts from status boards to information systems and equipment to perform cognitive work. While information technology (IT) systems have been promoted as a means to improve patient safety, current information systems and equipment systems are brittle and erode resilience instead of contributing to it. Based on a five‐year study funded by the Agency for Healthcare Research and Quality, we present a concept for an infusion device interface that would contribute to resilience.
9.1.0 Service Systems and Systems Sciences in the 21st Century
Authors: Wilby Jennifer , Kijima Kyoichi (Jim) , Ing David , Metcalf Gary
Published: November 2014

Progress on the emerging science of service systems will be advanced by improved collaboration between scientists, engineers, managers and designers. The endorsement of SysML by the OMG provides an option for rigourous descriptions of service systems.

The domains modeled by systems engineers have generally been technical in nature. “A service system can be defined as a dynamic configuration of resources (people, technology, organisations and shared information) that creates and delivers value between the provider and the customer through service” (IfM and IBM 2008). Service systems in the 21st century not only include service machines, but also commercial relationship interactions and public infrastructural and social offerings. Broadening the domains of interest to the subjective and the ambiguous presents challenges not only the formal modeling of systems, but also the effective attainment and communications of shared understandings.

A group of senior researchers with shared knowledge in the systems sciences has been conducting conversations about service systems, applying modeling tools in both face‐to‐face and distributed communications. Findings on joint learning, obstacles, and the responses from observers will be discussed.
9.2.1 RELAAy — A Tool to Guide HSI Requirements
Authors: Colombi John M. , Hardman Nicholas
Published: November 2014

Archives of Air Force mishap investigation reports provide a large data set of documented system failures. In this paper, we present a tool that analyzes human‐related errors in these mishaps and quantitatively predicts focus areas for new system development. Even new systems have similarities, either in structure or function, to legacy systems. Knowing what design induced errors have plagued past human‐machine interactions can guide new Human Systems Integration (HSI) requirements generation. This is accomplished using the Human Factors Analysis and Classification System (HFACS) as the underlying data. Our tool, with a novel method of using the entire mishap data set over the last five years is demonstrated through its application for a next generation unmanned aerial system (UAS). Lastly, the HFACS data is mapped to the domains of HSI for program office consumption.
9.4.1 Determining Reliability Requirements and Testing Costs in the Early Stages of Single Use Medical Product Design
Authors: Eubanks Fritz
Published: November 2014

The production of single use medical devices, particularly for home use by patients, continues to grow, and the reliability of these devices is a primary concern for manufacturers and end‐users. The systems engineer tasked with the device development needs methods and tools to establish reliability requirements and provide cost estimates for the testing necessary to show compliance with those requirements. This paper examines methods for determining reliability requirements, the cost of reliability testing for single use medical devices in the design input phase of product development, and how the costs of testing and potential errors can be used to perform trade‐off analysis between reliability tolerance and confidence level.
10.1.1 A Process and Data Model for Automotive Safety‐Critical Systems Design
Authors: Guillermo Hugo , Góngora Chalé , Taofifenua Ofaina , Gaudré Thierry
Published: November 2014

This paper presents the formalization of an innovative design process for automotive safety‐critical systems. The objects and data used or produced throughout the different steps of the system design process (e.g. requirements, safety goals, functions, components, validation and verification activities…) are formalized in an integrated data model (or meta model). Besides the novel aspects of the design process, which will only be briefly mentioned in this paper, the originality of the approach lies on the combination of two normally independent models: a Systems Engineering data model and an Automotive Safety data model. The latter stems from the future ISO26262 standard relative to the safety of automotive embedded systems. The results presented in this paper are part of the Systems Engineering deployment initiative at Renault and represent the very first efforts aiming at the compliance with the future ISO26262 standard.
10.2.1 Model‐Based Development of Spacecraft Onboard Functions
Authors: Yamada Takahiro , Matsuzaki Keiich
Published: November 2014

This paper presents a method of development of spacecraft onboard functions based on a functional model of spacecraft (FMS). This model provides a standard framework for designing the functions of onboard components. It also enables development of a standard database (called the Spacecraft Information Base or SIB) that stores functional information on any onboard component.

To monitor and control onboard components, we have developed a standard protocol called the Spacecraft Monitor and Control Protocol (SMCP). Since the specific information on the functions of any onboard component can be retrieved from the standard database, the design of SMCP is very simple. SMCP specifies types of messages used for monitor and control spacecraft onboard components, and the formats of the messages used for each onboard component are stored in SIB, too.

The functional and operational characteristics of onboard components can be specified, to some extent, by parameters used by FMS and SMCP, which are stored in SIB. This information can be used by any application program including spacecraft testing and operations systems. Generic application programs that can be used to the design, testing and operations of any component or any spacecraft can also be developed because they can retrieve the functional and operational information on specific components from SIB.

Furthermore, the part of the software installed in onboard components that is responsible for the functional and operational behavior can be automatically generated from the parameters of FMS and SMCP stored in SIB, as long as it is described with these parameters.