bluuebunny/crossref_metadata_2025 huggingface dataset:
10.3.1 Classification of Systems from Component Characteristics
Authors: Shaja A. S. , Sudhakar K.
Published: November 2014

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

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

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

Productivity measurement has long been employed to guide economic activities. Engineering organizations, as labor‐intensive economic entities, have used a variety of labor productivity metrics to capture the underlying productivity and efficiency (a reciprocal notion), in their ever‐enduring attempts to produce more outputs with fewer human resources. Depending on the functional disciplines, some widely embraced and de facto standard measures range from hours per drawing in hardware engineering, to lines of code per hour or day practiced in software engineering. Systems engineering, a relatively young profession still struggling to find its identity at times, has not yet reached an agreement on how it should capture its productivity and efficiency. However, such a measure is critical in managing resources, improving processes and work output, and establishing its utility as a bona‐fide field of engineering in production of goods and services.

This paper presents a proposed systems engineering productivity and efficiency (P&E) measure for system development projects, where there is usually the greatest amount of systems engineering content. This measure is defined by using parameters described in COSYSMO, a parametric estimating model for systems engineering. We provide the definition, recommendations for deployment, and relay our experience in applying this measure to organizational productivity and efficiency improvement.
Enabling Collaborative Decision Making through Applied Systems Engineering Tools, Methods, and Processes
Authors: Ender Tommer R.
Published: November 2014

Increasingly complex problems involved in systems development drive systems engineers to develop novel decision making processes. The breadth of complex problems demands the interaction of various stakeholders, including both decision makers and subject matter experts, each focusing on specific areas but all addressing a higher level common cause. The process brought forth in this tutorial integrates a series of methods, some widely accepted and others which are novel in nature, in order to enable a collaborative process for technology selection. Quality Function Deployment is used to capture customer desires and focus engineering level requirements. Multi‐Attribute Decision Making is used to identify system configurations when multiple and competing objectives exist, which is a situation where traditional system optimization struggles. System modeling is a necessary step to analyze and understand the impact of various systems options. This seminar therefore introduces the process of surrogate modeling in order to rapidly access elements of modeling and simulation, a necessary step to analyze system options. The very integration of these applied systems engineering methods enables collaborative decision making throughout system development. A proof of concept is presented where each of these methods is applied in the technology selection portfolio analysis of renewable energy system options for a remote off‐grid site.
Establishing and Using Risk Management Effectively
Authors: Powell Mark A.
Published: November 2014

We manage risk every day of our lives. You would think all good SE's would be good risk managers. Yet many enterprises fail because some unidentified or un‐handled risk materializes. Many enterprises fail to take advantage of positive risks (opportunities) that could all but ensure success. Risk Management is not as easy as it seems it should be.

This tutorial reveals to both the new SE and the seasoned veteran looking for a refresher the secrets of Risk Management and how to make it work. We will review the basic concepts of formal Risk Management and how it is executed in Systems Engineering. We will cover in depth all seven areas of Risk Management: Identification, Analysis, Assessment, Mitigation, Accounting, Planning, and Communication. Each of these areas will be approached with a specific emphasis on how they work together to make an enterprise successful. Further, we will set up a framework for introducing Risk Management within Systems Engineering, to work synergistically by integrating it with Project Management. And as icing on the cake, we will introduce some new methods for risk assessment that make the practice much more effective.
Lean Enablers for Systems Engineering
Authors: Oppenheim Bohdan “Bo” W.
Published: November 2014

Lean Thinking is the paradigm that enabled Toyota to rise to the best and largest auto company in the world. The paradigm includes not only Lean manufacturing but also extraordinary effective Product Development and Systems Engineering, as well as a culture based on Respect for People.

Systems Engineering is regarded as a technically sound process but often burdened with waste and inefficiencies. Lean Systems Engineering is a new body of knowledge applying the wisdom of Lean Thinking to Systems Engineering. Systems Engineering and Lean have overlaps and differences, but both represent processes that evolved over time with the common goal of delivering product or system lifecycle value to the customer. Lean Systems Engineering represents synergy of the two, leading to superior systems engineering process.

