bluuebunny/crossref_metadata_2025 huggingface dataset:
Cost Models with Explicit Uncertainties for Electronic Architecture Trade‐off and Risk Analysis
Authors: Axelsson Jakob
Published: November 2014

This paper discusses how the early phases of developing embedded electronic systems can be improved by enhanced modelling of cost and performance that includes explicit handling of uncertainties. The approach is to add cost information to existing UML models, capture uncertainties using probability distributions, and use Monte Carlo simulation to analyze the risk of not reaching the cost targets. It is demonstrated how the information obtained can be used when evaluating different architecture alternatives, while including both development and product cost as well as risk in the trade‐off.
Process in Enterprise Systems Engineering
Authors: DeRosa Joseph K. , McCaughin Keith
Published: November 2014

This paper addresses the importance of process in enterprise systems engineering. It relates process to the balance between complexity and order in a complex adaptive system, and it extends the rationale for process from efficiency to both efficiency and effectiveness in enterprise adaptation. It develops several enterprise principles based on the works of Ashby, Ackoff, Axelrod and Cohen, Barabasi, Gharajedaghi, and others. It makes no attempt to be mathematical or rigorous, but rather postulates several heuristics. It discusses the deep structure of engineering process.
Capturing Total System of Systems Costs Using SEER‐H with Total System Vision (TSV) and SEER‐SEM: An Example Application
Authors: Falque Joseph P.
Published: November 2014

This paper1 discusses how a parametric life cycle cost model (LCC), SEER‐H with Total System Vision (TSV) and SEER‐SEM software estimation model, are used to facilitate the cost impact assessment of Systems Engineering labor and materials for a Major System of Systems project containing both hardware and software components. The main purpose is to introduce the underlying methodology and demonstrate the flexibility of the cost model for developing System Level Costs at the System of Systems Level. Readers are introduced to the model, its premise, and how engineers use it to obtain system level engineering labor and material estimates on a Constellation of 18 earth orbiting Optical Satellites. The system includes the launch vehicles and services, mission control and a world wide tracking antenna sites as well as operational and support costs.
Universal Electronic Health Record: Just what the doctor ordered
Authors: Shahi Rajiv
Published: November 2014

The time has come for health informatics to unify; this call for integration will help in better patient care across various systems spread globally. This feat requires standardization of health related information. The implementation of Electronic Health Record (EHR) is such standard which will facilitate collaboration of disparate systems. This emerging standard proposes to digitally accumulate patient's entire healthcare information and allow real time effortless exchange between different care providing sites or individuals. This will result in non redundant patient data accessibility (Any time, any where, any device) resulting in improved efficiency and quality of patient care. The realization of this effort requires different standards organizations like Health Level 7 (HL7), Clinical Data Interchange Standards Consortium (CDISC) and European Committee for Standardization (CEN) to collaborate and produce standards that are interoperable between different organizations. This collaborated effort will result as building blocks for foundation of neural health care network. This state of the art health informatics grid has to overcome barriers in technical implementation, health care domain, globalization, and education and training before realisation of the dream to have an integrated EHR.
1.3.1 Modeling of hardware software performance of high‐tech systems
Authors: van den Bosch Peter , Muller Gerrit , Verhoef Marcel , Florescu Oana
Published: November 2014

The performance of the control system is an important aspect of a machine. It would be a waste if a high‐tech machine has been build such that it can physically achieve a high throughput, for example printed sheets of paper, but is limited because the software controlling it cannot keep up. Unfortunately, with current techniques it is hard to “predict” beforehand what the performance of the software will be when it finally runs in the real system on the real processor(s). There are two (extreme) ways to deal with it:

Over‐dimension the hardware platform to make sure the software will run.

Implement the software, then run and evaluate its performance on the target hardware platform. Then use this information in the next design cycle.

The disadvantages of both approaches are clear. In the first situation the cost price of the entire system will surely be higher than necessary. In the second case, the design time is increased dramatically because more design cycles are needed. Therefore, it is important to strive to a development method that leads to fast design cycles for software performance, while having an accurate enough prediction. In this paper we will discuss a pragmatic modeling approach to design for performance in the domain of software intensive systems.
1.3.3 Hybrid System Dynamic, Petri Net, and Agent‐Based Modeling of the Air and Space Operations Center
Authors: Mathieu Jennifer , James John , Mahoney Paula , Boiney Lindsley , Hubbard Richard , White Brian
Published: November 2014

