bluuebunny/crossref_metadata_2025 huggingface dataset:
8.2.0 I know what I want! Supply Chain Views on Delivering Requirements
Authors: Elphick Jon , McPharlin Tom , Verhoeven Nout H. , Birkelbach Ronald L. , Gharatya Kuldeep
Published: November 2014

This panel will examine whether it is practical or desirable to have a common approach to requirements management across the supply chain. Using the rail supply chain as the example, it will explore the different drivers, including:

How railway operators/agencies can minimize integration risk and reduce supplier risk through the bidding and award process – particularly in an age of global competition, where translation of languages and cultural differences add to the challenge of requirement interpretation?

How systems suppliers balance responsiveness to ‘unique’ sets of project requirements with their goal to standardize product development/product offerings?

What challenges both clients and suppliers face when seeking consensus on when system acceptance is attained? How do the perspectives on conducting systems verification & validation differ? How to overcome the reluctance of user stakeholders to transfer the system to operational service? This panel will bring representation from both clients (operators/agencies) and suppliers to compare and contrast approaches to requirements engineering – from developing concepts/eliciting user needs, managing requirements, verification & validation to system acceptance/turnover.

Panelists will highlight changes in practices intended to improve interactions between clients and suppliers and particularly note areas that would benefit from further improvement. The panel will also look at the role Systems Engineers must play across the supply chain at various stages of the lifecycle. As well as comparing different practices and drivers in the transportation sector, this panel and the discussion it seeks to stimulate will provide a more general insight into the differences between client and supplier side approaches to systems engineering.

The panel will provide an introduction to the different approaches to requirements engineering in a non‐traditional sector, including requirements development, management, verification and validation. It also seeks to elicit insight into contrasting SE perspectives of clients/owners and suppliers and whether optimization can be achieved where the supply chain members must share varied roles and functions to apply SE across the entire requirements lifecycle.

Come and joint us to debate and explore the dynamics within this sector's supply chain and how its approaches to requirements management compare or contrast with other sectors – where does best practice reside? What can be exchanged?
8.4.0 Student Division Program Panel Discussion
Authors: Mason David , Haskins Cecilia , Smith Eric , Luster Eric , Willard Tom , Walker John
Published: November 2014

The Student Division within INCOSE was reignited at the 2010 IW with Dave Mason from the San Francisco Bay Area Chapter being appointed to lead the effort. During the past year interest has increased at all stakeholder levels. The Student Division Program panel discussions will address the Value Propositions from each of the 4‐Way Benefit Model stakeholders perspective, and how these are used as success metrics for each student Division. This panel discussion will be followed by the brief introduction of the INCOSE 2011 International Science and Engineering Fair (ISEF) winner.
9.5.0 ABET Accreditation of SE programs: How is it going and why are we doing it?
Authors: Olwell David , Brown Phil , Ryan Julie , Farr John , Sutton Steve , Adcock Rick
Published: November 2014

INCOSE has become one of the professional societies overseeing ABET accreditation for systems engineering. This session present an overview of INCOSE's accreditation strategy, perspectives from recent evaluators of an undergraduate and a graduate program, an international perspective, a summary of why one major school has decided not to accredit its program, and a summary of why another did attempt accreditation. A floor discussion will follow.
9.6.1 Normative Approach to Six Sigma Project Selection
Authors: Kindi Mahmood Al
Published: November 2014

— This paper introduces the notion of expected utility and how to implement it in Six Sigma. Moreover, it intends to bridge the gap between process variation and the economic impact in order to have a clear view of economical consequences. It is agreed that the key for the success of any manufacturing firm is to select the most profitable project. There is a significant awareness in the Six Sigma community of the need for a tool that incorporates uncertainties, is data driven, and takes into account all financial aspects. Having an outstanding process quality is not necessarily an economical objective.
10.1.1 Software Systems Analysis Using Stress‐Strength Probability Functions
Authors: Wilder James O.
Published: November 2014