Most emphatically, Lean Systems Engineering is not a re‐packaged FBC or Acquisition Reform“. Lean Systems Engineering does not mean ”less Systems Engineering”; it means more and better Systems Engineering, with better preparations, planning, front‐loading, training, and more common sense, leading to better program execution.

Lean Enablers for Systems Engineering is a product designed by 14 experts from industry, academia, and U.S. and foreign governments, supported by 115+ strong Lean Systems Engineering Working Group of INCOSE. Lean Enablers are formulated as 194 “do's” and “don'ts” of Systems Engineering practice focused on Mission Assurance/Product Success and elimination of waste.

The workshop will cover three parts:

Description of the development process of Lean Enablers for SE

Presentation of 194 Lean Enablers organized into six Lean Principles: Value, Value Stream Mapping, Flow, Pull, Perfection, and People.

“Validation” of the Lean Enablers by surveys, and by benchmarking with recent studies by NASA and U.S. Government Accounting Office.

Early feedback from past tutorials and implementation
Writing and Managing Interface Requirements
Authors: Hooks Ivy
Published: November 2014

Caveat: If you have not had basic training or mentoring in writing requirements, this tutorial assumes you have those skills. This tutorial assumes you know how to write a good requirement and avoid the basic requirement defects. It also assumes you have seen some interface requirements, at some level in your work.
Roadmapping for Strategy Support
Authors: Muller Gerrit
Published: November 2014

Formulating and deploying a strategy requires a combination of vision and analysis. Roadmapping is a tool to explore and articulate future needs and trends for different dimensions.

Unfortunately most companies limit their roadmaps to either products and technology. In this tutorial we will show how to increase the roadmap value by integrating dimensions such as the market and customer context, the product portfolio, the technology, competences and supply chain, and processes. Roadmapping helps by relating these different dimensions in time, with a horizon of many years. We will discuss how to create and maintain roadmaps and give practical tips on the format.

All information (System Architecture articles, course material, curriculum vitae) can be found at: Gaudí systems architecting http://www.gaudisite.nl/
A Model Driven Development approach to supporting System Engineering Trade Studies
Authors: Bleakley Graham John
Published: November 2014

It is very common in manufacturing organizations for the organization to build its new products using the same or similar technology as the previous versions of the product. This means that the organization is not making the best use of new technology or components that could potentially improve their products and/or profitability. This presentation demonstrates an objective approach to evaluate and select complex physical architectures, i.e. doing a Trade Study. It is based upon SysML and it uses a modeling toolset (ref 1) to demonstrate the technique. The approach is based upon the definition of assessment criteria and target values for the product under consideration. Various means of physically realizing the architecture are proposed and the combined effect of the various components evaluated against the target values for the product. The results of this are used as the basis for final selection of the architecture. A practical worked example is provided throughout the paper to further demonstrate the techniques involved.
Applying Systems Engineering in a Renewable Energy Research & Development Environment
Authors: Snyder Neil , Antkowiak Mark
Published: November 2014

Systems Engineering (SE) practice has largely developed around a few specific industries, especially aerospace/defense and IT. SE is well understood by, and remains associated with, these industries. The classical systems engineering process starts with conceptual development of a specific system that will ultimately be produced and deployed. In the renewable energy R&D environment, neither of these normal cases apply; the work is being conducted in a culture that is generally unfamiliar with systems engineering, and the R&D activities are mostly oriented toward technology development and refinement rather than toward development of a specific deployable system. Nevertheless, systems engineering principles can be applied to enhance the management of the Research & Development (R&D) process, but significant tailoring of SE processes is required, and enhanced modeling and simulation techniques must be applied to deal with all the unknowns at a very early part of the system lifecycle. The lessons learned from several years of experience in this unique environment at the National Renewable Energy Laboratory, as well as a number of new ideas for future process enhancements, will be explored in this paper.
A Student's Perspective on the Education of Systems Engineers
Authors: Calderon Juan C.
Published: November 2014

The education of systems engineers is a main focus of the International Council on Systems Engineering (INCOSE). INCOSE released its latest guidance via the Systems Engineering (SE) Vision 2020 which describes the need for an increase in several aspects of systems engineering including how we educate systems engineers. Being a current graduate student of systems engineering provides me with unique insights into this process. To augment my academic experience, I also bring several years of experience in the military defense industry. This paper presents my experience through multiple perspectives, while analyzing the current curriculum for systems engineering education. The main lesson learned is that the study of systems engineering is a journey and not a destination.
A Day in the Life of a Verification Requirement
Authors: Scukanec Stephen J , van Gaasbeek James R
Published: November 2014