In an earlier paper, an existing Air and Space Operations Center (AOC) process model (i.e., Petri net) and new global and mission models for the environment in which the AOC operates (i.e., System Dynamics) were linked (federated). The focus of this paper is the development of an operator‐environment model (i.e., Agent‐Based Model). An existing systems framework for attention allocation of operators within the AOC has been implemented that supports multiple modeling paradigms. The results for linking the Petri net and System Dynamics models are summarized, and new results for the Agent‐Based Model are presented based on a pilot‐down scenario. It has been observed that many AOC operators can become distracted by a pilot‐down critical event, even if the operator is not able to directly assist in the rescue. Furthermore, this distraction has been hypothesized to have a detrimental effect on the activities the non‐involved operators are currently handling.
1.4.1 An Integrated Approach to Developing Systems Professionals
Authors: Davidz Heidi L. , Maier Mark W.
Published: November 2014

As the level of integration and the complexity of engineering systems increase, there is an increasing need to develop systems capabilities in engineers. Often, the demand for increased systems capabilities is automatically translated into a need to develop the systems capabilities of individuals. However, the systems capabilities of groups and organizations are what really matter for complex engineering systems, and individual capabilities do not automatically translate into group and organizational capabilities. This paper describes an integrated approach to developing systems professionals. To guide practitioners in utilizing relevant theoretical issues and research results, a five‐step plan to developing systems professionals is given. First, there is a description of how to frame the relevant problem space. Next, desired roles and competencies are linked to this problem spectrum. After describing how to develop an appropriate multi‐level strategy, the paper discusses how individual systems skills combine. Potential assessments for the development approach are shown. Since group and organizational issues can trump efforts to develop the systems capabilities of individuals, it is important to frame the relevant problem space, match the desired capabilities to that space, and create a multi‐level integrated strategy to develop those capabilities in individuals, groups, and organizations.
1.4.4 Measurably Improving Your Systems Engineering Requirements
Authors: Olson Timothy G.
Published: November 2014

Requirements continue to be a major problem area for most organizations. According to industry reports, the leading causes of quality, cost, and schedule problems are lack of understanding of the customer's needs, incomplete requirement specifications, and managing changing requirements. So what can an organization focus on now to improve their systems engineering requirements? This paper will describe some practical strategies that organizations can use to measurably improve their requirements as well as their requirements process.

The objectives of this paper are to:

Present some requirements problems from industry.

Present a useful classification of requirements problems from the literature.

Provide specific strategies to address the requirements problems from the literature.

Describe some practical strategies that organizations can use to measurably improve their requirements.

Provide some requirements lessons learned and provide some industry references.
1.5.1 A Decision Support System to Schedule Design Activities in Aircraft Industry
Authors: LIZARRALDE Iban , ESQUIROL Patrick , RIVIERE Arnaud
Published: November 2014

This paper highlights the relationship between Project Management and Systems Engineering through a framework proposal that links dependencies management and project scheduling. It investigates the problems of project scheduling at the design stage of the development of a civil aircraft, mainly characterised by a dynamic environment and uncertainties concerning the duration of activities.

This framework is supported by methods dedicated to the management of schedules at tactical levels with fully elastic tasks that takes into account dependencies between design teams as new constraints.

For end users, this framework can be considered as a Decision Support System (DSS). The DSS is a tool to check if all scheduling constraints are satisfied or to solve over‐constrained problems through interactions with end‐users. This approach, illustrated with AIRBUS use cases, is flexible enough to be implemented within the aerospace industry, by facilitating cooperation between design teams and by providing the possibility to carry out schedules simulations.
1.5.4 Time‐Expanded Decision Networks: A Framework for Designing Evolvable Complex Systems
Authors: de Weck Olivier , Silver Matthew
Published: November 2014

This paper describes the concept of Time‐Expanded Decision Networks (TDN), a new methodology to design and analyze flexibility in large‐scale complex systems. This includes a preliminary application of the methodology to the design of Heavy Lift Launch Vehicles for NASA's space exploration initiative. Synthesizing concepts from Decision Theory, Real Options Analysis, Network Optimization, and Scenario Planning, TDN provides a holistic framework to quantify the value of system flexibility, analyze development and operational paths, and identify designs which can allow managers and systems engineers to react more easily to exogenous uncertainty. TDN consists of five principle steps, which can be implemented as a software tool: 1. Design a set of potential system configurations 2. Quantify switching costs to create a “static network” that captures the difficulty of switching among these configurations 3. Create a time‐expanded decision network by expanding the static network in time, including chance and decision nodes 4. Evaluate minimum cost paths through the network under plausible operating scenarios 5. Modify the set of initial design configurations to exploit high‐leverage switches and repeat the process to convergence. Results can inform decisions about how and where to embed flexibility in order to enable system evolution along various development and operational paths.
1.6.3 Managing Dynamic New Product Development Processes
Authors: Karniel Arie , Reich Yoram
Published: November 2014

