bluuebunny/crossref_metadata_2025_split huggingface dataset:
8.2.0 I know what I want! Supply Chain Views on Delivering Requirements
Authors: Elphick Jon , McPharlin Tom , Verhoeven Nout H. , Birkelbach Ronald L. , Gharatya Kuldeep 
Published: November 2014

AbstractThis panel will examine whether it is practical or desirable to have a common approach to requirements management across the supply chain. Using the rail supply chain as the example, it will explore the different drivers, including:
How railway operators/agencies can minimize integration risk and reduce supplier risk through the bidding and award process – particularly in an age of global competition, where translation of languages and cultural differences add to the challenge of requirement interpretation?
How systems suppliers balance responsiveness to ‘unique’ sets of project requirements with their goal to standardize product development/product offerings?
What challenges both clients and suppliers face when seeking consensus on when system acceptance is attained? How do the perspectives on conducting systems verification & validation differ? How to overcome the reluctance of user stakeholders to transfer the system to operational service? This panel will bring representation from both clients (operators/agencies) and suppliers to compare and contrast approaches to requirements engineering – from developing concepts/eliciting user needs, managing requirements, verification & validation to system acceptance/turnover.
Panelists will highlight changes in practices intended to improve interactions between clients and suppliers and particularly note areas that would benefit from further improvement. The panel will also look at the role Systems Engineers must play across the supply chain at various stages of the lifecycle. As well as comparing different practices and drivers in the transportation sector, this panel and the discussion it seeks to stimulate will provide a more general insight into the differences between client and supplier side approaches to systems engineering.The panel will provide an introduction to the different approaches to requirements engineering in a non‐traditional sector, including requirements development, management, verification and validation. It also seeks to elicit insight into contrasting SE perspectives of clients/owners and suppliers and whether optimization can be achieved where the supply chain members must share varied roles and functions to apply SE across the entire requirements lifecycle.Come and joint us to debate and explore the dynamics within this sector's supply chain and how its approaches to requirements management compare or contrast with other sectors – where does best practice reside? What can be exchanged?
8.4.0 Student Division Program Panel Discussion
Authors: Mason David , Haskins Cecilia , Smith Eric , Luster Eric , Willard Tom , Walker John 
Published: November 2014

AbstractThe Student Division within INCOSE was reignited at the 2010 IW with Dave Mason from the San Francisco Bay Area Chapter being appointed to lead the effort. During the past year interest has increased at all stakeholder levels. The Student Division Program panel discussions will address the Value Propositions from each of the 4‐Way Benefit Model stakeholders perspective, and how these are used as success metrics for each student Division. This panel discussion will be followed by the brief introduction of the INCOSE 2011 International Science and Engineering Fair (ISEF) winner.
9.5.0 ABET Accreditation of SE programs: How is it going and why are we doing it?
Authors: Olwell David , Brown Phil , Ryan Julie , Farr John , Sutton Steve , Adcock Rick 
Published: November 2014

AbstractINCOSE has become one of the professional societies overseeing ABET accreditation for systems engineering. This session present an overview of INCOSE's accreditation strategy, perspectives from recent evaluators of an undergraduate and a graduate program, an international perspective, a summary of why one major school has decided not to accredit its program, and a summary of why another did attempt accreditation. A floor discussion will follow.
9.6.1 Normative Approach to Six Sigma Project Selection
Authors: Kindi Mahmood Al 
Published: November 2014

Abstract— This paper introduces the notion of expected utility and how to implement it in Six Sigma. Moreover, it intends to bridge the gap between process variation and the economic impact in order to have a clear view of economical consequences. It is agreed that the key for the success of any manufacturing firm is to select the most profitable project. There is a significant awareness in the Six Sigma community of the need for a tool that incorporates uncertainties, is data driven, and takes into account all financial aspects. Having an outstanding process quality is not necessarily an economical objective.
10.1.1 Software Systems Analysis Using Stress‐Strength Probability Functions
Authors: Wilder James O. 
Published: November 2014