One measure of the quality of a product requirement is that it be verifiable. Verifiability assessment is one of the exit criteria for the Systems Requirements Review and is necessary for requirement validity. Nomination of one or more verification methods (examination, analysis, demonstration or test) is often taken as the sole evidence of verifiability. A completed Verification Cross Reference Matrix is frequently considered as the final verifiability assessment and responsibility for the remainder of the verification effort is transferred to the test and evaluation and other implementing communities for completion.

Lessons learned from many Programs have shown that a more robust application of systems engineering should include the requirements engineers (with detailed knowledge of product requirement intent) working with the verification implementing organizations as the best combination to define the verification requirements. Such definition should include statement of the verification objectives, success criteria and environment. Including this information in the “Quality Assurance” section of the requirements document allows for buy‐in by the customer well in advance of implementing the verification activities. This information is used by verification personnel to generate one or more verification plans and to develop the detailed verification program. Verification requirements are planned into verification events which are executed using the proper system elements and environments. These verification requirements are key to establishing long lead verification facilities, tools and laboratories. Early definition of these requirements helps prevent facility re‐designs and verification re‐plans that can cause expensive delays. Finally, verification data analysis is performed, and the information compiled into verification reports certifying system product requirements compliance. This robust verification approach will provide proof of requirements satisfaction, leading to systems that meet the customers' needs at a lower life‐cycle cost.

This paper is written to explore the value of well‐crafted verification requirements developed early in the Program. A “Day in the Life of a Verification Requirement” shows the interaction and benefits of verification requirements to the verification execution teams. The reader will be offered a lifecycle description of the verification requirement from conception to certification.
3.3.1 System Phases, Modes, and States: Solutions to Controversial Issues
Authors: Wasson Charles S.
Published: November 2014

System phases, modes, and states are often one of the most controversial concepts in System Engineering due to a lack of standards for implementation. Yet, the topic serves as one of the most critical guiding principles of System Engineering: Decompose system complexity into manageable levels and entities with acceptable risk that lead to optimal system design solutions.

Four issues contribute to the challenges of implementing system phases, modes, and states:

Issue #1 – Definitions of “mode(s)” and a “state(s)”

Issue #2 ‐ Do “modes” contain “states” or do “states” contain “modes”?

Issue #3 ‐ Should specifications specify “modes and states”?

Issue #4 ‐ Should specifications flow down “modes and states”?

To address these four issues, this paper provides a statement of the problem, identifies sources of the problem, provides clarifying definitions, and provides illustrative examples of “modes” and “states”. Building on the foundational definitions, the paper explores the entity relationships (ERs) between phases, modes, and states and how they can be employed as a problem solving‐solution development framework to identify and link system phases of operation, modes, use cases, various types of states to the system architecture.

This paper proposes that due to the abstractness and understanding of the term “state”, communications among engineers becomes confusing and conflicting. Investigation and analysis of this reveals that “states” have at least four contexts of usage: 1) organizational or logistical employment of a system as an asset – i.e., System States, 2) the operating condition of a system– i.e. Operational States, 3) the time and operating environment‐dependent dynamics of a system – i.e., Dynamic States, and 4) the physical arrangement of architectural capabilities to achieve performance‐based outcomes – i.e., Physical Configuration States.

Based on a solution to Issues #1 and #2 that fuel the controversy, the paper addresses the final two issues – i.e., Issues #3 and #4 ‐ concerning specifying and flowing down “modes and states” in specifications. We conclude with a summary of recommendations concerning the four issues and provide suggestions for effective SE leadership to lead, apply, and orchestrate the concept of system phases, modes, and states.
4.6.3 An MBSE Feasibility Study using the Systems Integration Sandpit
Authors: Do Quoc , Lovric Bojan , Cook Stephen
Published: November 2014