New Product Development (NPD) processes are considered most challenging, involving major risks due to unknown or unforeseen obstacles, in terms of technology and business risks. The actual process activities which depend on the evolving product knowledge could be determined only during process execution. Thus, process planning is inherently dynamic and requires adaptation to product knowledge changes as well as other changes. Current Workflow tools can support ad‐hoc changes, but do not support the planning of process dynamics and the execution of such dynamic process changes as they unfold.

The current article presents a novel system framework for managing dynamic process planning changes resulting from changes in customer requirements, product structure, product parametric dependencies and constraints, as well as ad‐hoc changes. The proposed framework comprises: process planning, incorporating the Design Structure Matrix (DSM) method; business rules for interprating the DSM‐based plan to process plan; dynamic process plan changes; and implementation of changes into Run Time process simulation.
2.1.2 Milestone Driven Systems Engineering Methods
Authors: Wells Brian H.
Published: November 2014

Methods are presented that have been used successfully on large programs including a $3B development program that reached the System Requirements Review (SRR), Preliminary Design Review (PDR) and Critical Design Review (CDR) on or ahead of schedule. These methods link the non‐systems engineering activities into the system engineering processes and provides an effective means of communication and coordination between the systems engineers and design engineers to reduce the risk of achieving each milestone successfully. These methods augment the established systems engineering processes for technical reviews and use the milestone events as the impetus to drive the team and the program forward.
2.2.2 Using Stakeholder Analysis to Define the Problem in Systems Engineering
Authors: Trainor Timothy E. , Parnell Gregory S.
Published: November 2014

The first step in most system life cycles is the problem definition. Stakeholder analysis is a key technique to insure the problem has been fully and completely described before we attempt to obtain a solution to the problem. We identify and describe the three most common techniques for stakeholder analysis: interviews, focus groups, and surveys. We compare the three techniques using five criteria: time commitment of participants, ideal stakeholder group, preparation, execution, and analysis. We identify best practices to make stakeholder analysis both effective and efficient. This paper will aid the new practitioner and student of systems engineering as they organize and execute an effective stakeholder analysis, which is critical to the success of any systems engineering project.
2.3.2 Model‐based techniques for intelligent integration and testing in industry*
Authors: Braspenning N.C.W.M. , van der Ploeg D.O. , van de Mortel‐Fronczak J.M. , Rooda J.E.
Published: November 2014

The effort required for integration and testing of high‐tech multi‐disciplinary systems is increasing with each new or upgraded system that is developed. To counter this trend of increasing integration and test lead time and costs, we propose a model‐based integration and testing (MBI&T) method, where formal and executable models of the system components are used to replace the component realizations for early integration and system testing. In this paper, we describe how the integration and testing process currently used in industry can be made more intelligent by applying model‐based techniques from the MBI&T method. We also show how to analyze the necessary trade‐off between the investments needed for model development and the potential effort reduction, using a systematic and automatic integration sequencing method.
2.3.3 HCI Aspects of SysML and Architectural Frameworks
Authors: Hause Matthew , Thom Francis
Published: November 2014

The Human Computer Interface (HCI) is one of the most important aspects of any system. It governs how people perceive the environment in which the system is deployed, and can either enable or hinder their ability to interact with that environment. Specifying the appropriate characteristics of the interface is therefore crucial to the correct implementation of the system. The goals of HCI are to develop or improve the safety, utility, effectiveness, efficiency, and usability of systems that include computers. The challenges for HCI are to keep abreast of technology, and to ensure that their designs offer good HCI, as well as harnessing the potential functionality of the new technology. As SysML becomes more prevalent for modeling systems, integrating HCI aspects into these models has the potential for improving HCI, eliminating duplication of tasks, and making systems more useable. This paper will look at SysML and DoDAF/MoDAF (MAF) and how they contribute towards defining the parameters in which the HCI will take place.
2.4.2 Incorporating Software Cost and Risk Assessment into Early System Development Trade Studies
Authors: Weiss Kathryn Anne , Leveson Nancy G. , Francis James
Published: November 2014

This paper introduces a new method called SOCRATES (Software Cost and Risk Assessment for Trade and Engineering Studies) for incorporating software cost and risk assessment into the early concept development activities and trade studies typically conducted for complex systems. Early conceptual architecture trade studies often omit software cost and risk in architectural comparisons. However, the increasing importance of software in complex system design and its impact on project risk necessitates consideration of the cost and risk associated with developing and fielding software in early engineering architectural trade studies. SOCRATES takes into consideration the allocation of functionality to both software and human controllers and evaluates the utility of assigning control based on development cost, development risk, and mission risk. It also provides input to system engineers about the relative comparison of the cost and risk for a variety of system architecture concepts as well as recommendations based on the results. The technique is demonstrated on the Lunar and Mars Transportation and Surface Operations Architectures developed for the NASA Exploration Initiative Concept Exploration and Refinement Study.
4.5.4 Dialogic design for the intelligent enterprise: Collaborative strategy, process, and action
Authors: Jones Peter H. , Christakis Alexander N. , Flanagan Thomas R.
Published: November 2014

