bluuebunny/crossref_metadata_2025 huggingface dataset:
5.2.2 An Innovative Partnership in Systems Engineering for Schools
Authors: Brown Samantha
Published: November 2014

Must the teaching of Systems Engineering be restricted to a postgraduate level? Evidence from Loughborough University's undergraduate course has taught us that this is not the case. So why stop there? Can you teach systems engineering in schools – to children from 5 to 18 years? Focussing mainly on the secondary level (11–18 years), this paper look at some of the issues, some of the UK‐wide activities and at BAE Systems's own programme of working with schools to bring the basics of systems engineering to the workforce of the future.
5.4.2 Architecting a Command and Control (C2) System
Authors: Cropley David H
Published: November 2014

The C4ISR Architecture Framework (C4ISRAF) mandates architecture products that are needed to describe typical defense information environments and hence entities such as a hypothetical future Command and Control (C2) Architecture. However, as is commonly understood, the C4ISRAF does not describe a methodology for creating the architecture products. This paper seeks to redress this deficiency by identifying a suitable methodology to create and evolve a C2 Architecture that maps to the C4ISRAF and its products.

The strong influence of human activity in the problem domain necessitates both a functionalist and an interpretive approach to system design. This has been used to define an approach based on a multi‐methodology. The paper describes the steps taken to identify appropriate candidates for the multi‐methodology and concludes that there are two leading candidate hybrid multi‐methodologies: one that could be described as a soft mantle with a hard systems core and one that follows a more traditional hard systems paradigm.
5.5.3 Systems Engineering Management
Authors: Smith Alan , Cowper Douglas , Emes Michael
Published: November 2014

Organizations may have sophisticated and detailed systems engineering process models yet struggle to implement them effectively in the face of conflicting internal priorities, legacy practices and slowly changing cultures.

Taking experiences from a number of sources this paper identifies a range of current systems engineering issues and suggests that it is the interface of systems engineering with other business activities that is a cause of many implementation problems. By taking a systems view of the business (a systems‐make‐systems approach), one can use systems engineering principles to address these problems. A broader remit for Systems Engineering Management is recommended.
6.3.1 Decision Oriented Systems Engineering (DOSE)1 – A Structured, Systematic Approach to Function Allocation
Authors: Buckley Michael E. , Stammnitz Volker
Published: November 2014

Perhaps the most important reason Systems Engineering exists as a discipline lies in the observation that complex systems cannot be treated merely as an assemblage of so many building blocks. Systems Engineering employs techniques and practices that attempt to consider the whole throughout the design process. Systems Engineering offers quite an assortment of processes, and tools devices to capture, describe, derive, and otherwise characterize various aspects of systems under design or analysis. There are many evolving Systems Engineering processes and practices, including processes in which the object‐oriented paradigm dominates. Unfortunately, the set of available processes, models, and tools remains weakest where they are needed the most: where decision tradeoffs are most negotiable, where “requirements” are not yet firmly established, where the use of legacy systems can have the greatest impact, and where the (projected) life cycle impacts of such decisions are greatest.

This paper describes a new system development practice named Decision Oriented Systems Engineering (DOSE). If consistently and diligently applied in tandem with other more conventional practices, DOSE provides a solid Systems Engineering “hook” to the application of Human Systems Integration principles and offers considerable promise in simplifying the design of even the most complex systems involving teams working with mixes of new, evolving, and legacy systems.
6.4.3 Ontology‐Enabled Validation of System Structure
Authors: Mayank Vimal , Kositsyna Natalya , Austin Mark
Published: November 2014

This paper describes a vision for team‐based synthesis of engineering systems, enhanced by technologies for ontology‐based computing, cast in a Semantic Web framework. As a first step, in this paper we describe an ontology‐enabled procedure for validation of system structure. We apply the procedure to the validation of connectivity relationships in a home theatre system.
7.2.2 On Methodology and System Framework for Knowledge Management in Allied System Engineering
Authors: Chen Yuh‐Min , Chen Yuh‐Jen , Kuo Jen‐Yao , Wang Chin‐Bin , Ho ChengTer
Published: November 2014