Model‐Based Systems Engineering (MBSE) involves a focal shift from document‐centric to model‐centric systems engineering practices in which the model becomes the primary systems engineering artifact to represent the system specification and design. For an organization, early adoption of new approaches such as MBSE requires careful consideration of the cultural change, staff training needs, and introduction mechanisms to inform the cost‐benefit tradeoff and to ascertain the level of risks. To this end, this paper describes a pilot study conducted to investigate the above using an in‐house robotic surveillance system. The paper opens with a brief introduction to MBSE tools and methodologies, and the advantages advocated by the MBSE research community. The body of the paper describes the SysML model development activities undertaken in the pilot study and the lessons learned in the process. The paper concludes with a discussion on the potential of MBSE for major defence programs and for systems of systems integration.
11.3.1 Transforming the Enterprise Using a Systems Approach
Authors: Martin James N.
Published: November 2014

Enterprise Systems Engineering (ESE) is an emerging discipline that can be used to more confidently and rapidly create the essential changes for the modern enterprise to survive in these days of enormous economic and social uncertainty. Systems Engineering (SE) could have much to offer in enabling this transformation, but significant enhancements to traditional SE tools and methods must be brought to bear. This paper describes a set of principles and concepts that enables greater benefits when using the systems approach for enterprise transformation. These enhancements include technical activities, of course, but they also address the substantial leadership and managerial challenges at the enterprise level.
1.1.2 Applying Model Based Systems Engineering approach to Smart Grid Software Systems Security Requirements
Authors: Lakshminarayanan Sitaraman , Souvannarnarth Manyphay
Published: November 2014

Smart Grid Systems are a classic example of a System of Systems. Smart Grid brings intelligence to the existing electric grid by integrating various software and devices from domains [1] such as Transmission, Distribution, Customer, Bulk Generation, Operations, Markets and Service providers. Security is very critical both from a reliability and compliance standpoint. Smart Grid as a System of Systems contains various Software Systems that provide the necessary intelligence and integration. Therfore building security within software systems is very critical as opposed to bolt on solution that is often deferred until deployment. System Architects face a tough challenge in understanding what are the various security requirements, how such requirements are applied to software systems at various interfaces, how to capture the system security artifacts and articulate it better to stakeholders. We describe how various model based systems engineering concepts are applied in capturing the requirements and how those requirements are applied to various components and interfaces and can provide traceability.
1.2.1 The Architecture and Design of a Corporate Engineering Data Repository
Authors: Wang Gan , Saleski Lori
Published: November 2014

Historical data has increasingly become an essential asset to enable engineering organizations to optimize its processes and improve its performance, as it empowers business organizations to engage and maneuver the challenging marketplace. In this paper, we present an enterprise‐level engineering data repository developed to systematically capture the corporation's historical program data. We highlight the architecture and design aspects that aim to support the lifecycle data needs of multiple engineering organizations and discuss the major components including the database, a set of data collection and analysis tools, and a collection process. We also relay our experience in governance issues and practical lessons learned. This repository has been systematically populated over the past five years and used in support of business winning and program execution.
1.3.2 Tailoring Systems Engineering Processes in a Conceptual Design Environment: a case study at NASA Marshall Spaceflight Center's ACO
Authors: Mulqueen John , Maples C. Dauphne , Fabisinski Leo
Published: November 2014

This paper provides an overview of Systems Engineering as it is applied in a conceptual design space systems department at the National Aeronautics and Space Administration (NASA) Marshall Spaceflight Center (MSFC) Advanced Concepts Office (ACO). Engineering work performed in the NASA MFSC's ACO is targeted toward the Exploratory Research and Concepts Development life cycle stages, as defined in the International Council on Systems Engineering (INCOSE) System Engineering Handbook.

This paper addresses three ACO Systems Engineering tools that correspond to three INCOSE Technical Processes: Stakeholder Requirements Definition, Requirements Analysis, and Integration, as well as one Project Process – Risk Management. These processes are used to facilitate, streamline, and manage systems engineering processes tailored for the earliest two life cycle stages, which is the environment in which ACO engineers work.

The role of systems engineers and systems engineering as performed in ACO is explored in this paper. The need for tailoring Systems Engineering processes, tools, and products in the ever‐changing engineering services ACO provides to its customers is addressed.
1.4.3 The Open Academic Model and the Impact of the Stevens Systems Engineering Program
Authors: Lasfer Kahina , Pyster Art
Published: November 2014

