bluuebunny/crossref_metadata_2025_split huggingface dataset:
11.4.1 An Experience Report at Thales Aerospace: “The Lean Journey”
Authors: Baujard Michel , Gilles Harry , Terrien Olivier 
Published: November 2014

AbstractThis experience report illustrates the implementation of ‘Value Streams’ in Systems Engineering and Product Development at Thales Aerospace. It explains how non‐added value elements are eliminated thanks to these value stream mappings.This paper is based on one of our real experiences. Therefore, it could be considered as a concrete example of Lean Principle 2 of Lean Enablers for Systems Engineering developed by the INCOSE Lean Working Group:This experience report describes an achieved example of value stream mapping and its positive impacts on Systems Engineering. It also offers an overview of this pragmatic methodology and the training courses for implementation. Current worldwide deployment status and achievements in terms of performances and customer satisfaction are also provided. Finally key success factors and upcoming steps are described to further improve the performance.
“have cross functional stakeholders work together to build the agreed value stream”
“use formal value stream mapping methods to identify and eliminate Systems Engineering and Product Development waste, and to tailor and scale tasks”.

imageThis experience report describes an achieved example of value stream mapping and its positive impacts on Systems Engineering. It also offers an overview of this pragmatic methodology and the training courses for implementation. Current worldwide deployment status and achievements in terms of performances and customer satisfaction are also provided. Finally key success factors and upcoming steps are described to further improve the performance.
Model‐Based Systems Engineering For Project Success: The Complete Process
Authors: Long James 
Published: November 2014

AbstractThis basic tutorial identifies the elements and benefits of a complete, proven model‐based system engineering process, and demonstrates its tailorability and value for project success using vignettes from an information management system and a sample System of Systems (SoS) application. The tutorial illustrates how the model‐based system engineering process supports both document‐driven and model‐based paradigms, whether in top‐down, middle‐out, or reverse engineering environments. It discusses how to know when each element of the process has been completed, and how to develop and validate functional and physical architectures using executable architectures. The requirement for concurrent engineering, the onion model, and synchronization of models and data are presented.The participants will be introduced to a flexible system engineering process suitable for system development tasks across the complexity spectrum. In addition to the process description, the tutorial will include a sample solution to illustrate the recommended techniques, views, completion conditions, and products of an MBSE system development methodology. It will also include examples of the development of graphical views commonly used by practitioners of DoDAF and SysML approaches.This tutorial is focused on highlighting how the use of model‐based systems engineering can meet the government requirements for delivering architecture framework products while allowing the engineering organizations (industry and government) to successfully perform the systems engineering required to develop an executable design.
Architecting the Enterprise: Using a Standards Approach
Authors: Martin Richard A. 
Published: November 2014

AbstractEnterprise architecture has taken on many meanings as practitioners and scholars attempt to understand and apply the principles of design and construction necessary for today's highly complicated enterprise scale systems.This tutorial presents an overview of enterprise architecture concerns and then uses International Standards as a means to frame the disparate approaches relative to those concerns, offers some insight into the relationships among approaches that result from applying the standards, and identifies opportunities for an innovative architecting discipline to facilitate sustainable enterprise operation. International communities for Information technology (ISO JTC1) and Automation systems and integration (ISO TC184) have produced International Standards with requirements related to enterprise architecture. These methodology independent International Standards provide a means to assess methodological approaches and offer guidance for the creation and articulation of enterprise architecture. INCOSE, as a liaison partner, has been instrumental in assuring that systems engineering remains an essential contributor to these efforts.
Requirements Engineering for Large and Very Large Scale Systems Part I ‐ Processes and Tooling
Authors: Berenbach Brian , Cleland‐Huang Jane 
Published: November 2014

AbstractRequirements engineering processes in the large are very different from those on small to medium size systems. Most texts on requirements engineering, for example tend to describe small or medium scale systems (up to about 5K requirements), or if the systems are large, describe the processes associated with product development and product lines. Industrial projects, however, start at 20K requirements and up. The creation of scalable processes that will support a large infrastructure project of the kind we are reading about in the headlines today (e.g. “shovel ready”) can be a daunting prospect. This tutorial will present some of the challenges associated with the requirements engineering of such large and very large projects, and describe how to setup processes and tooling to support such projects.This is part one of a two part tutorial. The morning session describes how to set up processes and tooling for very large industrial projects, typically dealing with 50 thousand or more requirements. The afternoon session describes the unique nature of requirements engineering processes for contract based projects. Either session may be taken independently, but the attendee will get the most out of the tutorial by attending both sessions.
Systems and Software Architecting: A Unified Approach
Authors: Eisner Howard 
Published: November 2014