AbstractThe potential variability of external inputs and their possible “drift” outside the software design boundaries is a common cause of failure in real‐time mission software. Critical interactions increase as the complexities and breadth of the interacting software systems increases. In system‐of‐systems interactions, the possible combinations of critical interactions can be very large. A software fault in one module of a system may coincide with a fault of an entirely different module within the same system, or another subsystem, to produce unsafe conditions or even system failure. Unforeseeable combinations can cause cascading failures within the system. When such systems have availability or safety requirements that are defined in terms of probabilities over time, these requirements must be applied at the top‐level of the system to characterize overall systemic performance. The requirement could be stipulated as a probability that the system does not encounter failure during the mission. This paper introduces the concept of analyzing critical system interactions in terms of both the operational profile of the system as a stressing function, and the strength of the system, a function of software complexity. The stressing and strength probability distribution functions are analyzed for interferences. In cases where variates within the stressing probability density function exceed variates within the composite system strength density function, the system will be prone to failure during operations. The region of interference between the stressing and strength distributions is itself a probability distribution function, which enables the statistical assessments of large scale system of systems, similar to the stress – strength analysis of reliability theory.
10.2.2 Using Boolean Operators in Multiple‐Domain Matrices
Authors: Maurer Maik , GmbH Martin Strattner Teseon 
Published: November 2014

AbstractMatrices are a popular method for modeling systems in complexity management. They support the accurate structural acquisition of information, and guarantee a machine readable state of data. However, with today's matrix representations, Boolean operators cannot be intuitively depicted without simplifying the system.In this paper, we present a new approach for modeling Boolean operators (AND, OR, XOR) in matrices. Boolean operators induce conditions between more than two nodes. Wherever a determination of a combination of nodes or edges is necessary, we place any of these paths in separate, superimposed matrices. The creation of instances of nodes in these superimposed matrices permits their belonging to different paths. For a better handling, this multidimensional matrix is flattened and the instances of nodes are placed side by side. In addition, we merge operators with their predecessor or successor‐node, for a size‐reduction and simplification of the matrix.
10.3.1 Applying the Plan‐Do‐Check‐Act Cycle to Develop Best Practices in Remote Online Systems Engineering Education
Authors: Squires Alice , Cloutier Robert 
Published: November 2014

AbstractSystems engineering educators are inherently challenged to provide effective education to industry and government practitioners. Separating instructors and students by time and location, as is the case in remote online education, compounds the challenge. This paper summarizes research on the impact of the use of various pedagogical approaches on the effectiveness of teaching systems engineering in a remote online environment. Using that research as a leverage point, the Plan‐Do‐Check‐Act (PDCA) cycle is presented as a viable process for developing best practices for remote online systems engineering education.
10.3.2 The Development of an Architecture Framework for Systems Engineering Process Simulators
Authors: Ferreira Susan , Faezipour Misagh 
Published: November 2014

AbstractSystems engineering process simulators can help users to explore risks and evaluate the consequences of various project, process, and organization decisions. These types of simulators can incorporate the complex system dynamics associated with various concerns and include critical factors, their associated relationships, and corresponding effects, allowing one to reason and explore various decision options. Simulators can also help educate current and new engineers to understand the multi‐faceted issues related to systems engineering projects and processes. In support of the development of these types of simulators, this paper discusses the need for an architecture framework for systems engineering simulators. An architecture framework is proposed as an enabler to assist in the development of systems engineering process simulators.
11.1.3 Identifying the Most Critical Documents and Reviews for Small Information Technology Projects
Authors: Mulhearn Michael , Brouse Peggy 
Published: November 2014

ABSTRACTManaging Information Technology projects has historically been a very difficult endeavor. For the project manager, there are many project management (PM), systems engineering (SE), and information technology (IT) standards, bodies of knowledge, process models, and management models to use to help manage a project. The wealth of information makes it difficult for project managers and systems engineers of small IT projects to filter through the information and determine the specific documents and reviews that are the most useful to effectively and efficiently manage the project. The goal of this research is to identify the documents and reviews that are most helpful for managing small IT projects.
11.3.2 The Three Ts of Systems Engineering – Trading, Tailoring, and Thinking
Authors: Beasley Richard , Partridge Richard 
Published: November 2014