The potential variability of external inputs and their possible “drift” outside the software design boundaries is a common cause of failure in real‐time mission software. Critical interactions increase as the complexities and breadth of the interacting software systems increases. In system‐of‐systems interactions, the possible combinations of critical interactions can be very large. A software fault in one module of a system may coincide with a fault of an entirely different module within the same system, or another subsystem, to produce unsafe conditions or even system failure. Unforeseeable combinations can cause cascading failures within the system. When such systems have availability or safety requirements that are defined in terms of probabilities over time, these requirements must be applied at the top‐level of the system to characterize overall systemic performance. The requirement could be stipulated as a probability that the system does not encounter failure during the mission. This paper introduces the concept of analyzing critical system interactions in terms of both the operational profile of the system as a stressing function, and the strength of the system, a function of software complexity. The stressing and strength probability distribution functions are analyzed for interferences. In cases where variates within the stressing probability density function exceed variates within the composite system strength density function, the system will be prone to failure during operations. The region of interference between the stressing and strength distributions is itself a probability distribution function, which enables the statistical assessments of large scale system of systems, similar to the stress – strength analysis of reliability theory.
10.2.2 Using Boolean Operators in Multiple‐Domain Matrices
Authors: Maurer Maik , GmbH Martin Strattner Teseon
Published: November 2014

Matrices are a popular method for modeling systems in complexity management. They support the accurate structural acquisition of information, and guarantee a machine readable state of data. However, with today's matrix representations, Boolean operators cannot be intuitively depicted without simplifying the system.

In this paper, we present a new approach for modeling Boolean operators (AND, OR, XOR) in matrices. Boolean operators induce conditions between more than two nodes. Wherever a determination of a combination of nodes or edges is necessary, we place any of these paths in separate, superimposed matrices. The creation of instances of nodes in these superimposed matrices permits their belonging to different paths. For a better handling, this multidimensional matrix is flattened and the instances of nodes are placed side by side. In addition, we merge operators with their predecessor or successor‐node, for a size‐reduction and simplification of the matrix.
10.3.1 Applying the Plan‐Do‐Check‐Act Cycle to Develop Best Practices in Remote Online Systems Engineering Education
Authors: Squires Alice , Cloutier Robert
Published: November 2014

Systems engineering educators are inherently challenged to provide effective education to industry and government practitioners. Separating instructors and students by time and location, as is the case in remote online education, compounds the challenge. This paper summarizes research on the impact of the use of various pedagogical approaches on the effectiveness of teaching systems engineering in a remote online environment. Using that research as a leverage point, the Plan‐Do‐Check‐Act (PDCA) cycle is presented as a viable process for developing best practices for remote online systems engineering education.
10.3.2 The Development of an Architecture Framework for Systems Engineering Process Simulators
Authors: Ferreira Susan , Faezipour Misagh
Published: November 2014

Systems engineering process simulators can help users to explore risks and evaluate the consequences of various project, process, and organization decisions. These types of simulators can incorporate the complex system dynamics associated with various concerns and include critical factors, their associated relationships, and corresponding effects, allowing one to reason and explore various decision options. Simulators can also help educate current and new engineers to understand the multi‐faceted issues related to systems engineering projects and processes. In support of the development of these types of simulators, this paper discusses the need for an architecture framework for systems engineering simulators. An architecture framework is proposed as an enabler to assist in the development of systems engineering process simulators.
11.1.3 Identifying the Most Critical Documents and Reviews for Small Information Technology Projects
Authors: Mulhearn Michael , Brouse Peggy
Published: November 2014

Managing Information Technology projects has historically been a very difficult endeavor. For the project manager, there are many project management (PM), systems engineering (SE), and information technology (IT) standards, bodies of knowledge, process models, and management models to use to help manage a project. The wealth of information makes it difficult for project managers and systems engineers of small IT projects to filter through the information and determine the specific documents and reviews that are the most useful to effectively and efficiently manage the project. The goal of this research is to identify the documents and reviews that are most helpful for managing small IT projects.
11.3.2 The Three Ts of Systems Engineering – Trading, Tailoring, and Thinking
Authors: Beasley Richard , Partridge Richard
Published: November 2014

Defining what it is about Systems Engineering that makes it distinct from “normal” Engineering is one of the major challenges when making Systems Engineering explicit in an engineering company. This paper presents a view of Systems Engineering that emphasizes how the underpinning Systems Thinking enables Systems Engineering to ensure that the analytical thinking of normal engineering is used to the best advantage. This involves recognizing that trading is a natural part of the solution generation process. Trading is illustrated by an example from Rolls‐Royce's Naval Marine activities. The definition of Systems Engineering role within Rolls‐Royce is described as an example of tailoring. Systems Thinking should not only be used to understand the problem for which an “Engineered” solution (or system) is required, but also to understand the way the problem may be solved and the organization and roles needed to create the solution.
11.3.3 Behavioral Models and Improved Quality in Architecture‐Centric Engineering
Authors: Brouse Peggy , Jacobson Christopher P.
Published: November 2014