Dialogic design provides efficient, reliable approaches for organizations to envision and implement cohesive, comprehensive, and compelling roadmaps for enterprise evolution. Using structured dialogue to integrate the collective intelligence of stakeholders, we produce a shared representation of the intelligent enterprise, enabling “organizing around intellect.” Dialogic design is progressive in focus, scaling from strategic vision to business process design to system requirements, mapping each level's priorities to successive requirements. Each focus inquiry iterates from deep problem understanding, to generative solution design, through consensus action planning.

We applied Structured Dialogic Design to the transformation of a small consultancy, with findings applicable to any enterprise. The process efficiently enables a democratic, collaborative approach to redesign of socio‐organizational systems and practices, using a software‐supported collaborative process. It efficiently achieves true consensus on organizational and business strategy, resolves multiple conflicts of values and resource decisions, and determines the most effective priorities while preventing groupthink errors.
4.6.2 YADSES: Yet Another Darn Systems Engineering Standard
Authors: Walden David D.
Published: November 2014

It has happened to most everyone – someone releases the “next best” Systems Engineering standard (or method or tool or …) and your organization has decided to use it. How does one incorporate this new standard into the existing set of organizational processes without “breaking” the current processes and negatively impacting compliance to all the “old” standards that do not go away? By the way, expect to repeat this process at least every other year.

This paper gives practical advice to help ensure organizations are prepared for these types of situations. Guidance is given on how to establish and maintain organizational processes such that the introduction of Yet Another Darn Systems Engineering Standard (or YADSES as we will refer to it) causes minimal impact.
5.4.2 MV2 Tool Presentation: A management tool for the validation and verification of requirements by Airbus
Authors: Ducamp Christophe , Lagarrigue Alain
Published: November 2014

As the final integrator of the whole of systems and structures, equipments and engines that compose the aircraft, Airbus developed an Information System to manage product requirements and deployed it on a transnational basis. The specification of the tool ‐ labeled MV2 ‐ was based on the process of V&V (Validation & Verification) of requirements applied to a given aircraft program. Apart from the requirements related to its environment of use, and of the interfaces with the existing processes, the tools or databases already in place, the mission of Airbus was to make sure it could control the satisfaction of all the users involved throughout the life cycle of the product in the activities of validation and verification of the requirements. The results obtained by MV2, already applied to the A380 and A400M programs, corroborated the strategy carried out by Airbus, i.e.:

To manage the operational state of a function, system, equipment, structural part, for the whole requirements applied to them.

To challenge the response times between the test results or analyses and the modification of the functional elements, considered at the elementary product level as well as at the comprehensive product level.
6.1.3 System Resilience: Capabilities, Culture and Infrastructure
Authors: Jackson Scott
Published: November 2014

System resilience is the ability of organizational, hardware and software systems to mitigate the severity and likelihood of failures or losses, to adapt to changing conditions, and to respond appropriately after the fact. Challenger, Columbia, Chernobyl and Bhopal are examples of such failures. System resilience goes beyond traditional disciplines, such as reliability and system safety to achieve its goal. System resilience employs systems engineering principles at product and infrastructure levels. The infrastructure system includes such nodes as the developer, the customer, the user, the maintainer, and the operator. System resilience requires that systems engineering principles be practiced across organizational boundaries and to a greater level of detail than is common in today's world. System resilience depends on developing beneficial paradigms within all nodes of the infrastructure. Finally, system resilience requires that all nodes of the infrastructure system have a set of capabilities that are directly derivable from root causes of catastrophes. The combination of capabilities, culture and infrastructure forms the basic framework of system resilience.

A key aspect of catastrophes is emergence, that is, the negative interaction among two or more elements of the system, who, when acting alone perform benignly. Prediction of emergence and design against emergence is a major challenge of resilience.

Adaptability is the characteristic of a system that allows it to survive a catastrophe. Although rules for the creation of adaptability in human‐intensive systems have been formulated, similar rules for hardware and software systems are in their infancy.
6.4.1 The Hitchins‐Kasser‐Massie (HKM) Framework for Systems Engineering
Authors: Kasser Joseph E.
Published: November 2014

George Friedman (Friedman, 2006) called for the development of a grand unified theory of systems engineering (GUTSE) echoing (Hill and Warfield, 1972) who wrote “development of a theory of systems engineering that will be broadly accepted is much to be desired.” Taking up the spirit of the challenge, this paper applies systems thinking to systems engineering to propose a framework that can serve as a vital element in formalizing the discipline of systems engineering and potentially as a platform for developing such a theory.