AbstractFormulating a sound architecture has become one of the most important elements in systems engineering, software engineering and systems integration. Significant work has been done in the architecting of systems and, mostly as a separate matter, the architecting of software. This paper focuses upon the issue of a unified approach to both systems and software architecting. A specific procedure for a unified method is suggested and illustrated.
Requirements Engineering in the bio medical industry: GAMP 5 and tooling
Authors: Fanmuy Gauthier , Szczepaniak Richard 
Published: November 2014

AbstractThe principles of systems engineering are applicable to all types of systems including computerized systems. They are particularly effective for these systems because the computer is still new technology, they can better understand the development and life cycle of these systems by erasing the image of “black boxes”. It is now essential for computer systems to carry more and more critical actions especially in highly regulated industries such as pharmaceuticals or medical devices industries. These industries has established a repository, the GAMP (see reference [1]), in order to define the correct principles to be established for computerized systems. This paper presents the principles of systems engineering defined in GAMP and how they were developed by the company ADN and CORTIM for the pharmaceutical and medical devices industries.
1.4.1 Practical SysML Applications: A Method to Describe the Problem Space
Authors: Lempia David , Jorgensen Ray 
Published: November 2014

AbstractCustomers are looking for solutions to problems that they are having. The problem description methodology starts with the group of customers called the stakeholders and ends with a set of functions that need to be implemented to satisfy the needs of each of the stakeholders. Building the wrong feature or building features that are not used are costly forms of waste in engineering development. Likewise, building exactly what the customer wants and delivering the most valuable functions early is the key to project success. There are a number of SysML and UML methodologies published. These methodologies generally lead the engineer from requirements to analysis to structural design and back to behaviors. Because of the methodology, it is easy to mix the solution ideas in with the problem definition. Adding solution ideas too early constrains the possible solutions that can be utilized when the set of problems is investigated. Also, these existing methodologies yield poor traceability and throw‐away diagrams. This problem description methodology describes a logical evolution of thought, a reduced simplified set of diagrams, traceable requirements, and diagrams that easily evolve into implementation or test.
1.4.2 What Is the Smallest Model of a System?
Authors: Schindel William D. 
Published: November 2014

AbstractHow werepresentsystems is fundamental to the history of mathematics, science, and engineering. Model‐based engineering methods shift thenatureof representation of systems from historical prose forms to explicit data structures more directly comparable to those of science and mathematics. However, using models does not guaranteesimplerrepresentation–indeed a typical fear voiced about models is that they may be too complex.Minimalityof system representations is of both theoretical and practical interest. The mathematical and scientific interest is that the size of a system's “minimal representation” is one definition of its complexity. The practical engineering interest is that the size and redundancy of engineering specifications challenge the effectiveness of systems engineering processes. INCOSE thought leaders have asked how systems work can be made 10:1 simpler to attract a 10:1 larger global community of practitioners. And so, we ask: What is the smallest model of a system?
3.2.1 A Study of Systems Engineering Effectiveness: Building a Business Case for SE
Authors: Elm Joseph P. 
Published: November 2014

AbstractUnderstanding the value of Systems Engineering (SE) is necessary to justify a project's investment in SE resources and activities. To identify the value of SE, the Systems Engineering Effectiveness Committee (SEEC) of the National Defense Industrial Association (NDIA), in collaboration with the Software Engineering Institute (SEI), developed and executed a survey of defense industrial contractors. The survey analyzed the relationships between the SE activities applied to individual projects, and performance of those projects. Results of this survey, published in 2007 and 2008[1], indicated strong relationships between many SE efforts applied early in the project and the overall success of the project. Today, NDIA, in collaboration with the Institute of Electrical and Electronics Engineers Aerospace and Electronic Systems Society (IEEE‐AESS) and SEI, is engaged in extending that study to build a stronger business case for the application of effective SE to product development projects.
4.6.1 A historical perspective of MBSE with a view to the future
Authors: Haskins Cecilia 
Published: November 2014

AbstractModel‐based engineering has been a topic of discussion for over twenty years; Model‐based systems engineering (MBSE) has been an INCOSE initiative since 2006. For the third international conference on MBSE held September 2010, the author researched the background of MBSE from a historical perspective to identify the emergent timeline and to recognize the work that has lead to the current situation. This perspective can be used to understand the barriers to adoption, the research that remains, and to establish a reasonable expectation of the path ahead for realizing the full potential of MBSE.
6.2.1 Complexity Types: From Science to Systems Engineering
Authors: Sheard Sarah A. , Mostashari Ali 
Published: November 2014