AbstractDefining what it is about Systems Engineering that makes it distinct from “normal” Engineering is one of the major challenges when making Systems Engineering explicit in an engineering company. This paper presents a view of Systems Engineering that emphasizes how the underpinning Systems Thinking enables Systems Engineering to ensure that the analytical thinking of normal engineering is used to the best advantage. This involves recognizing that trading is a natural part of the solution generation process. Trading is illustrated by an example from Rolls‐Royce's Naval Marine activities. The definition of Systems Engineering role within Rolls‐Royce is described as an example of tailoring. Systems Thinking should not only be used to understand the problem for which an “Engineered” solution (or system) is required, but also to understand the way the problem may be solved and the organization and roles needed to create the solution.
11.3.3 Behavioral Models and Improved Quality in Architecture‐Centric Engineering
Authors: Brouse Peggy , Jacobson Christopher P. 
Published: November 2014

AbstractArchitecture‐Centric Engineering (ACE) is described by the authors in 'Achieving Interoperability for Critical IT and Communication Systems' (Desourdis, et al, 2009) as an engineering approach that derives requirements and performance targets from enterprise scenarios. As part of this approach, this paper summarizes the use of behavioral models for improved quality as a repeatable, integrated component of systems engineering. Predictable quality measurement is possible at transitions earlier in the engineering lifecycle. Case Study, behavior model analytics and summaries from expert peer reviews are presented to support this quality improvement. An approach for the integration of behavior modeling methods as a quality mechanism extension is summarized.
Modeling with SysML
Authors: Friedenthal Sanford , Wolfrom Joseph A. 
Published: November 2014

AbstractThe OMG Systems Modeling Language (OMG SysML™) is a general‐purpose, graphical, modeling language for specifying, analyzing, designing, and verifying complex systems that may include hardware, software, information, personnel, procedures, and facilities. In particular, it provides graphical representations with a semantic foundation for modeling system requirements, behavior, structure, and parametric equations that can integrate with a broad range of engineering analysis. SysML represents a subset of UML 2.0 with extensions to satisfy the requirements of the UML™ for Systems Engineering RFP. The OMG SysML™ Specification was adopted in May 2006. For more information on SysML, including articles, tool vendor and related links, and the specification, go to http://www.omgsysml.org/.This tutorial provides an introduction to how SysML can address your systems engineering needs, including: background and motivation, an overview of the SysML diagram types and language concepts, a demonstration of how the language can be used throughout a Model‐based Systems Engineering (MBSE) process. A class exercise is included to help solidify the student's understanding of the language. The course will also include a brief introduction to a typical SysML tool.Attendees should gain appreciation of the value of model‐based Systems Engineering versus legacy, document‐centric methods; awareness of the graphical notation; and a high level understanding of when and how a Systems Engineer can exploit the various diagrams and models as part of their systems engineering process.
A Simple Prescription For Requirements Success
Authors: Grady Jeffrey O. 
Published: November 2014

AbstractIn the development of systems and entities thereof it is extremely important as a prerequisite to design to know clearly what is needed, what are the essential characteristics that the design must have. We system engineers call these requirements and we prepare specifications for each entity in a system and for the whole system containing in each case all of the essential characteristics the design must possess. There are few enterprises and programs within them that are applying an effective requirements analysis approach but it is not all that difficult to do so. There are a few simple activities that can be combined to form a prescription for success. We should possess a preferred template for each kind of specification we will have to develop. We should model the program problem space and derive the requirements from model artifacts. Each paragraph of a specification should be linked to a model and a discipline provided by a particular engineering department of the developing enterprise such that on a program people from that department will apply that model to derive requirements that fall into that paragraph of program specifications. The model applied on all programs should be the same and it should be a comprehensive model meaning it is effective no matter how the design will be implemented in hardware, software, or people doing things. The modeling artifacts should be captured, reported, and configuration control applied to them. Finally, a program should establish and maintain traceability between the modeling artifacts and specification content using a requirements analysis sheet.This paper covers three comprehensive models, one of which an enterprise should select and apply on all programs. The paper also shows a preferred specification template and how to arrange traceability between the specification paragraphing structure, the modeling artifacts, and engineering department structure. In order to take advantage of this simple prescription an enterprise does have to apply effective management to initiate and continue movement from the present to a condition of success.
Requirements Engineering for Large Scale Systems: Contract Based Systems
Authors: Berenbach Brian , Worl John 
Published: November 2014

