bluuebunny/crossref_metadata_2025_split huggingface dataset:
4.2.0 Panel 4.2.0: Managing Rail Requirements: Case Studies Applying SE to Rail/Transit Projects
Authors: Krueger M. , Chin D. , Gharatya K. , Irving M. , Moran M. , Thomas P. 
Published: November 2014

AbstractWhat represents the tipping point for a predominantly brick & mortar industry like rail/transit to finally adopt an SE approach? Some argue the industry's recent struggles to successfully implement software‐intensive, technology‐driven projects are a clear wake‐up call to address requirements management in a systematic, disciplined way.Attempts to manage requirements have yielded mixed results. Are business enterprise needs truly linked to project delivery goals? How will technical staff be convinced to shift their focus to user needs rather than pre‐defining the solution? Can program managers see requirements management as their means to achieve schedule and budget goals? Case studies highlight attempts to transform an industry: lessons learned from mismanaged requirements – analyzing where the process breaks down; applying requirements management methods to support automating rail operations; novel techniques for triaging & tagging requirements engaging the whole project team.
6.2.3 Five Avoidable Problems in Process Improvement
Authors: Hoppe Markus 
Published: November 2014

AbstractSeveral factors are the sources for the increasing pressure on companies to change. However, a majority of change programmes fail. In this paper we discuss five avoidable problems in improvement initiatives that may lead to such project failures. To each problem we suggest a solution, and describe how it can be implemented in a simple way. The solutions are: create problem awareness, allocate key people that are able and willing to support the project teams, start with one pilot project, allocate qualification topics to roles, and define project milestones and review criteria.
7.4.3 Some Early History of Systems Engineering – 1950's in IRE Publications (Part 1): The Problem
Authors: Ferris Timothy L.J. 
Published: November 2014

AbstractThis paper is part 1 of the first stage in a project investigating the early history of systems engineering. Many current texts refer to the post World War II era as the origin of systems engineering as a means to overcome the problems of systems development projects that failed to deliver satisfactory product systems according to budget and schedule. The present paper investigates primary sources from the 1950's period to develop an understanding of the concerns present in the engineering community when systems engineering is said to have emerged in order to develop an understanding of the objectives and issues of concern addressed. The sources have been investigated from the perspective of the evidence that they provide concerning the reasons why systems engineering emerged with the characteristics that it developed.
7.4.4 Some Early History of Systems Engineering – 1950's in IRE Publications (Part 2): The Solution
Authors: Ferris Timothy L.J. 
Published: November 2014

AbstractThis paper is the second stage in a project investigating the early history of systems engineering. Many current systems engineering texts refer to the post World War II era as the origin of systems engineering as a means to overcome the problems of systems development projects that failed to deliver satisfactory product systems according to budget and schedule. The present paper investigates primary sources from the 1950's period to provide an understanding of the early stages of development of the systems engineering solution to the problems that had been observed and discussed in part 1 of this study. The sources have been investigated from the perspective of the evidence that they provide concerning the systems engineering solution to the problems which had been experienced and why these solutions were regarded as satisfactory.
7.5.2 Risk Analysis
Authors: Smith Eric D. , Bahill A. Terry 
Published: November 2014

AbstractThis paper presents a risk analysis example with quantitative data for frequency of occurrence and severity of consequences. It presents an algorithm for deriving severity scores. Then it shows use of a risk management tool that is commonly used in industry. Finally it presents many other factors that affect human perception of risk. Identifying and controlling risk is a characteristic behavior of intelligent enterprises.
8.3.2 A Formal Universal Systems Semantics for SysML
Authors: Hamilton Margaret H. , Hackler William R. 
Published: November 2014