The Open Academic Model (OAM) is the research and education concept adopted by the Systems Engineering Program at Stevens Institute of Technology. Applying OAM principles, the Stevens program has grown from inception in 2001 into one of the largest in the U.S. in terms of education and research. The Stevens Systems Engineering program performance and consequent impact is characterized with respect to the OAM, which is based on five principles: (1) Broad Partnerships, (2) Blurred Boundaries, (3) Agile Environment, (4) Community Sharing; and (5) Second‐Career Faculty. The individual aspects of the OAM are not unique to Stevens, but the combination is novel and has underpinned Stevens' impact when the program is measured against the four general criteria of size, quality, publication record, and faculty leadership. The OAM has been implemented via a number of strategies that correlate with the performance of the program.
2.3.1 The U.S. Department of Defense Technology Transition: A Critical Assessment
Authors: Sharif Azi , Yu Junfang , Stracener Jerrell
Published: November 2014

Technology transition and implementation is a major challenge for the U.S. Department of Defense (DoD). The DoD utilizes the Technology Readiness Level (TRL) to measure technological maturity of projects for transition to the acquisition phase. However, the TRL is just a technology maturity metric and does not consider other factors, such as the project's costs benefits and risks rewards, that the acquisition community needs to consider in implementing a project; and this has led to delayed acquisition of projects with high TRL. Rapid technology transition requires additional metrics to supplement TRLs. The focus of this paper was on a critical review of methodologies developed for DoD's technology transition process. The literature review examined major empirical studies that have evaluated DoD's technology transition outcomes to identify main bottlenecks and shortcomings. We conclude that DoD's technology transition and acquisition needs improvement in measure of effectiveness.
2.4.1 A Case of Systems Engineering in Daily Life
Authors: Lee Cheol Woo
Published: November 2014

Ever since SE had been introduced in Korea in the early 1990s, many Korean SE preachers or System Engineers have tried to introduce SE to the Korean industry, Korean engineering society or Korean Government, but hardly succeeded.

Then some questions arose. What is SE in a word? What does each SE process mean for us in our daily lives? If SE is so useful, it should also be easily understood even by any ordinary people.

This paper shows a usual daily issue in a family about purchasing a new kitchen cooker, on which they could ‘successfully’ apply the ‘useful’ SE process. With this case, explaining SE to anybody has become easier in less than 10 minutes.

The case also depicts how human factors in system design play a crucial role ie. emotional, psychological, value factors and other soft human factors, which are a new challenge for the systems engineers.
2.4.2 Systems engineering saves the day!
Authors: Haskins Cecilia , Welland Alexander
Published: November 2014

This paper is an experience report about how adding a systems engineer to a project helped the team achieve a second‐place result in a competition despite overwhelming technical and programmatic obstacles. The setting of the case in this report is Trondheim where the co‐author joined a student team that should design and construct a car to compete in the Shell Eco‐marathon. The project started August 2010 and ended May 2011, but the systems engineer joined the project late, and started his work in the middle of January 2011. The paper takes the reader on a journey following the steps taken to introduce and apply systems engineering techniques in a project that was time and resource constrained. The paper demonstrates the effectiveness of simple techniques, such as the “Systems Engineering Wall,” to implement systems engineering practices and improve team communications. The conclusion is that the systemic and systematic approaches of systems engineering, in this instance, helped the team achieve a winning result.
2.6.1 Graphical Representation of Situation Awareness in Joint Cognitive Systems
Authors: Hew Patrick , Byrne Lydia , O'Neill John
Published: November 2014

We propose a framework for modelling situation awareness (SA) in joint cognitive systems (JCS) of humans and machines. The key idea is to adopt a building block approach. The building block encapsulates the extant, mature theory of SA in an individual agent, for their individual workflows. We then articulate rules for assembling agents, for workflows that run across the JCS. Systems engineers gain an analytic tool and design patterns for improving SA in JCS, leveraging the potential of modern, digital technology.
3.4.1 Yes systems engineering, you are a discipline
Authors: Kasser Joseph , Hitchins Derek
Published: November 2014