Architecture‐Centric Engineering (ACE) is described by the authors in 'Achieving Interoperability for Critical IT and Communication Systems' (Desourdis, et al, 2009) as an engineering approach that derives requirements and performance targets from enterprise scenarios. As part of this approach, this paper summarizes the use of behavioral models for improved quality as a repeatable, integrated component of systems engineering. Predictable quality measurement is possible at transitions earlier in the engineering lifecycle. Case Study, behavior model analytics and summaries from expert peer reviews are presented to support this quality improvement. An approach for the integration of behavior modeling methods as a quality mechanism extension is summarized.
Modeling with SysML
Authors: Friedenthal Sanford , Wolfrom Joseph A.
Published: November 2014

The OMG Systems Modeling Language (OMG SysML™) is a general‐purpose, graphical, modeling language for specifying, analyzing, designing, and verifying complex systems that may include hardware, software, information, personnel, procedures, and facilities. In particular, it provides graphical representations with a semantic foundation for modeling system requirements, behavior, structure, and parametric equations that can integrate with a broad range of engineering analysis. SysML represents a subset of UML 2.0 with extensions to satisfy the requirements of the UML™ for Systems Engineering RFP. The OMG SysML™ Specification was adopted in May 2006. For more information on SysML, including articles, tool vendor and related links, and the specification, go to http://www.omgsysml.org/.

This tutorial provides an introduction to how SysML can address your systems engineering needs, including: background and motivation, an overview of the SysML diagram types and language concepts, a demonstration of how the language can be used throughout a Model‐based Systems Engineering (MBSE) process. A class exercise is included to help solidify the student's understanding of the language. The course will also include a brief introduction to a typical SysML tool.

Attendees should gain appreciation of the value of model‐based Systems Engineering versus legacy, document‐centric methods; awareness of the graphical notation; and a high level understanding of when and how a Systems Engineer can exploit the various diagrams and models as part of their systems engineering process.
A Simple Prescription For Requirements Success
Authors: Grady Jeffrey O.
Published: November 2014

In the development of systems and entities thereof it is extremely important as a prerequisite to design to know clearly what is needed, what are the essential characteristics that the design must have. We system engineers call these requirements and we prepare specifications for each entity in a system and for the whole system containing in each case all of the essential characteristics the design must possess. There are few enterprises and programs within them that are applying an effective requirements analysis approach but it is not all that difficult to do so. There are a few simple activities that can be combined to form a prescription for success. We should possess a preferred template for each kind of specification we will have to develop. We should model the program problem space and derive the requirements from model artifacts. Each paragraph of a specification should be linked to a model and a discipline provided by a particular engineering department of the developing enterprise such that on a program people from that department will apply that model to derive requirements that fall into that paragraph of program specifications. The model applied on all programs should be the same and it should be a comprehensive model meaning it is effective no matter how the design will be implemented in hardware, software, or people doing things. The modeling artifacts should be captured, reported, and configuration control applied to them. Finally, a program should establish and maintain traceability between the modeling artifacts and specification content using a requirements analysis sheet.

This paper covers three comprehensive models, one of which an enterprise should select and apply on all programs. The paper also shows a preferred specification template and how to arrange traceability between the specification paragraphing structure, the modeling artifacts, and engineering department structure. In order to take advantage of this simple prescription an enterprise does have to apply effective management to initiate and continue movement from the present to a condition of success.
Requirements Engineering for Large Scale Systems: Contract Based Systems
Authors: Berenbach Brian , Worl John
Published: November 2014

Requirements elicitation and management for contract based projects is significantly more complex than for product or product line development. For example, many practitioners are unaware of the fact that the traditional “V” model for requirements tracing does not work where there is a legal contract describing project deliverables; nearly every aspect of requirements engineering is more challenging, from elicitation to risk analysis and compliance management. This half‐day tutorial will describe in some detail contract issues that are typically not discussed in requirements texts and courses.
Correlating Product and Process Measures as a Model for Systems Engineering Measurement
Authors: Carson Ronald S.
Published: November 2014

Current measurement industry emphasis on process measures and compliance ignores elements of the history of measurement. The failure to establish product measures and provably correlate them with process measures leads to open‐loop management systems that can only measure process compliance, with unknown effect on product quality. The new INCOSE Measurement Primer attempts to begin addressing this important distinction. In this paper a set of standard categories of measures are applied to various Systems Engineering work products identified as “output” in the INCOSE SE Handbook. Process and product measures for each process output are proposed, along with correlations between them, and associations to the INCOSE SE Leading Indicators where applicable.
Examining Survivability of Systems of Systems
Authors: Mekdeci Brian , Ross Adam M. , Rhodes Donna H. , Hastings Daniel E.
Published: November 2014