This paper presents a systematic approach to development of a methodology and a system framework for knowledge management to support allied system engineering. The approach of this research has laid‐down four phases: allied system engineering characterization, knowledge identification, analysis and modeling, KM strategy and methodology development, and system development. The methodology consists of a rationale behind the methodology, a life cycle model for knowledge management, and a distributed knowledge management framework. Based on the proposed methodology, a knowledge management system framework is developed using component technology. Besides providing functions for knowledge management and sharing, the system possesses properties to meet the hierarchical, distributed, flexible and dynamic‐configurable characteristics of allied system engineering.
8.1.2 Requirements Risk Assessment ‐ Integrating QFD and Risk Assessment
Authors: Kenley C. Robert
Published: November 2014

A modified Quality Function Deployment (QFD) analysis [Hauser and Clausing, 1988] was applied to evaluate development risk for user requirements across multiple system architectures. Applying QFD to the risk assessments required tailoring the approach to capture and quantify subjective risk judgments and to reconcile them with raw risk assessment data from specific designs. Initial evaluation of development risk from each architecture showed that overall risk reduction activities were acceptable as planned. Risk assessments were also conducted on updated designs using the QFD assessment to confirm validity of the final risk reduction plans.

This method extends previous work by Clausing and Cohen [1999], which described the use of QFD to capture requirements relationships, and U.S. Air Force guidance [AFMC, 1977], which describes methods for risk evaluation. It allows capture of the strength of relationship between user requirements and development risk early in a program by use of conceptual system architectures. This permits early evaluation of the trade offs between user requirements and risk mitigation efforts prior to committing a program to a functional baseline is established for user requirements and the design solution.
8.5.1 Design Reviews: A Customer's Confessions
Authors: Armstrong James R.
Published: November 2014

Even when guidance was available on design reviews in MIL‐STD‐1521, much was left to the reader. Since the cancellation of the standard, specifics on design reviews have been limited. This paper provides several lessons learned and best practices that can be applied at any point in the program. As the title indicates, most of the lessons were learned from the viewpoint of the customer. They are augmented by experiences as the one being reviewed.
9.6.2 Standard Approach to Trade Studies
Authors: Felix Arthur
Published: November 2014

This paper describes the steps for performing and documenting a Trade Study (Trade‐Off Study), developing products for the Decision Making Authority, and guidelines in tailoring the study to meet the needs of the program. The purpose herein is to transform a subjective decision making process into a more objective decision making process. Within this process, standard terms and definitions are used, roles and responsibilities of the participants and decision makers are documented, and a suggested flow is illustrated. The significant developments introduced in this paper are identified in the paper where they appear.

Defining a Framework and Structure for seven often used Trade Study types

Removing Cost and Risk from the tradable Criteria list

Defining a Baseline/Optimum solution(s) to anchor Criteria Utility Curves.

Presenting Uncertainty (Lack of Confidence) considerations in criteria evaluation

Presenting the Cost‐Benefit Chart for use in final (Gate 3) evaluation

Presenting the Risk‐Benefit Chart for use in final (Gate 3) evaluation

This Trade Study process meets Level 3 Decision Analysis and Resolution requirements of the Capability Maturity Model Integration (CMMI®)1.
9.6.3 Systems Engineering in a COTS World
Authors: Sorensen Richard L.
Published: November 2014

Using traditional systems engineering practices to accommodate commercial off‐the‐shelf (COTS) components requires focusing on those steps within the design process that allow identification of the constraints imposed by COTS items early in the design process. Two traditional systems engineering processes are reviewed for their insights into the major tasks, the goals, and the dependencies. With this understanding, the focus moves to discussion of a proposed approach for applying systems engineering practices using a process that retains a requirements‐driven methodology while simultaneously adapting to the boundaries imposed by COTS items, thereby converging on a solution.
1.4.1 Governing Systems Engineering as an Enterprise Competence: A Benchmark Study with Pertinence to the US Department of Defense
Authors: Mullins William P , Wilson Mark A.
Published: November 2014