Systems engineering is currently characterized by conflicting and contradictory opinions on its nature. The paper begins by describing the evolution of systems engineering in the National Council on Systems Engineering (NCOSE)/ International Council on Systems Engineering (INCOSE) and the difficulty in defining and differentiating systems engineering as a discipline. The paper then identifies and discusses six different and somewhat contradictory camps or perspectives of systems engineering. After identifying the cause of the contradictions the paper suggests one way to reconcile the camps is to dissolve the problem to distinguish between the activity known as systems engineering and the role of the systems engineer with a return to the old pre‐NCOSE systems engineering paradigm. The paper then continues by testing the hypothesis and shows that systems engineering is a discipline that can be differentiated from other disciplines. However, it is not a traditional engineering discipline.
3.6.2 Next Generation Requirements Engineering
Authors: Favaro John , Mazzini Silvia , Schreiner Rudolf , de Koning Hans‐Peter , Olive Xavier
Published: November 2014

Establishing and managing a “good” set of requirements is one of the critical success factors for any space system project, and for the development of any complex product in general. The NextGenRE project sponsored by the European Space Agency has developed an innovative approach featuring the use of semantic wiki technology to enable users to specify structured, semantically‐rich requirements associated with canonical system designs in OMG SysML. Reuse of requirements through templates is supported, as well as semantic reasoning to check properties such as consistency and coherence among requirements. The approach is entirely model‐based, allowing tight integration of the requirements engineering and design processes and opening the way to the application of model checking and simulation techniques. The new approach is being validated alongside an existing space project.
4.4.1 Using MBSE Methodology to drive a PLM Initiative
Authors: Ciriello Daniele
Published: November 2014

Product lifecycle management (PLM) is recognized as one of the key leading technologies to facilitate companies to overcome global market challenges, by adopting a new way to rapidly plan, organize, manage, measure, and deliver new products or services much faster, better, and cheaper in the extended enterprise. Following these aspects, PLM initiatives have to be organized and managed to orchestrate overall complexity: although first activities related to PLM Vision & Strategy definition as well as PLM project organization and plan are strongly emphasized by literature and business excellence, PLM System Design is often underestimated with a general decrease of industrial ROI. Focusing on this aspect, this paper describes formal method for PLM Implementation based on Model Based System Engineering (MBSE) approach. Starting from an overview of domain related to System Development Lifecycle (SDLC) and System Engineering methodologies, description of a PLM Initiative is made, applying proposed approach to a PLM Project.
4.4.3 Efficiently Managing Product Baseline Configurations in the Model‐Based System Development of a Combat System Product Family
Authors: Mitchell Steven W.
Published: November 2014

Efficient management of product configuration baselines is a challenge in the evolution of any industrial scale product family. This is particularly true with current standards‐based system modeling tools, as the standards themselves are just beginning to address this problem in a scalable fashion.

In the case of the Submarine Warfare Federated Tactical Systems (SWFTS) common submarine combat system, dozens of product configurations must be managed in parallel, with many of those baselines being updated several times a year. To support this activity a new SysML modeling technique has been developed for constructing hardware and software component bills of materials. It extends the concepts of libraries with SysML catalogs to bound the complexity of the task, improving the quality and efficiency of the systems engineering process.

General Terms: Systems Engineering, System Evolution
5.1.1 Verification & Validation; An inconvenient truth
Authors: Elich Erik , Schreinemakers Paul , Vullings Maarten
Published: November 2014

This paper addresses several inconveniences regarding the proper use of Verification and Validation. The inconvenient truth is addressed by discussing reality in projects and domains, versus the widely accepted definition of Verification & Validation, versus the way we think both projects and developments should be managed and versus the aim to achieve transparency in the relationship between principals and contractors.
5.5.1 A SysML‐based Approach for the Specification of Complex Systems
Authors: Petrinca Paolo , Gammaldi Mario , Tirone Lucio
Published: November 2014

This paper describes a SysML‐based approach for the definition of the different layers of requirements necessary for a full functional specification of complex systems and/or systems‐of‐systems. The approach is specifically suited to those cases in which the development of the system as a whole and that of the single system elements (or of subsets of system elements), are under the responsibility of different development teams, within the same firm or belonging to different firms.