AbstractOMG SysML™ is a general purpose systems modeling language adopted by OMG in May, 2006. Used for specifying, analyzing, designing, and verifying complex systems; it provides graphical representations with a semantic foundation for modeling system requirements, behavior, structure, and integration with a broad range of engineering analysis. SysML represents a subset of UML2 with extensions needed to satisfy the requirements of UML for systems engineering. The goal is to enhance systems quality, improve the ability to exchange information among tools, and help bridge the semantic gap between systems, software, and other engineering disciplines (Friedenthal et al. 2006). This paper provides an analysis of how SysML may be further enhanced by a more formal framework that uses the semantics, based on the axioms of a general systems theory, of the Universal Systems Language™ (USL™), 001AXES™ (Hamilton April 1994). At the same time SysML provides 001AXES with a standardized based approach for capturing this formalism.001AXES has had a focus on reliable systems since its inception. Instead of object oriented and model driven systems, the designer thinks in terms of system oriented objects™ (SOOs™) and system driven models. Much of what seems counter intuitive with traditional approaches, that tend to be software centric, becomes intuitive with this approach, which is system centric. How to minimize errors and maximize integration of systems to software, reuse, open architectures, evolvable systems, and productivity in a system's development becomes better understood; this understanding can then be used as a means to an end—designing and building better systems.001AXES is used today to address problems considered difficult to solve with traditional approaches (Hamilton and Hackler 1991, 2003–2004); it can be used to address these problems for SysML users as well. Its preventative paradigm and how the 001AXES kernel can provide SysML with a formal foundation will be discussed. Examples show mappings between SysML and 001AXES and how the kernel can be used to support SysML.
9.1.2 Overcoming Engineering Challenges of Providing an Effective User Interface to a Large Scale Distributed Synthetic Environment on the US Teragrid: A Systems Engineering Success Story
Authors: Kalawsky Roy S. , Holmes Ian R. 
Published: November 2014

AbstractOver recent years large scale distributed synthetic environment enterprises have been evolving in a diverse range of scientific and engineering fields. These computer modelling and simulation systems are increasing in scale and dimension in order to allow scientists and engineers to explore the attributes and emergent properties of a given system design. Within the field of computational science the grid has been developed to facilitate very large scale collaborative simulation enterprises. The grid is similar to DIS/HLA in that it supports interconnectivity but differs in the sense that it supports intercommunication of large super computing resources. An important factor in the rapid adoption of the grid has been its role in enabling access to significant supercomputing resources not usually available at a single institution. However, the major challenge for the grid has been the lack of an effective and ubiquitous interface to the huge computational resource (which can comprise over 6000 CPUs distributed across the globe) at any time and from any location. This paper describes a unique user interface built on systems engineering principles and practices to solve the problem of delivering real‐time interaction (from lightweight computing devices such as PDAs to high end computing platforms) with simulations delivering high resolution 3D images. The application of our work is likely to have far reaching benefits for many sectors including: aerospace, medical informatics, engineering design, distributed simulation and modelling.
9.3.1 Teaching SysML through a process led approach for systems engineering – lessons for the SysML standard
Authors: Battersby David 
Published: November 2014

AbstractThe systems modelling language, SysML, supports the growing demand for model based systems engineering. This paper describes the design of undergraduate teaching material for SysML based upon an approach which maps the language to systems engineering needs. These needs are high level requirements for a systems engineering language, which are based upon elements of systems engineering lifecycle process standards. This approach is designed to show the capabilities of SysML and UML against the backdrop of a set of simple and logical activities which the students could identify in the context of their studies and industrial experience.The course material was successful in introducing the students to visual modelling through an initial analysis of UML for systems engineering, followed by the introduction of SysML where this adds value to the UML 2 standard. Lecture material and a practical session were used to emphasise this focus on systems problems, including hardware and human aspects. As these issues were addressed the information presented was assessed against the needs identified in order to show the value of SysML to the students.The comparison of the standard with the needs identified resulted in a compliance table that explored how well SysML supports systems engineering; this identifies a number of potential weaknesses of the language which can be seen as opportunities for the next iteration of the standard. The key difficulty identified when trying to apply the SysML standard was the lack of a methodology for the application of the language. This methodology would allow the use of SysML by engineers without previous experience of UML though providing a framework for use and education.
10.5.0 Panel 10.5.0: Cultural, Psychological and Motivational Factors in Risk Management: “Major Issues” or “Let's Not Go There”
Authors: Stein J. , Dolan A. , Gilb T. , Jackson S. , Roedler G. , Siefert W. 
Published: November 2014