DoD is reinvigorating SE capabilities so that “system of systems” structures can now be engineered. A benchmarking review reports approaches to the achievement of SE competence in a Research, Development and Engineering Center. For SE competence management most SE organizations contacted reflect tailoring to local and historical conditions more than the effects of integrated development. Current SE governance practices are analyzed here on a continuum between composite models termed the “Strong Form Model” and the “Methods Model.” Systems‐engineered Competence Development Plans appear to be in order to address growing dynamic complexity inherent in the “system of systems” environment.
1.4.2 Performance‐Based Earned Value®
Authors: Solomon Paul J.
Published: November 2014

Performance‐Based Earned Value (PBEV) is an enhancement to the Earned Value Management Systems (EVMS) industry standard. PBEV supplements EVMS with principles and guidelines for true integration of project cost, schedule, and technical performance. It is derived from standards and capability and maturity models for systems engineering and project management.

PBEV overcomes several shortcomings of EVMS. EVMS specifically excludes the measurement of product quality and is silent on risk management. In contrast, PBEV bases earned value on product quality requirements, technical performance, and technical maturity. It also incorporates the outcomes of risk management into revised plans and the Estimate at Completion (EAC).

PBEV supports agile systems development because it is scalable to match the project risk and is responsive to changing product requirements. PBEV evolved from lessons learned in both the U.S. defense industry and the commercial software industry in India. It is also cost‐effective. The principles and guidelines of PBEV provide a framework for process improvement.
5.2.1 Architecting Ontological Systems
Authors: Terrill Alexander R. , Dagli Cihan
Published: November 2014

Recent emerging technologies such as internetworking and the World Wide Web have significantly expanded the types, availability, and the volume of data accessible to information management systems. In this new world, there is less emphasis on isolated devices and greater emphasis on information exchange. This shift is making knowledge management and application integration key issues in computer technology. In order to stay competitive, a company is held hostage by how it understands, maintains and accesses its data. Data comes from many sources, containing a variety of types and formats. One possible way to tackle this complex data problem is to implement an ontology, a unifying framework that facilitates communication through a shared understanding and vocabulary of a system. It enables communication between systems that are independent of system technologies, information architectures and application domain. This paper describes the importance of ontologies in knowledge management and provides the basis on how to architect such an ontological system.
5.2.3 Obsolescence Management for System‐of‐System Hierarchies – A Technology‐based Approach
Authors: Herald Thomas E.
Published: November 2014

Many systems face a similar obsolescence issue, which is that the desired system deployment life cycle is much longer than the life cycle of the constituent parts (hardware and software) that make up the physical architecture. Thus, the system baseline must evolve over its operational life cycle just to remain functionally viable. This problem is compounded as the size of the system grows toward network‐centric system‐of‐systems and as the use of commercial technologies and products increases. Thus, the challenge is to perform technology assessments that facilitate the forward planning of technology evolution on the system of interest. A corollary challenge is to perform this planning while simultaneously optimizing the life cycle affordability for the customer.

This paper provides a methodology for taking current technology information and transforming it into a system evolution plan (the term system being used in the most general sense to encompass sub‐assemblies through system‐of‐systems) using affordability as the optimizing variable for technology change incorporation.
6.4.1 Adapting SEER Cost Estimating Tools to Evolutionary Acquisition
Authors: Stump Evin J. , Ferens Daniel V.
Published: November 2014

In recent years, the U.S. Department of Defense (DoD) has emphasized improvements in acquisition processes. We have found that most of these called for little or no change in our SEER cost models, but a current initiative does seem to call for significant changes. This initiative is called evolutionary acquisition.

Evolutionary acquisition shares many features with conventional DoD acquisition methods of the late 20th century, but does introduce unique features that need to be accounted for in an up‐to‐date cost modeling system.

This paper discusses some of the major changes in DoD acquisition practices that have recently been formalized in the DoD 5000 series documents, and how we are responding to them by experimenting with design changes in the SEER tools.
7.3.2 Enhanced Interoperability for Systems Engineering Data by a Transformation Report
Authors: Eckert Roland , Mansel Wolfgang , Specht
Published: November 2014