The process is based on a recursive approach, in which each layer of the development must: i) interact with its “customer”, through the acquisition and analysis of the stakeholder requirements applied to the system, ii) define the system‐level requirements as a result of a black‐box analysis of the system's behavior, and iii) perform a white‐box analysis for the definition of the system elements' requirements.
6.4.1 Systems Engineering Business Context: The Evaluation of the South African Systems Engineering Industry
Authors: Harding Charl
Published: November 2014

Systems Engineering and Business Strategy might seem to be at different sides of the Business spectrum, but in reality Systems Engineering is a vehicle for achieving the goal set by Business Strategy and obtaining a competitive advantage. It is the author's experience in both military and commercial projects, that most Systems Engineers do not have an understanding of the business principles such as marketing and economics to be taken cognizance of during the design and development of system. The current Systems Engineering standards like the INCOSE handbook, ISO/IEC 15288‐2008 and ANSI/EIA‐632‐1998 also do not always provide any standard processes or activities that could guide Systems Engineers in looking at the business case during the Systems Engineering life cycle.

The top management of the organization is responsible for defining the business strategy that defines the direction to enable the organization to satisfy the market demands and subsequently make profit to build a sustainable business. In a Systems Engineering organization, market needs are satisfied through products and services that Systems Engineers are responsible for, but the author's experience has shown that Systems Engineers do not partake in development of organizational strategy. In many cases the Systems Engineers do not even know the organizational strategy. This may cause a misalignment between the organizational strategy and the products and services delivered to customers.

The importance of incorporating the business strategy into the Systems Engineering process is becoming more important in order to remain competitive in the global market. The business strategy alignment of Systems Engineering projects is even more important during the current recession of the global economy. This paper investigates the relationship between Systems Engineering, business and the business case of the project the system engineer is responsible for. The relationship between Systems Engineering and Business Strategy to enable Systems Engineering to become the competitive advantage of an organization is also investigated.
6.4.2 The 7 +/‐ 2 Uses For An Estimation Tool
Authors: Nolan Andrew J. , Pickard Andrew C.
Published: November 2014

Rolls‐Royce adopted COCOMO II in 2004 in order to improve its estimation capability. Since then COCOMO”s importance has grown within the business and has had far reaching effects well beyond its initial remit. COCOMO has been applied to software development, software supplier oversight, improvement identification, improvement validation, risk identification and even business decision making. The tool has become a common language that unites projects, engineering, business, risk and improvements. The tool was also read across into hardware Engineering. Through the adoption of COCOMO, we have seen an 11% reduction (on average) of project costs as well as greater program stability and predictability. This paper is intended to describe our journey and the next steps for Rolls‐Royce

This paper is written in two parts. The first part describes the lessons learnt during a six sigma Black Belt to improve our estimation capability. Part two of the paper then describes the benefits we got after we had embedded the estimation capability into the business.
7.7.3 The Requirements Engineering Process Design for Six Sigma
Authors: Yurt Hakan , Brouse Peggy
Published: November 2014

Many software projects continue to be over budget, over schedule, and fail despite the tools created for managing the life cycle and the continuous improvement efforts. A great number of the problems in systems development projects is caused by poor requirements management processes.

The failure to understand the reasons behind the low quality requirements, to understand the relationship between the quality of requirements and requirements engineering process, and to take no actions for increasing the quality of requirements by eliminating the causes behind those effects result in increased cost, low reliability and maintainability, and a system that does not meet the stakeholders' requirements.

The aim of this research, the Requirements Engineering Process Design for Six Sigma (REDFSS), is to improve the quality of requirements using Six Sigma methodology along with a set of metrics and tools to identify the low quality requirements and offer corrective actions to overcome the quality issues and identify and eliminate the causes for defects and help requirements engineers to make better judgments.
8.1.1 The Factors that Lead to Unidentified Risks in Software‐intensive Projects
Authors: Yuval Efrat , Kuflik Tsvi , Tahan Meir
Published: November 2014

Development and deployment programs continue to suffer from budget overruns, schedule delays and poor technical performance. In most cases, this is a result of failure in handling uncertainty in complex software system development. The development communities lack a systematic way of identifying, communicating, and resolving technical uncertainty.