AbstractThere is abundant evidence that the biggest obstacles to effective risk management are psychological paradigms rooted in the organization's culture. These paradigms were present in the Challenger, Columbia and Chernobyl catastrophes. Consider the following examples:
When asked to name their top risks, program decision‐makers confidently do so. When asked if the risks are in the database, a typical response is “no, that's not the type of thing we put in our risk management database.”
Some individuals view risks as challenges; others fear their acknowledgement. Many engineers deny or don't communicate risks.
Program managers wanting to present their program in a positive manner to management or the customer often downplay serious risks.In the Time Magazine article “Why We Worry About the Wrong Things – The Psychology of Risk” psychology professor Paul Slovic explains, “there are two systems for analyzing risk: an automatic intuitive system and a more thoughtful analysis. Our perception of risk lives largely in our feelings, and most of the time we're operating on this system.”In evaluating a risk, the brain's most primitive part, the amygdala, acts first. It is not till later that the higher regions of the brain get the signal. This, explains Time author Jeff Kluger, is why “… we wring our hands over the mad cow pathogen that might be (but almost certainly isn't) in our hamburger, and worry far less about the cholesterol contributing to heart disease that kills 700,000 of us annually.”Intelligent Enterprises effectively employ risk management processes and tools to reinforce utilization of the higher regions of the brain over the primitive part.Our panelists are among the world's most highly respected SE and Risk Management practitioners. They will characterize psychological, cultural and motivational inhibitors and describe key practices used by Intelligent Enterprises to accomplish Intelligent Risk Management.Further information about this panel topic, and risk management in general panel, may be found at http://www.incose.org/practice/techactivities/wg/risk/.
11.1.3 ‘Tour d'horizon’ in Requirements Engineering ‐ Areas left for exploration
Authors: Kossmann Mario , Odeh Mohammed , Gillies Andrew , Ingamells Colin 
Published: November 2014

AbstractThe present paper aims to give an overview of the state‐of‐the‐art in Requirements Engineering (RE) based on a wide collection of publications from recent years, and focuses specifically on some advanced areas that need to be further explored in the future. Those areas addressed here are the use of ontologies and UML in RE, the coverage of non‐functional requirements, interfaces to other engineering disciplines and other functions, as well as RE in the context of corporate wide improvement initiatives such as CMMI and Lean Enterprise Value.
Cultural Differences – and how they affect Systems Engineering
Authors: Pandikow Asmus , Ruhe Linda , Herzog Erik , Larsson Ronnie 
Published: November 2014

AbstractSystems Engineering often deals with complex systems being developed and / or supported by multi‐national teams of engineers with different cultural backgrounds. In such environments, cultural differences among the involved individuals often lead to misinterpretations and misunderstanding, leading to suboptimal solutions or even errors in design and failures in systems. In this paper we intend to draw the attention of systems engineers to the area of anthropology, where the analysis of cultural differences delivers a number of interesting insights that may be of great use for improving communication among systems engineers. We provide indices for measuring cultural differences as well as recommendations how cultural analysis can be integrated in the Systems Engineering process.
1.3.3 Valuing System Engineering: The Enterprise QCD Approach
Authors: Clausing Don P. , Campbell Ronald B. 
Published: November 2014

AbstractExtending the definition of quality, cost, and delivery (QCD) from the program or project level to the Business Unit and indeed to the Enterprise level establishes a framework to effectively assess the value of system engineering (SE) in commercial enterprises. Most of the value of SE lies at these higher corporate levels where business and technical metrics intermingle. The Enterprise QCD approach supports a clear definition of system engineering. Three major confounding factors must be dealt with in valuation. In commercial environments, much system engineering is conducted by individuals not carrying the title “system engineer.” Second, attempts to correlate benefits to the quantity of systems engineering will be confounded by the fact that high quality systems engineering reduces the needed quantity. And third, the stage of the enterprise in its life cycle must be taken into account when evaluating the role and value of systems engineering. Effective competitive benchmarking and before/after comparisons can get at the value of SE while minimizing confounding effects. Improvements in QCD should aim at large increases in performance.
2.1.1 Automated Requirements Quality Analysis through Requirements Comparisons
Authors: Scott William , Cook Stephen 
Published: November 2014

AbstractGiven the importance of key requirements documents such as the function and performance specification to the outcome of a systems engineering project, it is important to ensure that a system's requirements are captured and managed well. While contemporary requirements engineering tools are effective at the latter, they offer little assistance in preparing and assessing a set of requirements. This issue has been the subject of an ongoing research project within the Defence and Systems Institute at the University of South Australia that has led to the definition of a context‐free grammar that underpins both a requirements entry wizard and a requirements assessment engine. This engine performs what we call Level 1 assessment in that it ensures that all the necessary components of the imperative statement are present and that the requirement passes elementary tests for reasonableness. This paper describes how through automated comparison of requirements statements much more powerful requirement assessments can be performed. The paper opens by describing a methodology to assess sets of requirements that can be applied at what we call the second and third levels of our three‐tiered requirement assessment approach: namely, consistency checking across the requirements set and context‐based reasoning that seeks to apply a degree of real‐world reasoning based on a comparison of the requirements for the system of interest against industry norms. To facilitate the comparison processes, this paper introduces and describes a finite set of comparison outcomes that can be used to characterise each comparison and become the input for further reasoning. The paper proceeds by showing how the second‐tier assessment can be achieved by comparing each requirement within a requirements set against all of the other requirements thus identifying inconsistent and contradictory requirements. Similarly, the paper shows how the third‐tier assessment can be achieved by comparing the overall meaning of the requirements set against that of benchmark sets. While the paper describes requirements matching concepts that are useful, it also identifies that there are numerous issues that need to be addressed to allow the concept to reach its full potential.
2.1.2 Cyclone Process: Dealing with Vague Requirements
Authors: Bone Mary Alice 
Published: November 2014

AbstractThe main goal of current requirement processes is to define requirements that are complete and unambiguous. Though this is a commendable goal, in the everyday workplace this task is usually unfeasible due to other restraints such as budget, schedule, and/or difficult customers. To handle the balance of creating requirements with integrity and dealing with the aforementioned restraints this paper puts forth a new requirement process, the cyclone process, which allows some requirements to remain vague throughout the requirement process.The cyclone process handles vague requirements by adding a new dimension to the requirements process, which is risk assessment. By associating risk with requirements the user is able to proceed through the requirements process with a known risk level that is acceptable between the stakeholders. An example of the cyclone process is included to demonstrate how the risk assessment dimension is integrated into the requirement process.
3.1.2 Two Empirical Tests of Design Principles for Survivable System Architecture
Authors: Richards Matthew G. , Hastings Daniel E. , Ross Adam M. , Rhodes Donna H. 
Published: November 2014

AbstractSurvivability, the ability of a system to minimize the impact of a finite‐duration disturbance on value delivery, is increasingly recognized beyond military contexts as an enabler for maintaining system performance in the presence of dynamic disturbance environments. This paper attempts to validate a preliminary set of twelve general design principles for survivability through two empirical tests. Survivability features of the A‐10A “Warthog” combat aircraft and UH‐60A Blackhawk helicopter, two systems designed for reduced vulnerability, are inductively traced to an existing set of principles. Seven unique insights are derived from the analysis, and the design principles are revised to reflect the lessons learned. A new set of seventeen design principles are formalized: six aimed at reducing susceptibility and eleven aimed at reducing vulnerability. The paper concludes with propositions for future work for developing a theory of survivable system architecture and a discussion of the importance of empiricism in systems engineering.
5.2.2 On the Use of Concepts and Principles for Improving Systems Engineering Practice
Authors: Lawson Harold , Martin James N 
Published: November 2014

AbstractMany complex system projects fail due to the fact that the conceivers and developers of the system have not clearly established and communicated the central concepts and principles related to the system product or system service being provided. Establishment and communication is not a guarantee. It is vital that the concepts and principles are followed consistently in all life cycle related decision‐making in order to achieve a unifying effect. System architects have a primary responsibility for concepts and principles of the system solution. In this paper, the nature of concepts and principles are explored and related. Some concrete examples of system successes that resulted from the proper treatment of concepts and principles are described.
6.1.1 When and What to Standardize; An Architecture Perspective
Authors: Muller Gerrit 
Published: November 2014

AbstractMany products today are developed for highly dynamic markets while the products and functions get more and more integrated. The product and service realization is based on fast changing technologies that come together in complex value chains. The challenge for modern companies in innovative domains is to survive in this dynamic world. In this paper we explore what the appropriate timing of product standardization is.
6.3.2 Emergence: Still a Challenge for the Systematic
Authors: McConnell George R. 
Published: November 2014

AbstractAt the International Symposium of 2000 in Minneapolis I presented a paper that suggested that in order to deal with emergent properties of increasingly complex systems, the typical systems engineer needed to go beyond the systematic and become more systemic in approach. This paper revisits the issues and suggests that, for many, progress along this road is rather slow. At the same time it highlights that for some within INCOSE there have been very significant advances and this provides promise for the future. The fundamental purpose of the paper is not to describe a systems approach, but to try to highlight some of the reasons why a systems approach is needed and the ways in which such an approach can be beneficial to the systems engineering community.
7.3.1 Going Beyond Traditional Systems Engineering to Address 21st Century Challenges
Authors: Harwell Richard (Rich) M. , Martin James N. 
Published: November 2014

AbstractIn spite of several decades of increasingly sophisticated systems engineering processes, methods, and tools, industry continues to be plagued with systems engineering failures. Enterprise leaders are focused on delivering solutions that meet customer needs and have become weary of systems engineering that does not consistently deliver results. In view of the increased complexity and complicatedness of systems development in today's marketplace, systems engineering is at a crossroads necessitating a transition to a more expansive and integrated mindset. A mindset comfortable with changing variables, eternally evolving requirements and capability needs, lack of single‐oversight control, and simultaneous interoperability among many networked and interdependent systems.