In industry, product data exchange via STEP ISO 10303, is an established method. In case of heterogeneous CASE Tools, e.g. in Systems Engineering applications, it is very often difficult to guarantee a defined level of data quality. This paper analyses the state of data transformation and exchange as well as offering a solution for schema mapping and integration by means of a transformation report which can be used in systems engineering. The report records individual transformation steps, during the exchange, between two different tools. It supports the understanding of the data exchange process and helps to rectify incomplete or incorrect transformed data. The proposed framework was validated using gateways between the Statemate and Teamwork CASE tools.
8.3.2 System Engineering Issues in the Transformation to Service Oriented Architecture
Authors: Halley Marc R.
Published: November 2014

The major problem facing enterprises today is the system engineering of large scale multi‐enterprise “systems of systems“. These initiatives integrate dozens of legacy applications into a “system of pre‐existing systems” that solves a new unexpected problem. A new paradigm called the Service Oriented Architecture (SOA) has been developed in hopes of managing the complexity and adaptability needed. By creating a macro system from loosely coupled modular components, SOA is a solution for the major roadblocks of large‐scale enterprise change: inflexible technology, cross‐organization initiatives, outdated strategic planning, and organizational inertia.

However, transitioning to an SOA is a difficult task. Since these projects involve little new software development, the system engineering organization takes the central role. These complex transitions involve uncoupling pre‐existing systems, creating modular components, and loosely re‐coupling these components via common standards. Current widely used enterprise architecture models deal well with static state architectures, but are very limited in the description of transitions between architectures.

This paper presents an overview of the issues facing systems engineers when transforming traditional enterprise architecture to a Service Oriented Architecture. The issues are collected together in a strategic issues framework which can be used to guide transformation planning and execution. The framework encompasses the seven transformation issues: a suitable business model, IT governance, enterprise SOA architecture, portfolio investment, risk management, change management, and technology management.
9.2.1 “….is he in heaven or is he in hell that illusive Systems Integrator?” – Who's Looking After Your Systems Integration?
Authors: Cowper Douglas , Emes Michael , Smith Alan
Published: November 2014

Changes in supply chains, for example, due to increased competition, lower margins, and changes in customer enterprises, can cause enterprises to want to move up the ‘food chain’ and take on the role of systems integrator. This role comes with its own set of risks and implications for both customers and suppliers. This paper explores these issues. For example, being one step removed from component suppliers, what must an enterprise consider when deciding whether to move into the role of systems integrator or to pass this role along its supply chain? This will include identifying where the appropriate skills are within its organisations and establishing what its credibility would be in performing this new role.
9.3.2 Enhancing Commercial Systems Engineering with Design For Six Sigma
Authors: Creveling C.M.
Published: November 2014

The advent of Design For Six Sigma and its integration with a commercial Systems Engineering process has systematically improved rigor in risk management during product commercialization. Many companies suffer from a lack of discipline and rigor as they develop and integrate systems within their commercial phase‐gate process. DFSS is well known for helping “put the science and engineering back into product design” (Dr. Joseph Sullivan, VP Quality, Carrier Corp.). It is also recognized as “a shift from a deterministic to a probabilistic approach to product design” (DFSS: 15 Lessons Learned; Treichler, Charmichael, Kusmanoff, Lewis & Berthiez; Quality Progress, January 2002).

Organizations that focus on systems architecting, engineering, integration and assessment applied within their commercialization process, are recognized as having a more disciplined and comprehensive approach to improve cycle time, cost and quality. This paper defines DFSS and presents the integration of DFSS and Systems Engineering. The goal is to demonstrate that a DFSS enabled Systems Engineering organization can measurably improve rigor and discipline in delivering critical parameter data for risk management and decision making during product commercialization.
10.2.2 Proposition of a methodology and tools for the management of innovative design projects
Authors: Baron Claude , Rochet Samuel , Gutierrez Citlalih
Published: November 2014

This paper deals about the development of new methods and tools to support the management of projects dealing with the design of innovative systems. Currently, there are only few methods and virtually no tool making possible to ensure in a formal way of the design choices coherence with those of project management. This involves risks of incoherencies which can have technical and economical consequences (low quality, wrong deadlines, higher costs…). It is to fill this gap that we currently develop tools, in collaboration with academics and industrials partners, based on a specific representation integrating both technological and organizational data, which will help the designers and the project leader in their respective tasks. In this paper, we present a methodology which, thanks to the interaction of various tools, will lead to establish this project representation and assist the actors of the project in their choices of design and management and so reduces project costs, delays and risks.
11.4.1 From Waterfall to Evolutionary Development (Evo): How we rapidly created faster, more user‐friendly, and more productive software products for a competitive multi‐national market
Authors: Johansen Trond , Gilb Tom
Published: November 2014

