bluuebunny/crossref_metadata_2025_split huggingface dataset:
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

AbstractThe 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

AbstractThe 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

AbstractMany 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

AbstractRisk 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

AbstractIt 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

AbstractOrganizational 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

AbstractThe 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

AbstractBoth 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

AbstractIn 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 SEThe 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

AbstractDesigning 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

AbstractThe 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.”
8.4.1 Infusing Healthcare with Resilience
Authors: Nemeth Christopher , Cook Richard 
Published: November 2014

AbstractResilience 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

AbstractProgress 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

AbstractArchives 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

AbstractThe 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

AbstractThis 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

AbstractThis 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.
10.3.1 Classification of Systems from Component Characteristics
Authors: Shaja A. S. , Sudhakar K. 
Published: November 2014

AbstractIn recent times there is a growing interest in systems architectures in domains like biological systems and social networks leading to useful insights and generalizations. These developments have opened up possibility of investigating architectures of complex engineering systems on similar lines. Architecture of a system can be abstracted as a graph, wherein the nodes/vertices correspond to components and edges correspond to interconnections between them. Graphs representing system architecture have revealed motifs or patterns. Motifs are recurring patterns of 3‐noded (or 4, 5 etc.) sub‐graphs of the graph. Over‐represented motifs have offered insights into the basic functionality of systems in some cases. Concept of motif significance profiles (i.e., proportions of various motifs present in a system) has also given rise to interesting insights. These profiles are seen to be highly correlated across systems of the same family (i.e., very similar proportions of motifs are present in systems of same type). Recently these profiles are proposed as classifiers for system architecture. We now show that the same classification of systems can be arrived at by merely looking at characteristics of components/nodes from which systems are synthesized. In other words, we argue that the motif significance profile of a system is due to the properties of the individual components that form the system. We have shown this by considering a vast variety of systems (38 systems arbitrarily chosen) ranging from – biological systems, languages, electronic circuits, software systems and mechanical engineering systems.
11.1.0 Architecting the Enterprise: Is INCOSE up to the challenge?
Authors: Martin James N , Arnold Stuart , Ring Jack , White Brian , Martin Richard 
Published: November 2014

AbstractThe enterprise consists of much more than just hardware and software. Yet most SE literature deals with systems only composed of these technological components. This panel of experts in the domain of Enterprise Systems Engineering will draw from their experience to describe some of the special challenges in architecting the enterprise. They will recommend necessary changes to the SE discipline to enable better development and evaluation of enterprise architectures. Special methods and tools required at the enterprise level will be discussed. We will discuss the special nature of the “soft” elements of the enterprise: people, policies, practices, & procedures. We will also discuss some of the other elements not often dealt with by traditional SE: platforms, media, infrastructure, facilities, & (low‐tech) equipment.
11.3.2 A Method for Total Baseline Integration
Authors: Brown Gary 
Published: November 2014

AbstractAdvancements in technology continue to enable our society to design and implement more complex systems to achieve more ambitious missions. As systems become more and more complex, it is incumbent on the systems engineering practitioners to develop new and innovative methods to ensure our systems are cable of fulfilling their intended missions in an efficient and effective manner. This paper describes one such method known as Total Baseline Integration™ (TBI), developed through corporate investment at Booz Allen Hamilton. As part of an internal study on why programs to develop large complex systems often fail to meet cost, schedule, and/or performance objectives, one recurring theme became evident. As systems grow in complexity, it becomes more and more difficult to tightly integrate the programmatic baselines for performance, cost, schedule, and risk. We have a tendency to further complicate this situation by setting up our organizations such that these functions do not come together organizationally until they reach the Program Manager level. This is primarily due to the fact that control and management of these baselines requires different skill sets. There is a natural tendency to separate the staff performing these duties and often times they are even acquired through separate procurements of support staff. This paper will discuss a methodology we have developed to physically link and analyze these baselines. The goal and ultimate result of the methodology is to provide a more holistic assessment of the impact across program baselines for any proposed changes or alternatives.