AbstractHow to measure complexity for systems engineering is currently receiving great attention, including such efforts as DARPA's META program. However, complexity is a highly varying concept with many different views. This paper discusses some of those varieties of meaning, types of complexities, and entities which may be measured for complexity (qualitatively or quantitatively). First discussed are attributes that make a system complex and difficulties in dealing with the system because of the complexity (i.e. complexity causes and effects). Next types of complexity are reviewed from previous work. Finally those types of complexity are applied to four types of systems engineering entity: a project building a technological system, that system itself, the environment into which the system will be inserted, and the cognitive load on humans involved in the system. Ongoing and future work is also described.
6.3.2 Capability Engineering – An Analysis of Perspectives
Authors: Henshaw Michael J de C. , Lister Peter , Harding Alan D , Kemp Duncan , Daw Andrew J , Farncombe Andrew , Touchin Malcolm 
Published: November 2014

AbstractThe terms ‘capability’ and ‘capability engineering’ are now widely used across industry and in government procurement, but it is clear that different communities use the terms with similar, but distinctly different meanings. Using a soft systems methodological approach, an INCOSE UK working group has identified eight perspectives of capability, which have been related to Ring's value cycle and the Hitchins' five layer model of systems engineering. It is asserted that capability is the ability to do something and that capability engineering is the overarching approach that links value, purpose, and solution of a systems problem. It is equivalent to layers 1–4 of Hitchins' Five Layer Model and is equivalent to an holistic perspective of systems engineering. There are significant practice and examples of capability engineering from (at least) the UK rail provision, defence, and Information Services and it is the view of the working group that further INCOSE guidance may be needed to ensure engineers are properly equipped to deal with capability and capability engineering.
6.6.1 Using MBSE with SysML Parametrics to Perform Requirements Analysis
Authors: Bijan Yvonne , Yu Junfang , Graves Henson , Stracener Jerrell , Woods Timothy 
Published: November 2014

AbstractRequirements are attributed as a common cause of failure in system development. Not only are text requirements ambiguous, the domain conditions under which they are to be satisfied are vague. Until operating conditions and requirements are formally captured, they will continue to be vague with ill‐defined verification criteria. SysML used in a Model‐Based Systems Engineering (MBSE) development process can enable mitigation of this primary source of error. By representing the system under design and its operating environment as a composite SysML model with parametric diagrams, requirements can be formalized in a precise manner. Formalization of requirements and constraints with parametric diagrams enables them to be verified and flowed down during the development process. An example will be used to illustrate how parametric diagrams can be used to develop requirements and constraints.
7.1.3 Architectural Patterns for Self‐Organizing Systems‐of‐Systems
Authors: Nichols Craig , Dove Rick 
Published: November 2014

AbstractContemporary threats exhibit unique characteristics that challenge classical security systems. In response to these threats, the DoD has an increased focus on applying proven SE techniques to SoS, which provide more functionality and performance than the sum of the constituent systems. Tools and techniques are necessary to facilitate evolution of today's systems. One major need is the ability to develop agile SoS architectures that respond to contemporary threats. This paper focuses on one characteristic of contemporary threats, self‐organization. Different SoS are reviewed for the driving forces that support their self‐organizing architecture. Necessary characteristics are identified and general constructs are put forward as candidate architectural patterns. These candidate patterns are now available for evaluation and employment consideration. They can be applied when problems common to the pattern manifest in new environments. They also add to the body of knowledge for SoS SE.
9.3.1 Adaptive Systems Engineering: A Medical Paradigm for Practicing Systems Engineering
Authors: Hamelin R. Douglas , Klingler Ron D. , Dieckmann Christopher 
Published: November 2014

AbstractFrom its inception in the defense and aerospace industries, SE has applied holistic, interdisciplinary tools and work‐process to improve the design and management of “large, complex engineering projects.” The traditional scope of engineering embraces the design, development, production, and operation of structural, hardware, and software systems, and SE, as originally conceived, falls within that scope.While this “traditional” view has expanded over the years to embrace wider, more holistic applications, much of the literature and training currently available is still directed almost entirely at addressing the large, complex, NASA, defense, and other industry systems wherein the “ideal” practice of SE provides the cradle‐to‐grave foundation for system development and deployment. Under such scenarios, systems engineers are generally viewed as an integral part of the system and project life‐cycle from conception to decommissioning. In smaller, less complex, and far less “ideal” applications, SE principles are equally if not more applicable to a growing number of systems and projects that need to be “rescued” from overwhelming challenges that threaten imminent failure.The medical profession provides a unique analogy for this latter concept and offers a useful paradigm for tailoring our “practice” of SE to address the unexpected dynamics of applying SE in the real world. In short, we can be much more effective as systems engineers as we change some of the paradigms under which we teach and “practice” SE.
Considerations for a Generalized Reuse Framework for System Development
Authors: Wang Gan , Rice Jeff 
Published: November 2014