Evolutionary development (Evo) focuses on early delivery of high value to stakeholders, and on obtaining and utilizing feedback from stakeholders. This paper describes from a project manager's viewpoint, the positive experiences that one organization rapidly achieved on switching from using the Waterfall method to Evo. Major benefit came from paying greater attention to the quality requirements as opposed to the previous practice of concentrating solely on the required functionality.
12.1 Design Evaluation: Estimating Multiple Critical Performance and Cost Impacts of Designs
Authors: Gilb Tom
Published: November 2014

How should we evaluate someone's design suggestion? Is gut feel and experience enough for most cases? Is anything more substantial and systematic possible? This paper outlines a process for design evaluation, which assesses the impacts of designs towards meeting quantified requirements. The design evaluation process is viewed as consisting of a series of design filters.
12.3 Project Failure Prevention: 10 Principles for Project Control
Authors: Gilb Tom
Published: November 2014

It is now well‐known and well‐documented that far too many projects fail totally or partially, both in engineering generally (Morris 1998) and software engineering (Neill and Laplante 2003). I think everybody has some opinions about this. I do too, and in this paper I offer some of my opinions, and I hope to lend some originality to the discussion. As an international consultant for decades, involved in a wide range of projects, and involved in saving many ‘almost failed’ projects, my basic premises in this paper are as follows:

We specify our requirements unclearly;

We do not focus enough on ensuring that the system design meets the requirements.
4.4.3 Extending Platforming to the Sequential Development of System Families
Authors: Boas Ryan C. , Crawley Edward F.
Published: November 2014

Creating system designs that efficiently satisfy an evolving set of needs is critical for improving program lifecycle properties such as cost, development time, and risk; properties that are often in conflict with near‐term system requirements. This paper proposes that system evolution can be viewed as a family of sequentially developed systems and that existing work in the platforming domain serves as a useful foundation. An overview of related work is provided with emphasis on the platforming literature in an attempt to strengthen the connection between the systems engineering and product platforming communities. A classification scheme is proposed for multi‐system design strategies. Preliminary cost model work is presented, with the ultimate goal being a model that provides program managers with a clear understanding of the economic trades associated with sequential platform development and alternative strategies.
7.2.1 The FAR Approach – Functional Analysis/Allocation and Requirements Flowdown Using Use Case Realizations
Authors: Eriksson Magnus , Borg Kjell , Börstler Jürgen
Published: November 2014

This paper describes a use case driven approach for functional analysis/allocation and requirements flowdown. The approach utilizes use cases and use case realizations for functional architecture modeling, which in turn form the basis for design synthesis and requirements flowdown. We refer to this approach as the FAR (FunctionalArchitecture by use caseRealizations) approach. The FAR approach is currently applied in several large‐scale defense projects within BAE Systems Hägglunds AB and the experience so far is quite positive. The approach is illustrated throughout the paper using the well known Automatic Teller Machine (ATM) example.
11.3.3 Integration Challenges of Complex Systems
Authors: Haskins Bill , Striegel Jack
Published: November 2014

Integration of complex systems normally requires many different components, subsystems and systems. Commonly referred to as system of systems (SoS), these many different systems are too complex for any one company to develop. Current examples are the international space station and network centric operation programs. Since complex systems require many different companies, challenges arise in effective communications and understanding of requirements, interfaces, validation and verification of integrated systems. This paper addresses the foundation of integration, which is a clear understanding of validation and verification activities at all levels of development, including the key interfaces between systems, subsystems and components. Equally as important is the ability to work key issues during the development process. Attention to detail in both of these aspects is the key to having a successful integration of complex systems.
1.1.0 Panel 1.1.0: Can We Have Systems Resilient to Natural Disaster Events and/or to Terrorist Attacks? A Debate on the Issues
Authors: Mackey W. , Carl J. , Jackson S. , Long J. , Nolte J. , Sutton S. , Tulodieski C.
Published: November 2014