Previous research has identified design principles that enable survivability for systems, but it is unclear if these principles are appropriate and sufficient for systems of systems as well. This paper presents a preliminary examination of how some of the characteristic properties of systems of systems may enable or hinder survivability, based on existing design principles and a newly proposed taxonomy of disturbances. Two new design principles, defensive posture and adaptation, are introduced. The next phase of research will be to conduct empirical studies to validate the design principles against some of the characteristic properties of systems of systems, and test hypotheses about how survivability will be affected.
Enabling the Net‐Centric Systems Model through Adapting Enterprise Security Services to the Mobile Users
Authors: Farroha Bassam S. , Farroha Deborah L.
Published: November 2014

1.0 ABSTRACT

This paper investigates the requirements, technologies and risk mitigation techniques for securely sharing information with the tactical Mobile users while protecting the data and the information systems from intruders and malware. The systems engineering concepts applied to the design and development of the Enterprise need to include the security criteria and mitigating techniques to handle Mobility, and reliance on Cloud services to obtain the required data and services. A strong emphasis is placed on analyzing secure data sharing outside its security domain with services, agencies, coalition partners and state/local authorities. There has been an increased demand for multiple levels of secretive data at the tactical edge; however the threat level at that point has been increasing dramatically compared to the enterprise environment. The next generation information systems need to eliminate the stovepipe architectures and open the doors to share information across traditional and non‐traditional domain boundaries, while dealing with the increased threats stemming from wireless attacks, virtualized resources, and limited investment. This leads the sponsoring organization to think in terms of System of Systems when developing independent capabilities that needs to operate as consumers or producers with other systems. Agility in development is also paramount in today's budget sensitive and fluid requirements environments.
1.2.2 SE in a Cloud: Retiree Knowledge Capture and Consumption Optimization
Authors: Shelby Kenneth R. , Sarkani Shahram , Mazzuchi Thomas A.
Published: November 2014

Systems Engineers have a grand opportunity to leverage the Cloud for its collaborative environment capabilities where they can advance their Systems Engineering acumen, effectively articulate knowledge they possess about innovations or insights into existing systems, and effect knowledge transfer before retirement. This paper shares suggestions for authors, who possess good and valuable engineering knowledge, to prepare knowledge assets that are more easily consumed by other Systems Engineers, Specialty Engineers involved in the design, development and build of systems, and other stakeholders like funding source representatives, leadership, customers and end users. A proper balance of illustrations/diagrams/pictures with textual/verbal representations, following the dual‐coding theory, in an interactive Cloud collaborative environment with user‐subjective approaches enabled, will improve knowledge mobilization in the audience. The communication transfer function with human‐in‐the‐loop systems, like retiree knowledge transfer systems, benefit from knowledge capture and consumption optimization. This results in systems that are easier use and therefore are more likely to be used and create value.
1.6.3 What Makes Motif Patterns of Engineering Systems Architectures to Look Alike?
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). We now explain the reasons for the resemblance of these motif profiles of system architectures within various engineering systems families. We explain this by considering a vast variety of system architectures (38 systems architectures arbitrarily chosen) ranging from –electronic circuits, software systems and mechanical engineering systems.
2.2.2 A Decision Support Framework for the Software Systems Engineer
Authors: Knapper Robert J. , Brouse Peggy S.
Published: November 2014

Decision Support Systems have been developed to aid the decision maker by providing ranked alternatives to consider. The ranking criteria may be resource‐based, schedule‐based or performance‐based. When considering decisions that affect the overall architecture of a software system and the integration of its subsystems/components, the software systems engineer may have some unique challenges when legacy software is part of the system. For the software systems engineer, reengineering legacy systems or integrating legacy systems with new development and/or off‐the‐shelf software are areas where effective software system analysis is critical. When analyzing a software system, a range of system artifacts may be used. These artifacts include a description of the system in natural language, program design language descriptions, flow charts, object diagrams, as well as the system code. All of these artifact types can contain equivalent information at their specific level of abstraction. However, deriving information that is needed from each of these types of artifacts for reengineering or integrating a legacy system may present varying levels of difficulty. For example, analyzing a poorly structured system with little or no design documentation is a particularly challenging problem. Software modelling using an abstract architecture representation as a common description vehicle can “level the playing field” by creating representations of disparate systems at the same level of abstraction. This is of importance to reengineering efforts; it shows promise for supporting and facilitating integration efforts between legacy and other systems. It also allows the definition and development of a framework for a decision support system to aid the software system engineer. This paper is a follow on to previous work by the authors and presents a proposed decision support system framework that makes the use of the technical analyses and techniques presented.
3.6.1 Rapid prototyping and validation of Human factors model in a Model Based Naval Systems Engineering Application
Authors: Gopinathan H. , Tocci A. , Ciambra F. , Frisoni D.
Published: November 2014