This paper focuses on what systems engineers do, and builds on past research and success. Documenting research using an object‐oriented approach in a creative and innovative manner it discusses the evolution of a proposed framework for systems engineering that meets or shows promise of meeting the following four requirements (Kasser, 2006):

The framework shall provide an understanding of why systems engineers can't agree on their roles and activities.

The framework shall provide an understanding of the reasons for the overlap between systems engineering and management.

The framework shall provide a way to cope with complexity.

The framework shall enable the lowering of the cost of doing work by at least an order of magnitude.

The framework is based on a combination of the Hitchins' five‐layer representation of systems engineering (Hitchins, 2000) extended by Kasser and Massie over the systems lifecycle phases (Kasser and Massie, 2001) coupled with Shenhar and Bonen's taxonomy of systems based on technological uncertainty (risk) (Shenhar and Bonen, 1997).
6.4.2 A Metric Framework for Capability Definition, Engineering and Management
Authors: Lam Sylvia , Pagotto Jack , Pogue Chris , Hales Doug
Published: November 2014

As defence planning and management evolves from a platform‐centric, threat‐based approach toward a capability‐based paradigm, the need for a rigorous approach to systems engineering at the capability level is amplified. This is because capability‐based plans incorporate system‐of‐systems configurations with varying developmental timeframes that must deliver interoperable effects on the battlefield. In addressing this challenge, a capability‐based planning construct is being examined within the Department of National Defence. This construct is supported by integrating and enabling concepts like enterprise architectures, system‐of‐systems engineering principles and capability metrics. While an architecture framework is useful for developing functional requirements of a capability, a metric framework, as this paper contends, can be used as a guide for defining and articulating desired quality characteristics. This paper describes the concept of a capability metric framework, and how it has been applied to define capability goals and evaluate implementation options.
7.1.4 Coping With System Integration Challenges in Large Complex Environments
Authors: Muller Gerrit
Published: November 2014

The increasing scope of systems integration poses many challenges for the system integrators. This paper contends that in conventional projects the Systems Integration phase is systematically underestimated. During this phase all unexpected and unforeseen problems surface, where most problems are cross‐organizational. When the project size increases with more suppliers, more users, more enterprise processes, and more (intelligent) functionality, then the system integration phase gets tremendously more difficult.

In this paper we will bring order to the integration process and discuss an approach and best practices to cope with systems integration in conventional projects. Such level of integration approach is a prerequisite to deal with all added integration complexity in systems with a scope of (intelligent) enterprises.
7.2.0 Panel 7.2.0: Challenges and Successes in the Deployment of Systems Engineering in the Commercial World
Authors: Jain A. , Brickley L. , Reichart G. , Smith F.
Published: November 2014

Each panel will focus on his or her experience in deploying Systems Engineering in their industry and domain with an emphasis on successful techniques for handling the lack of acceptance and lack of history of SE in each domain. Each Panelist will, at least, address the discussion items: Is there a lack of acceptance of SE in your industry? Is SE practiced in your industry under a different title? Can SE be deployed by management edict and training or one has to employ diplomacy in dealing with internal engineering departments? Can SE practices be domain tailored without sacrificing the basic SE principles? Audience participation will be requested.
7.4.1 Coupling Enterprise and Technology by a Compact and Specific Architecture Overview
Authors: Muller Gerrit
Published: November 2014

Enterprise level projects tend to be delayed and to exceed budgets. Original expectations and targets are not met by these projects. Many solutions have been proposed to address this problem, one of them the application of Systems Engineering at large. In this paper we show how a compact Architecture Overview is a helpful instrument to keep enterprise level projects on track.

Practical experience shows that such an overview provides a quick insight in project progress and in potential threats. Principal customers and managers should ask the architects for this overview. Benefit for the architects of making the overview is that it helps to position their work in the enterprise context. Experience also shows that pragmatic system engineering practices, such as process orientation and project management are complementary to the proposed overview. This combination of overview and pragmatic systems engineering is very powerful.

One of the main issues in creating an architecture overview is the need for breadth, what needs to be included and for whom, and the balancing act of providing sufficient depth, what are crucial details that are part of this top‐level description. Also the way of describing is discussed, from stakeholder needs to ambiguity and the level of formalism.
7.5.1 Taking Out the Garbage – How to Get Good Risks into Your Risk Tool
Authors: Parker Vikki
Published: November 2014