During the past few years, natural disasters including the major earthquakes in Pakistan, the Tsunami floods of Indonesia, and the hurricanes and destruction in New Orleans, LA and the Gulf Coast region of the United States have caused major loss of life, injury and significant loss of property.

During the same period, insurgent attacks in Iraq, subway bombings in London, fire attacks on the city of Paris, and continued threats of terrorists throughout the world have placed life at risk.

Terrorism is the systematic use of violence and force as a means of coercion through fear and intimidation. As we have seen since World War II and experienced first hand since the terrorist attacks of September 11, 2001, the calculated murder of political personalities has given way to the random killing of innocent people and civilian populations. Natural disasters are perhaps even more threatening. Are the systems under development and already built resilient these kinds of events? How can the discipline of systems engineering assist in preparing for, responding to, recovering from and mitigate against the risks of natural disasters and terrorist events.

Since September 11, 2001, INCOSE through its Anti‐Terrorism International Working Group (ATIWG) has focused the principles, techniques, and practices of systems engineering on how to reduce and eradicate international terrorism. We are taking this opportunity to expand emergency preparedness efforts to natural disasters as well.

Through the ATIWG sponsoring of panels at previous INCOSE symposia (2002‐2006), writing papers for publication (2003), a tutorial (2004), and working group activities, the systems engineering community has discussed the application of collaborative engineering environments, simulation and modeling, religion, system solutions to defend against terrorism, psychology, and root causes of terrorism to address the vulnerabilities of systems as well as the attack responses to threats. This panel continues the INCOSE application of systems engineering to these international problems by discussing the recovery and resiliency of society and the systems it builds to natural disaster events and terrorist attacks.
1.6.2 Practical Process Implementation: Using SE Methods to Develop SE Processes
Authors: Nolte Jerome T. , Newbern David W. , Vanghel Pamela S.
Published: November 2014

At our company, process development and process implementation is taking a new direction. We have completed and revised a robust set of corporate core processes, based on the Capability Maturity Model Integrated (CMMI) that address our primary business areas of systems engineering and system development. However, as our business evolves, we are finding new areas of related activities that are not effectively represented by our current corporate process descriptions. In this paper we present an approach for using SE methods to prepare processes for repeated reuse, in specialized areas. Our preliminary results have already been used to support marketing and business development, showing other current customers our capability and the potential to assist them in a new way. The preliminary results have also been used effectively by staff and project managers to improve management processes on existing programs.
2.4.1 Decision Analysis for Design Trades for A Combined Scientific‐Technological Mission Orbit on Venμs Micro Satellite
Authors: Herscovitz Jacob , Barnett Danna Linn
Published: November 2014

The scope of the VENμS Technological Mission is to evaluate and qualify the IHET (Israeli Hall Effect Thruster) performance in space and to use the IHET for mission enhancement. IHET will be used to demonstrate space missions that require high V and are hardly achievable using traditional chemical propulsion in microsatellties.

During the satellite's third mission phase (VM3) the VENμS satellite will fly in a high drag environment. The IHET will be used for autonomous orbit maintenance to enable continuation of the scientific mission, which is vegetation monitoring.

This paper describes the selection of VM3 orbit. Different orbit candidate alternatives were compared according to pre‐determined criteria and weighted accordingly, using the NGT technique. After all candidate alternatives were analyzed, they were compared using a Decision Analysis for Design Trades method. Based on the analysis, the final orbit was chosen.
3.1.3 Exploring Intelligent Entreprise System Limitations
Authors: Palmer Kent D.
Published: November 2014

In this paper we will consider the implications of Meta‐systems Engineering for Intelligent Enterprises. We may think of this as the dark side of intelligent enterprise systems. Our essay is a search for light at the end of this tunnel by employing the theory of Special Systems and the Emergent Meta‐system. This work brings together advanced theories in order to redefine the nature of the Intelligent Enterprise and Enterprise in general.
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

What 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

Several 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

This 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

This 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

This 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

OMG 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

Over 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

The 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

There 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

The 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

Systems 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

Extending 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.