The Model Based System Engineering (MBSE) approach focuses on building an architecture model which is portable to different platforms, re‐usable and interoperable among different domain models. This allows integrating the Human Machine Interface (HMI) model or the Human Factors domain model with the System architecture model seamlessly.

MBSE ensures the separation of user specifications from the way the system utilises the capabilities/technologies of the target application platform. Thus a Platform Independent Model (PIM) of the HMI is developed, mapping the end‐user/operator specifications. This model is then transformed to Platform Specific Model (PSM) meeting the requirements/technologies of the specific platform using rapid prototyping.

This paper discusses the generation of HMI Prototype from a PIM for a Naval Combat Management System (CMS) using the application codenamed ModVis. It also addresses the advantages of an early Verification and Validation (V&V) of the system model and visualisation of a preliminary prototype of the system early in the project life cycle.
6.5.1 A collaborative process based on systems engineering and mechatronics methods
Authors: Caron Françoise
Published: November 2014

The laws of physics bring into play geometric dimensions and directions. Consequently, systems engineering can in no way ignore the reciprocal effects of choices concerning the system's geometry and architecture on expected performance (electromagnetic phenomena, heat propagation and pressure loss, for example, are recurring issues in systems engineering projects).

Such challenges elicit the need to define which processes and methods would permit to concurrently design a system's architecture, its geometry, and the three‐dimensional layout of its constituent parts.

The purpose of this report is to present elements of an answer to this need. They were provided by a systems engineering methodology based on system architecture and three‐dimensional models as well as functional models. Based on modeling and simulation techniques, this methodology was developed and applied as part of the O2M research project sponsored by the competitiveness clusters System@tic and Moveo (two French agencies promoting applied research projects that bring together research laboratories, large industrial groups, and small and medium‐sized organizations).
7.2.2 An Introduction to Applying Systems Engineering to In‐Service Systems
Authors: Ven Marcel Van De , Talik Joe , Hulse Jon
Published: November 2014

There is emerging consensus within the Systems Engineering (SE) community that, while the principles underpinning SE remain the same across the lifecycle:

Some of the issues concerned with sustaining existing systems are more problematic than when realizing new systems; and

The existing SE Body of Knowledge and the competences of SE practitioners tend to focus on the issues that are more important when realizing new systems than on the issues that are more important when changing existing systems.

A UK working group on Applying SE to In‐Service Systems looked into difficulties in this area and produced a report containing draft guidance and recommendations for further action. These recommendations were recognized by INCOSE and consequently the International In‐Service Systems Working Group (“the ISSWG”) was set up in 2009 with the following objectives:

To consider the work of the UK Working Group and extend and adjust it as necessary in order to provide improved advice on the difficulties encountered in practice in applying authoritative guidance on SE, including the INCOSE SE Handbook, to systems which are in service and best current practice in adapting SE guidance to overcome these difficulties; and

To consider the current channels by which INCOSE promulgates advice on good SE practice, including the SE Handbook and the SE Book of Knowledge and make recommendations on how additional guidance on performing SE on in‐service systems should be integrated into these channels.
7.2.3 FasTracks Transit Program Oversight using Systems Engineering Principles
Authors: Stokes Timothy
Published: November 2014

The Regional Transportation District (RTD) FasTracks Program is a multi‐billion dollar transit expansion plan to build 122 miles of new commuter rail and Light Rail Transit (LRT) lines, and 18 miles of Bus Rapid Transit (BRT) in the Denver region.

RTD recognized that programmatic risk, inherent in the cost, schedule, and quality aspects of such a complex program, needed to be mitigated through a comprehensive Oversight Program. A systematic requirements based oversight approach was developed based on the principles of Systems Engineering to manage complexity. This Oversight Program is modeled on a Systems Engineering V‐framework.

Utilizing risk management to focus oversight efforts, requirements are verified by RTD's oversight staff throughout a project's life cycle. A web‐enabled database application is utilized to collect oversight data, which helps to ensure that requirements are verified at the system, subsystem, and component levels of the work breakdown structure. Useful information derived from the Oversight Program is fed‐back to program participants to enable continuous improvement of the program's management systems, thus reducing programmatic risk.