You have a sophisticated risk tool. You have leadership buy‐in on the importance of risk management and you have formal risk management communication channels. Yet, your risk assessment discussions swirl and your list of top risks does not accurately reflect what you know to be true. Worse, the risk information is not helpful in your organization's decision‐making forums. What else can you do? Consider the old saying “garbage in, garbage out.” Before you dazzle them with your quantitative analysis and Monte Carlo simulations, strive for getting good content into the tool. In this white paper, you will see examples of effective risk statements and learn a proven approach for getting better risk data into your organization's decision‐making activities – and put that sophisticated risk tool to good use.
7.6.1 Systems are Imaginary—Systems are Not Real: Some Thoughts on the Nature of Systems Thinking
Authors: Martin James N
Published: November 2014

Systems are not as real as we think they are. It is indeed true that engineers design things that when placed into service are very real. But these things are merely constituents of perhaps many different systems. Which systems these engineered things belong to is really up to our imagination to make such assignments. The assignments of these things to systems is what is involved in “systems thinking.” We make assignments of things to systems before these things exist in order to examine their contribution to the system's intended “purpose.” We can even make assignments of things to (different) systems to examine how they are currently behaving (or perhaps misbehaving). This paper will explore what it means to employ systems thinking to imagine various system structures and to examine these structures for their suitability in different situations to address perceived problems.
8.2.1 The Compilation of an Integrated Qualification and Commissioning Programme for a Nuclear Power Plant
Authors: Brits BC
Published: November 2014

Executive Summary

Systems engineering principles, and more specifically qualification principles, are application dependant. In general, these principles can be easily applied in the qualification of most products in the automotive, aerospace and arms industries. When it comes to the qualification of a commercial nuclear power plant (or probably any commercial plant for that matter), however, there are numerous limiting factors that prohibit the orthodox application of these basic principles.

The intent of this paper is to show how the classic qualification principles can be interpreted and adapted to a specific application, provided there is a solid understanding of both the basic qualification principles, as well as the peculiarities associated with the specific product and its related industry sector. The size, cost, design complexity, maturity of technology base and the projected life cycle of the product, as well as acceptable practices within its industry sector, have a significant effect on how the basic principles can be applied. Once the application of the principles is understood, it becomes relatively easy to plan and structure a process for the compilation of an integrated qualification programme. This process is essential to ensure that all angles are covered during the qualification planning stages, and to ensure effective execution and management of the planned qualification activities.
8.2.2 Improvement of Software Engineering Performances An Experience Report at Bombardier Transportation – Total Transit Systems Signalling Group
Authors: Laporte Claude Y. , Roy Denis , Doucet Mikel , Drolet Marc
Published: November 2014

The performance of the Bombardier TTS/Pittsburgh Signalling group has been evaluated twice: first in November 2003 and again in January 2006. The 2003 evaluation established a baseline for the evaluation of progress made in 2006. During those visits, the same evaluation method was used to evaluate project performance and organizational change management, i.e. the people issues. Since 2003, there has been substantial improvement in both process maturity level and process performance. This experience report, at Bombardier Transportation, illustrates that process performance improvements are achievable when two key factors are involved, namely: a link between business goals and process improvement activities, and a sponsor committing the right level of resources to the improvement program. This paper explains the multi‐dimensional methodology used to perform the evaluations, as well as the business goals and the quantitative performance improvements achieved since 2003.
8.2.3 Optimal integration and test planning applied to lithographic systems1
Authors: Boumen R. , de Jong I.S.M. , van de Mortel‐Fronczak J.M. , Rooda J.E.
Published: November 2014

In the current integration and test phase of the development of a complex system, (the “right side” of the V‐model) planning is becoming more and more difficult because of: 1) variability in delivery times of components, 2) failing tests and subsequent repairs, 3) resource changes and the use of component models, and 4) the growing system complexity and growing number of components and tests. Manually created integration and test plans are often not optimal regarding time‐to‐market. Furthermore, creating and maintaining these plans costs a lot of effort. In this paper, we introduce a method that allows to automatically create optimal integration and test plans. This method can be used by intelligent enterprises to shorten the time‐to‐market of a system and to reduce the effort needed to create and maintain integration and test plans. We illustrate this method with two cases studies related to the development of ASML lithographic machines (ASML 2006).
8.3.1 Bridging the Chasm ‐ Tracing from Architectural Frameworks to SysML
Authors: Hause Matthew , Thom Francis
Published: November 2014