AbstractReuse has been gaining ever increasing focus in all stages of the system development process as the prospects of leveraging prior investments to save costs, shorten delivery schedule, and possibly improve product quality are appealing to system developers. However, the concept of reuse at the system level is often poorly understood and the practice has not been effectively documented and practiced, particularly from the systems engineering point of view. This paper conceptualizes a generalized reuse framework for system development using an activity‐based modelling approach. It examines reuse from both the producer's and consumer's points of view and links the essential reuse activities for the production and consumption processes through reusable resources. A classification schema is proposed to evaluate reuse from the two perspectives, i.e., development with reuse and development for reuse. The interface between the two strategies is discussed and notional scenarios to apply this framework are also presented. The framework proposed lays down a foundation for quantitative evaluation of the effect of reuse in an on‐going effort assessing such an impact through parametric modelling.
1.4.2 Systems engineering education for confirmed engineers:experience feedback
Authors: Hammami Omar , Ruault Jean‐René 
Published: November 2014

AbstractSystem engineering evolution and adoption around the world have been unevenly supported by education programs. The current strong emergence of system engineering needs in several industries combined with inappropriate education support in the past resulted in strong demands for lilelong education programs. Most mid career engineers with very significant technical project experience in major french companies graduated in engineering programs with no education in system engineering beyond short trainings. Often, they have been exposed to system engineering processes through participation in large programs but only in a partial manner. This is typical of a general transition period inside companies with internal struggles on the exact role and scope of system engineering. In this paper we report the feedback of a system engineering program targeted to this audience.
1.6.2 Generic Approach for Systems Design Optimization in MBSE1
Authors: Broodney Henry , Dotan Dolev , Greenberg Lev , Masin Michael 
Published: November 2014

AbstractThe complexity of contemporary systems causes Systems Engineers great pains during early architectural design phases. Model‐Based Systems Engineering (MBSE) proposes methodologies to deal with complexity and streamline design processes, but the penetration of the new approach is slow. This paper proposes a generic SysML based methodology for improving the Architectural Design phase of Systems and mitigate the barriers for MBSE adoption. The proposed methodology suggests an alternative way to formalize requirements, define design alternatives, automate design space exploration and examine optimization results in the original modeling format. A representative example is provided. A glossary is included at the end of the paper.
2.1.2 A novel approach to Large System Performance Prediction via Markov analysis
Authors: Petrucci Roberto , Vigilante Domenico 
Published: November 2014

AbstractThis paper provides a preliminary answer to the rising needs for performance prediction in the Large System (LS) area. Specifically, it was required by the Selex‐SI OIL Camp Protection IPT, in order to support the Technical Proposal generation.LS performance prediction is a whole new field of interest, fuelled by its huge potential in the homeland security and homeland defense applications; a lot of research is being conducted by the main private companies and national agencies; however, a standard approach to assess the performance of a Large System has not been defined yet.The outcomes of our work have been the following: a technical report, describing the approach, the mathematics and some examples; an analysis tool, coded in matlab, supporting the numerical evaluations.
3.1.1 The Impact of IT on Product Architecture and Project Outcomes
Authors: Marion Tucker J. , Barczak Gloria , Meyer Marc H. , Brown Greg 
Published: November 2014

AbstractProduct Architecture and scalable product platforms are primary assets in leveraging R&D resources for continued firm growth. This study explores the impact of information technology (IT) on the development of robust, scalable architecture and their shared product platforms. Over the past twenty years, the implementation of information technology infrastructure and associated tools has transformed how firms approach new product development (NPD). IT solutions have migrated from a focus on detailed engineering design and associated production and launch (i.e. 3D computer‐aided ‐design (CAD) and product lifecycle management systems), to up‐front activities like architecture planning and development. Given the expanding role of IT and digital design tools further up‐front in the NPD process, we investigate their impact on developing robust product architecture. Through an empirical study of 122 firms and follow‐up interviews, we study the impact of IT (ie. digital design tools, IT infrastructure, IT embeddedness) and team collaboration on the efficiency and effectiveness of product architecture and overall project outcomes. The results indicate that a firm's IT infrastructure and team collaboration have strong, significant relationships with the development of an efficient and effective product architecture. The findings also show a strong, positive relationship between product architecture and project outcomes. Specifically, efficient and effective product architecture results in meeting project performance goals.