This paper discusses the application of RTD's tools and techniques used to oversee the FasTracks program and how Systems Engineering principles can be used to reduce programmatic risk for large transit programs.
7.4.3 Understanding Airlines' Value Perceptions for Value‐Based Requirements Engineering Of Commercial Aircraft
Authors: Zhang Xinwei , Auriol Guillaume , Eres Hakki , Baron Claude , Kossmann Mario
Published: November 2014

Although Systems Engineering (SE) processes and standards are widely used in aircraft development programs, traditional requirements engineering practice for commercial aircraft does not explicitly address value perceptions and related, relevant information. In this paper, a novel approach is proposed to promote a better understanding of customer value perceptions for value‐based requirements engineering. The approach is a four‐step process leading from initial customer statements to component value models. A set of theories and methods is introduced in order to resolve the different concerns regarding the appropriate understanding of customer value perceptions, and based on these, the establishment of the requirements. A case study is used that shows the transformation of airlines' initial expectation statements into a corresponding group value model, which supports the first two steps of the approach. The benefits of this approach are that perceived customer value can be explicitly qualified and quantified; and subsequently used reactively for design evaluation, and proactively for value‐driven design.
7.5.3 Common Sense – Uncommon Practice? Capability engineering examples from Rail and Defence
Authors: Kemp Duncan , Mollett Jennifer
Published: November 2014

Whilst there is a significant amount of information available on systems engineering of products, there is significantly less information available on how to systems engineer operational capabilities1.

In some respects this is surprising – it is the operational capability that the sponsor requires –whether it is the ability to move large numbers of people into and out of central London, or to establish and sustain a bridgehead in enemy held territory.

The paper describes an approach to developing operational capabilities. It describes how capability engineering can be viewed from several perspectives, including:

An enquiry based perspective describing the seven key questions that all capability engineering programmes need to address if they are to be successful

A structural perspective describing the relationship between purpose, operation concept, capability design and individual components of capability

A process perspective describing the activities that need to be undertaken from realising there is a capability gap through to demonstrating that the new/changed capability has improved the situation

The paper describes the interrelationships between the three perspectives, when to use them as part of Capability Engineering activities and why they are necessary and probably sufficient. The discussion topics in this paper are illustrated with two case studies from the Defence and Rail industries.

Finally the paper suggests that the effectiveness of using the different perspectives will vary with the maturity of the organisations' capability engineering. Where capability engineering maturity is low the enquiry based perspective will be most useful, where it is more defined the structural and process perspectives will be more effective.
9.4.1 Synergies between INCOSE SE Handbook, CMMI and DO‐178B
Authors: Monzon Antonio
Published: November 2014

One of the biggest challenges in multi‐normative organizations, in the field of industrial areas like aerospace and defense, is to make all technical regulations compatible. A huge amount of effort is spent by these organizations to maintain their accreditations periodically. Although each standard has its own purpose and appraisal procedure, it seems to be useful to know about the commonalities among norms, as well as extracting best practices from the application of its requirements to the accomplishment of the others. Particularly the INCOSE Systems Engineering Handbook can be considered as general lifecycle framework for systems, the Capability Maturity Model for Integration (CMMI) is a reference model to assess the process efficiency and RTCA DO‐178B can be used as basis for software certification. In literature very few contributions can be found to explain how these standards interrelate and how they can work together to achieve more efficient organizations. This experience paper aims to shed some light on the common aspects of these three standards applicable for the production of on‐board software. The combination proposal included in this paper is the result of the experience of the author in the application of these standards (and others) in the military avionics domain. Conclusions could be useful for their application to other domains or even for future potential combined accreditations.
10.2.1 A Framework to Institutionalize Systems Engineering Skill‐Set
Authors: Jahangir Ebad
Published: November 2014

Systems Engineering (SE) has been variously defined as an approach, discipline, process, practice, or similar other terms. Each of these terms presents issues especially when compared to other traditional engineering specializations. It is best to think of SE as a skill‐set that can be promoted among the engineering population in general but, more importantly, in a smaller group whose members lead multidisciplinary groups (e.g. chief engineers). A specific skill‐set is derived from INCOSE and NASA competency models using a design structure matrix type approach. This framework uses commonly understood terms in the industry to encourage adoption by a company's engineering leadership. It is recommended that large engineering companies encourage the SE skill‐set by including key SE experts in technical career ladders. The formation of an SE tools and methods group is also recommended that can drive and harmonize SE practice in all technical areas of a large engineering company.
10.3.2 Systems Engineering Lite
Authors: Kolozs James , Henderson Cody , Gardner John
Published: November 2014