A conspicuous disconnect exists between a MoDAF/DoDAF Architectural Model (MAF) and any subsequent Systems Engineering modeling activities. MAF permits the modeling of 'system‐of‐systems' and they both facilitate the capture of the high‐level properties of a system's interfaces. However, how is this critical information communicated to an organization contracted to develop the real system? How does an organization ensure traceability from MAF artifacts and any subsequent Systems Engineering artifacts? In addition to heavyweight and lightweight mapping, SysML offers bridges that provide traceability between artifacts in MAF and any subsequent system specification. The concepts used by the different languages are examined as well as mapping from MAF to SysML. Then this paper explores allocation and requirements traceability. Due to the inherent extensibility of a UML‐based model, properties not prescribed by MAF (‘Risk’) can be added to a MAF and the two approaches to flow‐down can be augmented with these domain specific properties.
8.3.3 Enterprise Domain Modelling Process Using SysML for the Tooling Enterprise at the U.S. NNSA's Pantex Plant
Authors: Griego Regina M. , Mayes Larry M. , McGrath Daniel A.
Published: November 2014

This paper describes the process and methods applied in modelling an enabling enterprise within the NNSA Pantex Plant within the U.S. Nuclear Weapons Complex. The process used is based on the Enterprise Domain Modelling and systems analysis methods enabled by Systems Modelling Language (SysML). SysML consists of four types of views to describe a system: structure, requirements, parametrics, and behavior (INCOSE, 2006). The model illustrated behavioural viewpoints of the tooling enterprise.
9.2.2 Object‐Oriented Systems Engineering Method (OOSEM) applied to Joint Force Projection (JFP), a Lockheed Martin Integrating Concept (LMIC)
Authors: Friedenthal Sanford , Izumi Lisa , Meilich Abraham
Published: November 2014

A Lockheed Martin Team is developing an enterprise architecture to specify a Joint Mission Capability Package for Next Generation Long Range Strike (NGLRS) in support of Major Combat Operations. The modeling approach leverages the Object‐Oriented Systems Engineering Method (OOSEM) and the newly adopted Object Management Group Systems Modeling Language (OMG SysML™) using the I‐Logix Rhapsody modeling tool. The preliminary modeling effort resulted in a model of the enterprise architecture and an executable architecture to support behavior analysis and simulation. The analysis and simulation are intended to allow JFP to validate customer and mission requirements and develop and demonstrate System of Systems (SoS) architecture solutions. A brief overview of SysML is included in the paper; however, those who are not familiar with SysML will benefit from a review of the OMG's SysML Tutorial [3].
9.2.3 Standardized Process as a Tool for Higher Level Systems Thinking
Authors: Lamb Caroline Twomey , Rhodes Donna H.
Published: November 2014

Standardized processes are being used to address three issues in engineering today: increasing system complexity; shifting demographics; and longer development cycles that result in a dearth of experiential learning for young engineers. There is obvious value in having engineers who can see the big picture and effectively broker design tradeoffs: engineers capable of systems thinking. However, what is the impact of standardized processes on the ability of teams of engineers to make these critical tradeoffs? This paper lays the groundwork for research investigating ways in which standardized process usage facilitates or hinders systems thinking within engineering teams—termed collaborative systems thinking.
10.1.1 Capability Engineering: Learning from Practice
Authors: Lalancette Claire , Lizotte Michel , Nécaille Christophe , Pagotto Jack , Robbins Wayne , Waruszynski Barbara
Published: November 2014

For over four years, Defence R&D Canada has been investigating Capability Engineering, which aims at supporting the Capability‐Based Planning (CBP) decision‐making process, under the Collaborative Capability Definition Engineering and Management Technology Demonstration (CapDEM TD) project. Based on the systems engineering paradigm, the approach is articulated around three axes: People, Process and Materiel. This paper presents the results of an experimental evaluation conducted to assess the CapDEM approach to Capability Engineering. The focus is on the lessons learned from Exercise Beta, the second of three validation exercises which are part of an evaluation strategy attempting to evolve capability engineering from theory into practice.
11.1.2 Systematic Enterprise Definition
Authors: Grady Jeffrey O.
Published: November 2014

One prerequisite to enterprise improvement is management awareness of the enterprise current process, organization, and the relationship between these entities. That is, the enterprise must define itself as a system capable of satisfying a pre‐defined enterprise functionality using a particular organizational entity structure derived from that needed functionality. If this sounds familiar, it should because it is precisely the way system engineers have defined product systems for many years applying traditional structured analysis. The same methods used to define large product systems can be employed to define enterprises and their programs which are, after all, process systems. This paper describes how this process can be employed to re‐engineer an enterprise that has been found to be inefficient. It is not suggested as a way to originally engineer an enterprise, though it will work in that context, because enterprises are commonly formed by entrepreneurs who seldom have a lot of interest in organized ways of thinking. Over time, however, an initial success will often expose a need for better discipline and efficiency.
Effective industrial modeling for high‐tech systems: The example of Happy Flow
Authors: Beckers J.M.J. , Muller G.J. , Heemels W.P.M.H. , Bukkems B.H.M.
Published: November 2014