In this paper we focused on the risk identification stage and try to understand the reasons for unidentified risk appearing during project development. We interviewed project managers from industry. The findings suggest that the unidentified risk factors can be divided into three main types: Managerial, Behavioural and External. Each category consists of factors that through awareness and openness on the part of project teams and managers can help avert many problems and achieve project success.
8.1.2 Principles of Systems Engineering Management: Reflections from 45 years of spacecraft technology research and development at the Mullard Space Science Laboratory
Authors: Emes* M. R. , Smith A. , James A. M. , Whyndham M. W. , Leal R. , Jackson S. C.
Published: November 2014

Based on 45 years of experience conducting research and development into spacecraft instrumentation and 13 years' experience teaching Systems Engineering in a range of industries, the Mullard Space Science Laboratory at University College London (UCL) has identified a set of guiding principles that have been invaluable in delivering successful projects in the most demanding of environments. The five principles are: ‘principles govern process’, ‘seek alternative systems perspectives’, ‘understand the enterprise context’, ‘integrate systems engineering and project management’, and ‘invest in the early stages of projects’. A common thread behind the principles is a desire to foster the ability to anticipate and respond to a changing environment with a constant focus on achieving long‐term value for the enterprise. These principles are applied in space projects and have been spun‐out to non‐space projects (primarily through UCL's Centre for Systems Engineering). They are also embedded in UCL's extensive teaching and professional training programme.
8.2.1 Enterprise Systems Engineering ‐ Practical Challenges and Emerging Solutions
Authors: Brook Peter , Riley Tom
Published: November 2014

Much attention has been given over the last 10–20 years to the development of mature practices for engineering complex systems, and these are now largely in place in many large organisations and companies, underpinned by professional bodies such as INCOSE and an increasing number of university departments. Moving the practice of systems engineering into wider fields remains problematic, with many false starts ‐ and even backward steps. While much has been written about Enterprise Systems Engineering – and the allied subject of Systems of Systems – making the transition from theory to practice has proved tortuous and complex, requiring attention to re‐engineering the organisation as well as the projects it undertakes. This paper draws on the authors' combined experience ‐ gained from working across a range of organisations, both inside and outside defence – and discusses emerging strategies for coping with the challenges of joined‐up projects and programmes. The paper finishes in a more speculative vein with some thoughts on how the practice of ESE might evolve.
9.1.1 Systems Engineering and Project Management Intersects and Confusion
Authors: Arnold Eileen P.
Published: November 2014

Commonalities, differences, and confusion between the top level Systems Engineering, Systems Engineering Manager, and the Project/Program Manager views are explored based on the International Council on Systems Engineering (INCOSE) and Project Management Institute (PMI) process basis for Systems Engineering and Project Management certifications with an undercurrent of four initial factors that are observed to cause conflicts and confusion between the disciplines in the real world. The certification sources, the INCOSE Systems Engineering Handbook (SEHBK) which is aligned with ISO/IEC 15288, and the PMI Body of Knowledge (PMBoK), are the certification sources that guide Systems Engineers and Project Managers in their quest for credentials and on‐the‐job influence. These intersects are expected to work in concert, yet in real life, the interaction often results in mismatched expectations and confusion as to who has the responsibility for each process/knowledge area, in part due to mismatched certification bases. Recommendations are provided for initial alignment of the disciplines.
9.1.2 Antipatterns in Systems Engineering: An Opening Trio
Authors: Neill Colin J.
Published: November 2014

Patterns provide a way for experts to document the lessons of their experience in such a way that novices can apply those lessons in new situations, and thus avoid costly errors. Furthermore, pattern languages provide a terse form of communicating complex situations and their solutions. While patterns are undoubtedly useful, learning what not to do in recurring situations is equally valuable, if not more so. Patterns that document the painful experience of negative consequences to familiar solutions are called antipatterns. In this paper three antipatterns relevant to systems engineering are introduced: Work‐Breakdown Architectures refers to the phenomenon of project management artifacts influencing engineering decisions; Planning with Gantt Regard explores the nuances of project management techniques when applied to complex engineering; and Dogmatic About Dysfunction explains the cultural inertia that can inhibit progress. No claim is made that these are the only antipatterns found in the application of systems engineering, rather that, as the title suggests, they might provide the inspiration and impetus for documentation and identification of a robust catalog.