An approach is presented (termed Systems Engineering Lite) in which systems engineering is adapted to address small to medium sized projects by combining the roles of project manager and systems engineer and by utilizing a simplified set of systems engineering tools. This approach brings the systems engineering benefits of managing complexity and increasing communication and understanding of the system to a wider range of companies, industries, and project sizes than is traditionally the domain of systems engineering. Our experience has been that this approach results in reduced project costs, happy customers, and more successful projects.
10.5.2 Three years of MBSE for a large scientific programme: Report from the Trenches of Telescope Modeling
Authors: Karban Robert , Zamparelli Michele , Bauvir Bertrand , Chiozzi Gianluca
Published: November 2014

The most ambitious projects of the European Southern Observatory's (ESO) is the construction of the European Extremely Large Telescope (E‐ELT) which will be by far the world's largest optical and near‐infrared telescope, and. will provide images 15 times sharper than those from the Hubble Space Telescope. Such a project poses continuous challenges to systems engineering due to its complexity in terms of requirements, operational modes, long operational lifetime, interfaces, and number of components. Since 2008 the Telescope Control System (TCS) team has adopted a number of Model Based Systems Engineering (MBSE) practices in order to cope with the various challenges ahead. This paper provides an overview of the different approaches we took during this time ‐ which ones worked, and which did not.
11.1.1 Agent‐Based Modeling for Smart Grid: Application to Consumer Reaction to Demand Response
Authors: Lewe Jung‐Ho , Miller Michael Z. , Kelly Kristin M.
Published: November 2014

The Smart Grid is a large‐scale endeavour to accommodate future electric power needs. It plans to deploy innovative technologies for higher level of system efficiency and sustainability. A solid understanding on multitude facets of this challenge is vital hence a system‐of‐systems perspective was adopted. The resulting model was created to capture dynamics between the supply and the demand aspects, underpinned by agent‐based modeling and simulation techniques. After defining the consumer agent and the environment that includes the external and internal factors with which the agent interacts, a baseline simulation run was performed to verify the correct interactions between the agents and their environment. A sample Demand Response scheme was implemented to demonstrate the model and the results were compared with the baseline at the individual agent and the aggregate levels. This model demonstrates the capability and the insights that systems engineering techniques, such as agent‐based modeling, can bring to Demand Response evaluation for a Smart Grid system.
11.4.3 Impact of Agile Process in Systems Engineering
Authors: Pamujula Suresh , Thoppay Rajesh , Kelly Kristin , Fish Rusty
Published: November 2014

This paper explores how Agile techniques can be adopted in the structured system engineering process in delivering System of Systems (SoS). In doing so, the impact of following Agile processes and how priorities are handled in a corporation that is more product centric and profit‐loss driven will be discussed. The paper addresses the lessons learned from the integrating various products that make the SoS. Effects on the overall delivery of the SoS will be discussed including factors like system‐level knowledge, tools, organization structure and global teams. Finally, the paper will highlight some the recommendations that would be applicable for program management in system engineering who want to adopt Agile based techniques for software development and overall delivery of SoS. This paper is intended to provide a case study for applying Agile processes in a SoS context in a commercial environment.
Agile Collaborative Systems Engineering ‐Motivation for a Novel Approach to Systems Engineering
Authors: Asan Emrah , Bilgen Semih
Published: November 2014

Well‐established systems engineering approaches are becoming more inadequate as today's systems are becoming more complex, more global, more software intensive, more COTS/re‐use based and more evolving. The changes in the organization and management of such systems of systems projects make it even more difficult for traditional systems engineering approaches. Increased level of outsourcing, significant amount of subcontractors, more integration than development, reduced project cycles, ecosystem like collaborative developments, software product lines and global development are some of the changes in the project life cycle approaches. In this paper, we gather and synthesize the current literature to highlight the need for an agile systems engineering approach and to characterize its agile properties in order to support our motivation for a novel systems engineering approach for large scale software intensive systems of systems projects.
Developing the Modeling Recommendation Matrix: Model‐Assisted Communication at Volvo Aero
Authors: Rypdal Rasmus Wibe , Muller Gerrit , Pennotti Michael
Published: November 2014