In the design of high‐tech systems like copiers, wafer steppers and televisions, modeling plays an important role. However, not all developed models are industrially successful. It would be very beneficial if guidelines were available on how to create industrially effective models that support the system architects and speed up the multi‐disciplinary design of high‐tech machines. In this paper, we describe a very successful industrial model in the context of the design of copiers. The model is developed for the design of the paper transport system (the mechanical layout of the paper track, the schedule of print jobs, sensors, actuators, etc.) in a multi‐functional office copier. As most other activities in the printer are synchronized to the paper transport system, this design issue is at the heart of the overall design and has a major influence on the total functioning of the machine. The so‐called Happy Flow model is based on kinematic modeling and its generic elements are not restricted to copiers only. Its main ideas are applicable to a much wider range of mechatronic products. It is important to learn from such instances of successful industrial models. The aim of this paper is to identify the success factors of this particular model, which forms a first step towards a more systematic method on how to construct industrial effective models.
Creative Product Development
Authors: Dick Michael J.
Published: November 2014

Enterprises can establish a culture for engineering creativity by encouraging engineers to practice proven conceptualisation techniques that lead to better designed systems. This paper presents several easily‐performed creativity techniques that work within the context of engineering.
1.3.1 Measuring Systems Engineering Success: Insights from Baseball
Authors: Blackburn Craig , Valerdi Ricardo
Published: November 2014

Optimizing the efficiency of socio‐technical systems and determining accurate measurements of performance is a critical issue in many systems engineering enterprises. In our analysis we explore some of the recurring themes of Michael Lewis's study of baseball, depicted in the best selling book Moneyball, and we make the connection to corresponding systems engineering principles of interest. The paper will focus on the systems engineering roadmap inspired by Lewis' study for developing and refining a meaningful set of metrics for organizational transformation. The following steps are highlighted to convey this transformation with the assistance of metrics: identify and understand value in the enterprise and your organization; consider an integrated system focus in your organization; use cost analysis methods to implement a strategy for executing the transformation; and manage risk throughout operations and improve the process continuously.
1.4.3 A Sustainable Energy Economy: The Next Challenge for Systems Engineers
Authors: Snyder Neil
Published: November 2014

The realities of shrinking fossil fuel reserves, growing global energy demand, and climate change concerns will force a change to a sustainable energy economy. Systems engineers need to take a leadership role in making the transition to this new energy economy. A study of large projects from the past provides some insights into methodologies that might be used to effect this transition; however, the complexity of the energy transition is far greater in some respects than on these earlier projects. The timeframe of this transition is measured in decades, the technologies involve numerous industries, and the spatial dimension involves the entire planet. Systems engineers will not only need new tools but will need to step into somewhat different roles than in the past. It is time to start planning for these new challenges, and INCOSE should play a key role in this planning.
1.5.0 Architecture Concepts, Principles, and Terminology
Authors: Malhotra S , Dickerson C E , Martin J , Bendz J , Martin R , Sillitto H , Wilkinson M , Ring J
Published: November 2014

An invitational workshop at the January INCOSE International Workshop (IW08) was held to clarify the concepts, principles and terminology for the architecture of systems and enterprises. The results of this workshop have served the needs of several groups: the two ISO standards committees dealing with architecture, TC184/SC5/WG1 and JTC1/SC7/WG42, the Model Based Systems Engineering initiative, and various INCOSE Working Groups. Attendees of this panel will learn the outcome of recent debates on concepts, principles and terminology and how they have helped the progress of the ISO groups and other stakeholders in this critical domain.
2.3.2 COSYSMO Reuse Extension
Authors: Wang Gan , Ankrum Aaron , Valerdi Ricardo , Millar Cort , Roedler Garry J.
Published: November 2014

Reuse in systems engineering is a frequent, but poorly understood phenomenon. Nevertheless, it has a significant impact on estimating the appropriate amount of systems engineering effort with models like the Constructive Systems Engineering Cost Model. Practical experience showed that the initial version of COSYSMO, a model based on a “build from the scratch” philosophy, needed to be refined in order to incorporate reuse considerations that fit today's industry environment. The notion of reuse recognizes the effect of legacy system definition in engineering a system and introduces multiple reuse categories for classifying each of the four COSYSMO size drivers – requirements, interfaces, algorithms, and operational scenarios. It fundamentally modifies the counting rules for the COSYSMO size drivers and updates the definition of system size in COSYSMO.

In this paper, we present (1) the definition of the COSYSMO reuse extension and the approach employed to define this extension; (2) the updated COSYSMO size driver definitions that are consistent with the reuse model; (3) the method applied to defining the reuse weights used in the modified parametric relationship; (4) a practical implementation example that instantiates the reuse model by an industry organization and the empirical data that provided practical validation of the extended COSYSMO model; and (5) recommendations for organizational implementation and deployment of this extension.