AbstractRequirements elicitation and management for contract based projects is significantly more complex than for product or product line development. For example, many practitioners are unaware of the fact that the traditional “V” model for requirements tracing does not work where there is a legal contract describing project deliverables; nearly every aspect of requirements engineering is more challenging, from elicitation to risk analysis and compliance management. This half‐day tutorial will describe in some detail contract issues that are typically not discussed in requirements texts and courses.
Correlating Product and Process Measures as a Model for Systems Engineering Measurement
Authors: Carson Ronald S. 
Published: November 2014

AbstractCurrent measurement industry emphasis on process measures and compliance ignores elements of the history of measurement. The failure to establish product measures and provably correlate them with process measures leads to open‐loop management systems that can only measure process compliance, with unknown effect on product quality. The new INCOSE Measurement Primer attempts to begin addressing this important distinction. In this paper a set of standard categories of measures are applied to various Systems Engineering work products identified as “output” in the INCOSE SE Handbook. Process and product measures for each process output are proposed, along with correlations between them, and associations to the INCOSE SE Leading Indicators where applicable.
Examining Survivability of Systems of Systems
Authors: Mekdeci Brian , Ross Adam M. , Rhodes Donna H. , Hastings Daniel E. 
Published: November 2014

AbstractPrevious research has identified design principles that enable survivability for systems, but it is unclear if these principles are appropriate and sufficient for systems of systems as well. This paper presents a preliminary examination of how some of the characteristic properties of systems of systems may enable or hinder survivability, based on existing design principles and a newly proposed taxonomy of disturbances. Two new design principles, defensive posture and adaptation, are introduced. The next phase of research will be to conduct empirical studies to validate the design principles against some of the characteristic properties of systems of systems, and test hypotheses about how survivability will be affected.
Enabling the Net‐Centric Systems Model through Adapting Enterprise Security Services to the Mobile Users
Authors: Farroha Bassam S. , Farroha Deborah L. 
Published: November 2014

1.0 ABSTRACTThis paper investigates the requirements, technologies and risk mitigation techniques for securely sharing information with the tactical Mobile users while protecting the data and the information systems from intruders and malware. The systems engineering concepts applied to the design and development of the Enterprise need to include the security criteria and mitigating techniques to handle Mobility, and reliance on Cloud services to obtain the required data and services. A strong emphasis is placed on analyzing secure data sharing outside its security domain with services, agencies, coalition partners and state/local authorities. There has been an increased demand for multiple levels of secretive data at the tactical edge; however the threat level at that point has been increasing dramatically compared to the enterprise environment. The next generation information systems need to eliminate the stovepipe architectures and open the doors to share information across traditional and non‐traditional domain boundaries, while dealing with the increased threats stemming from wireless attacks, virtualized resources, and limited investment. This leads the sponsoring organization to think in terms of System of Systems when developing independent capabilities that needs to operate as consumers or producers with other systems. Agility in development is also paramount in today's budget sensitive and fluid requirements environments.
1.2.2 SE in a Cloud: Retiree Knowledge Capture and Consumption Optimization
Authors: Shelby Kenneth R. , Sarkani Shahram , Mazzuchi Thomas A. 
Published: November 2014

AbstractSystems Engineers have a grand opportunity to leverage the Cloud for its collaborative environment capabilities where they can advance their Systems Engineering acumen, effectively articulate knowledge they possess about innovations or insights into existing systems, and effect knowledge transfer before retirement. This paper shares suggestions for authors, who possess good and valuable engineering knowledge, to prepare knowledge assets that are more easily consumed by other Systems Engineers, Specialty Engineers involved in the design, development and build of systems, and other stakeholders like funding source representatives, leadership, customers and end users. A proper balance of illustrations/diagrams/pictures with textual/verbal representations, following the dual‐coding theory, in an interactive Cloud collaborative environment with user‐subjective approaches enabled, will improve knowledge mobilization in the audience. The communication transfer function with human‐in‐the‐loop systems, like retiree knowledge transfer systems, benefit from knowledge capture and consumption optimization. This results in systems that are easier use and therefore are more likely to be used and create value.
1.6.3 What Makes Motif Patterns of Engineering Systems Architectures to Look Alike?
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). We now explain the reasons for the resemblance of these motif profiles of system architectures within various engineering systems families. We explain this by considering a vast variety of system architectures (38 systems architectures arbitrarily chosen) ranging from –electronic circuits, software systems and mechanical engineering systems.