Volvo Aero Norway (VAN) is a manufacturing company specializing in the production of high precision aerospace components for both commercial and military jet engines. VAN has, as a high‐end production company, a highly diverse set of stakeholders in their employees, customers and suppliers. It is therefore a definite need for VAN to have personnel that can communicate efficiently between stakeholders to be able to complete projects and optimize production in order to sustain their competitive position.

Using systems modeling is a known technique to aid communication, raise understanding and create debate surrounding any given system of interest. By measuring the value, in regards to the aforementioned effects of modeling, of the work being performed at VAN we can discuss the usefulness of modeling‐based communication. We will examine the connection between a stakeholder's distance to a given system and the optimal level of modeling detail and novelty.

In this paper, we will discuss model effectiveness based on balancing impact factors based on stakeholder's system proximity. We will classify and evaluate models in a 2D‐Matrix and present recorded trends at VAN.
Estimation: A Paradigm Shift towards Dynamic Design‐to‐Cost and Radical Management
Authors: GILB TOM
Published: November 2014

Accurate estimation is impossible for complex technical projects, but keeping to agreed budgets, and deadlines is achievable by using feedback and change. In other words, rather than trying to improve the initial project estimates, the budgets and deadlines must be set, based on the value of delivery (not the cost), and then iterative re‐engineering of product and process must be used to stay within acceptable resource bounds. Or at least iteration must be used to get most of the expected value delivered, within the acceptable budgets and deadlines. This paper explains the background to this approach and discusses its use providing several examples.
Managing Concurrency in Systems Engineering
Authors: Scheithauer Dieter
Published: November 2014

The engineering of complex products and services cannot be performed without iterations. Products and services with a multi‐level system architecture and a reasonable number of system elements usually show development activities on individual system elements performed in parallel. The development of each system element is widely managed independently. This paper is concerned with managing concurrency resulting from both, the iterative nature of systems engineering per se, and the multiple projects for developing all the system elements.

Lean systems engineering is promising improvements to the systems engineering process in general. However, lean systems engineering is still evolving. Particularly, the integration with all other system life cycle processes needs to be progressed without compromising the lean paradigm. In this paper, amendments to the current state of lean systems engineering are proposed in order to close some of the gaps.
Systems thinking in the planning of military operations
Authors: Greeff A.P.
Published: November 2014

The execution of a Military operation has an analogy to a development project which has the objective to develop a complex product system (victory). This product Performance (victory) must be delivered within a certain time, cost and operational context. Vital to any successful development project is planning, and for complex development projects, good planning is imperative.

The result of a complex product development planning cycle, results usually in projects with tasks which resembles a systems life cycle approach. Similarly a complex military operation has the characteristics of delivering a product within time cost in an operational context. Just as a complex product is developed by means of a systems approach, planning could be performed by means of the application of systems thinking.
Using the Guide to the Systems Engineering Body of Knowledge (SEBoK version 0.5) for Undergraduate System Engineering Program Assessment
Authors: Parnell Gregory S. , McCarthy Daniel J. , Hardman Nicholas , Yale Gary E.
Published: November 2014

The draft of the Guide to the Systems Engineering Body of Knowledge (SEBoK version 0.5) was released in a wiki format on September 19, 2011. This paper uses SEBoK to assess the undergraduate systems engineering programs at the United States Military Academy at West Point and the United States Air Force Academy. Both ABET accredited engineering programs educate cadets in to be future leaders of character in their respective military services. We first review the rationale for undergraduate SE programs at the academies. Next, we compare the two programs including their program objectives, student outcomes, curricula, enrolments, and graduate assignments for each program. Then, we compare each of the SE programs to the SEBoK knowledge areas. We conclude with ideas on how undergraduate SE programs can use the SEBoK in planning and execution of their academic programs.
“PBS : a major enabler for Systems Engineering”
Authors: Tonnellier Edmond , Terrien Olivier
Published: November 2014

In 2012, Thales Systèmes Aéroportés initiated a study on the Product Breakdown Structure (PBS) as a central enabler for Systems Engineering. Obvious similarities between tree‐like representations used throughout the entire lifecycle of a Solution suggest in a simplistic and reductive way that breakdown structures are only an unnecessary redundancy due to complementary businesses designating the same reality in different ways. However, a more precise study of international standards and a more careful examination of stepped uses of these tree frames show how different their purposes are and how they support different features of the system being designed. Nevertheless a confusion exists between these tools. Thus our paper asks a question of principle: “does this confusion come from imprecise and unclear standards on this subject, from incorrect interpretations of these by system architects or from vague approximations in the use of technical tools that structure and size R&D projects?”.