bluuebunny/crossref_metadata_2025 huggingface dataset:
10.2.3 Guidance on Tailoring of Systems Engineering Processes for Quick Reaction Capability (QRC) Developments
Authors: Richstein Alan B. , Nolte Jerome T.
Published: November 2014

Although the very basis for establishment of the discipline of systems engineering is grounded in development of large, complex systems, the principles and processes are also extremely valuable for other types of systems. As discussed in (INCOSE Handbook 2004) the responsibilities of systems engineers, that include “requirements analysis, functional analysis and allocation, architecture/design, systems analysis and control, and verification and validation of the system”, while “most apparent on large, complex systems … are also important in the development, production, deployment, and support of much smaller systems.”

A Quick Reaction Capability (QRC), the focus of this paper, is a type of system development characterized by deployment of a critical capability to satisfy an urgent need in which the normal acquisition process is accelerated. That is, the driving requirement is the timely delivery of the system to operations. In this paper, we provide guidance on tailoring the CMMI processes for QRC developments to achieve mission success while satisfying the shortened development schedule. We assert that identifying and implementing the right SE processes is of even greater value for conducting a QRC development, precisely because time is such an important consideration.
10.3.1 The Producing System
Authors: Paul Arthur S. , Yerace Gary A.
Published: November 2014

This paper discusses the importance of the enabling resources (otherwise identified as enabling capacity or enabling capabilities) to the successful development of systems. It proposes the Producing System as a mechanism for planning, acquiring, deploying and managing these enabling resources as a system of interest, in addition to the delivered or required system, in the system development process.
11.1.2 A case study of multi‐disciplinary modeling using MATLAB / Simulink and TrueTime1
Authors: van den Bosch P.F.A. , van de Waal E.H.
Published: November 2014

A big challenge in the development of complex machines is to evaluate the effects of early design decisions. This is because of 1) the multi‐disciplinary nature of such systems, and 2) the complexity of these machines. In this paper, it is demonstrated that it is possible to model essential system artifacts like timing and power usage for a complex machine, and obtain simulation results that can predict system behavior.

As a case study, a model of the paper flow in a modern high‐volume printer / copier is made. This model focuses on timing and electrical power consumption. The model is validated using measurements on a real printer. It is shown that the model can be used to evaluate the impact of design decisions on the system.
11.1.3 The Nuts, Bolts and Duct Tape of Establishing a System Engineering Measurement Program
Authors: Frenz Paul J.
Published: November 2014

While Software Engineering has a long history of conducting a measurement program, System Engineering (SE) is still in its infancy, in relative terms, in providing comparable measurement program guidance. This paper traces the establishment and institutionalization of a System Engineering Measurement Program.
11.2.3 Developing Section 4 Verification Text: Getting Early Buy‐In from Industry & Government Stakeholders
Authors: Haskins Bill , Striegel Jack
Published: November 2014

Defining, designing & building a Large‐Scale Integration system is a daunting task. Even more daunting is proving that a system of that complexity meets the design requirements. The verification ‘proof process’ starts early on in a development program and the foundation is captured in the section 4 verification text, as defined in MIL‐STD‐961E, DoD Standard Practice, Defense and Program‐Unique Specification Format and Content. There have been numerous technical papers written to ensure that the section 3 requirements are verifiable, but few papers have been written to describe how to develop quality section 4 verification text. This paper describes a formal verification approach for developing quality section 4 verification text, with associated verification planning data, and getting early buy‐in from Industry and Government stakeholders in defining critical verification events, which is crucial to the success of any Large‐Scale Integration system.
1.2.2 Enhancing SE deployment in large organisations by proactively managing service quality of SE training and support services
Authors: Kossmann Mario
Published: November 2014

When implementing Systems Engineering (SE) in large organisations, one key success factor that is absolutely essential for the acceptance of the related changes by concerned employees is the availability of high quality training and support services. For many such employees that are meant to start applying SE in their daily work, the first and arguably most important impression is the one given in the corresponding training session. Also, once they have completed the training needed for their level of involvement, it is crucial that they find the necessary support to get started and keep on track.

The present paper will argue why it is worthwhile to proactively manage service quality when introducing SE in large organisations, give an overview of a proven Service Quality Management process for SE training and support services, illuminate the inherent advantages of such an approach and specifically look at a case study from Airbus, where the process in question has been used over a period of two years.
1.3.3 On the Alignment between System Architectures and Organizational Structures
Authors: Strandberg Tom , Burton Herb , Verma Dinesh
Published: November 2014

Enterprises of today need to be agile in how they manage systems over their life cycle. The design of system architectures has received a lot of focus as a means to facilitate agility. Less attention has been paid to the relationship of the system architecture to the organizational structures of all of the entities involved in the system life cycle.

A common, but inadequate, statement is that “the organizational structure shall mirror the product structure”. This research introduces processes as “middleware”, along with system architecture and organizational structure, to be included in the trade‐off for effective system life cycle management. Important additional factors that must be considered include informal organizational structures and the maturity of products, process and organizations.

This paper suggests a model of the problem description and recommendations for further research that can be adopted by practitioners and researchers in the fields of both engineering and organizational design. The paper builds on a previous paper by (Strandberg et al 2006) and elaborates on, in particular, the aspect of maturity.
1.4.4 Introducing Structured Information Handling in Automotive EE Development
Authors: Malvius Diana , Redell Ola , Ritzén Sofia
Published: November 2014

One way for the automotive industry to cope with the demand of a more structured information handling is to adjust model‐based development (MBD) to multidisciplinary needs. Many of the issues faced in this transition are as much organizational and managerial as they are technical. In a case study carried out at a global automotive manufacturer a project to improve the electrical and electronics (EE) development has been followed and analyzed. The project originated from different needs identified by management in their ongoing work effort towards MBD as well as by developers who experienced that tools did not support their work situation. This paper describes how the introduction of a new tool support was made in a project carried out within EE development, further it reports on benefits achieved by using the tool. Both the effect on the work of affected EE developers and the expansion of a new information model are discussed, leaving important implications for management. Success keys for putting new support tools into practice are identified here and include; a bottom‐up approach, user involvement from the beginning, focus on the individual needs and adaptation to current work practice. Further, management support and adequate resources are essential for extracting long‐term benefits.
2.1.2 Designing Systems for Adaptability by Means of Architecture Options
Authors: Engel Avner , Browning Tyson R.
Published: November 2014

Systems provide value through their ability to fulfill stakeholders' needs and wants. These needs evolve over time and may diverge from a fielded system's capabilities. Thus, a system's value to its stakeholders diminishes over time. As a result, systems are replaced or upgraded at substantial cost and disruption. If a system is designed to be changed and upgraded easily, however, this adaptability adds to its lifetime value. How can adaptability be designed into systems so that they will provide maximum value to stakeholders throughout their lifetime? This paper describes the problem and an approach to its mitigation.

We adopt the concept of real options from the field of economics and extend it to the field of systems architecture. We coin the termarchitecture optionsfor this next‐generation method and the associated tools for the design of flexible systems. Architecture options provide a quantitative means of implementing the optimal degree of design flexibility in a system to maximize its lifetime value for varied stakeholders. Based on initial research to date, we believe that implementing this aspect ofdesign for adaptabilitycan increase a system's overall stakeholder value by 15% at a very conservative minimum. We also present an extension of a method for measuring the dynamic value of a system.
3.3.2 How Should We Use the Term “System of Systems” and Why Should We Care?
Authors: Cocks Dan
Published: November 2014

As an engineering discipline, systems engineering is relatively young. As this branch of applied science comes of age, it struggles with nomenclature and boundaries and roles of interaction with other disciplines. Yet before the foundations are quite set and cured, additional terms are being introduced to imply specialized subdivisions or independent offshoots of the yet‐ill‐defined context of systems engineering. This paper offers a proposed definition for “System of Systems” to distinguish it from “System” and “Family of Systems” that not only delineates the differences among these terms, but also postulates that there is value in recognizing these differences.
3.4.1 Technology and Obsolescence Sustainment for Integrated Systems
Authors: Herald Tom , Genaw Dennis
Published: November 2014

Large, network‐centric systems utilizing legacy elements, integrating newest commercial technologies and involving highly diverse joint‐forces and international stakeholders have increased the magnitude and complexity of systems development and, subsequently, the system sustainment. This forces the need for additional bottoms‐up tangible change management decision and optimization support for the systems and supportability engineers.

This paper addresses two critical aspects in the context of system‐level obsolescence management. The first is System Obsolescence Life Cycle Forecasting and the second is Product and Technology Obsolescence Surveillance and Health Assessment. Proactive forecasting and assessment condense into a sustainment plan that encompasses the complete product operational life cycle. Product surveillance is the real‐time data monitoring mechanism that calibrates the accuracy of the forecast and the implementation plan. This paper provides recommendations specifically for the supportability engineer and the systems engineer in order to optimize the design for system affordability and to monitor change through market surveillance of the system baseline elements toward continued support of program decisions.

This paper is broken into five parts in order to highlight the needs and solutions which apply to each life cycle phase. This provides a complete technology management strategy for an integrated system that is comprised of varying commercial technologies, readily available Commercial‐off‐the‐Shelf (COTS) elements, and required legacy systems.

Part 1: Overview of Technology Management (TM) Requirements and Approach. Includes a discussion of the “life cycle mismatch” facing any operational system, wherein the desired system operation period is much longer than the life cycle of the constituent parts. This obsolescence mismatch must be managed at the system level to ensure program affordability.

Parts 2‐4: Development, Production and Sustainment phase TM needs and solutions.

Part 5: Conclusions and Recommendations. Two distinct TM variables are covered; the life cycle phases and the program complexity. Understanding these variables guides the systems and logistics engineers to an optimal operational solution.
3.4.3 Systems Engineering Net‐Centric solutions – an analysis of different perspectives
Authors: Crosby Gary , Kemp Duncan , Snell Dave
Published: November 2014

This paper reviews several different perspectives of net‐centric operations (NCO) identified by the INCOSE NCO working group. It is of one of three initial products of the group alongside a review of the Systems Engineering challenges posed by NCO and a literature survey of the state of the art in NCO.

The paper uses elements of Checkland's Soft‐Systems Methodology to understand a range of different perspectives on NCO. It describes three different perspectives of the benefits of net‐centric approaches, four perspectives of what constitutes a net‐centric solution and four different approaches to realising net‐centric solutions.

Finally the paper examines the relationship between the perspectives and draws some high level conclusions about the utility of the different approaches to different situations.
4.2.1 A Diagnostic Approach to Risk Driver Definition
Authors: Stump Evin
Published: November 2014

Brainstorming is a commonly used approach to generating project risk drivers. A consequence of brainstorming is that many proposed risk drivers are superficial symptoms, or at best next‐level‐down proximate causes.

Unfortunately, statements about symptoms and proximate causes are often assigned risk values such as probabilities or probability density functions. This paper will show that this practice can seriously overstate project risks. It can also lead to significant risk understatement due to issues of statistical independence.

The paper will conclude by proposing a diagnostic approach that eliminates or at least minimizes this problem. It is based on root cause analysis using fishbone diagrams.
4.2.3 Systems Engineering Professional Development & Certification
Authors: Fisher Gerard H.
Published: November 2014

In the mid‐1990s, the Federal Government pursued “Acquisition Reform,” which resulted in significantly reduced government technical oversight of contractors. This caused less technical personnel to be hired in the government program offices for the last ten years. Recent investigations of space problems have recognized the need to revitalize the systems engineering workforce within the government program offices. Two years ago, the National Reconnaissance Office (NRO) embarked on the development of a professional development and certification program for space systems engineering. The NRO workforce is heterogeneous; it is comprised of military and civilian members of all DoD services as well as several intelligence community agencies. Our objective was to develop a program that maximized the synergy with parent‐agency programs and avoided any redundant training requirements. A three‐level certification program was established that required technical education, systems engineering experience, and systems engineering training. The training selected is a combination of existing NRO courses, off‐the‐shelf academic courses, commercial training classes, newly developed classes and INCOSE CSEP certification. After the first year, over 375 employees have attended at least one training class and we are certifying systems engineers at the rate of 10–12 per month. The success of this program has led to potential expansion into other areas of the government.
4.4.2 Lessons Learned from Synchronizing Complex Systems Development within Automotive Industry
Authors: Negele Herbert , Schmidt Reinhard , Finkel Stephan , Wenzel Stefan
Published: November 2014

The automotive industry has encountered fundamental changes in the last decade, e.g. increased international competition, more complex and diversified products, and strongly changing product development processes. Nowadays, electrical/electronic (E/E) systems play a crucial role in vehicle development in order to offer innovative and attractive products to customers. Therefore, it is vital for an automotive OEM to master E/E systems over the entire life‐cycle. Besides sound engineering, an effective project and risk management becomes more and more important. Synchronizing all the development activities and all involved stakeholders is a major challenge here. This is of key importance, as the E/E system represents a triplicate highly distributed structure, in terms of process, organization, and the product itself.

This paper illustrates lessons learned from implementing synchronization management within the E/E system development as part of a major process improvement initiative. The paper starts by highlighting the paradigm shift within the development processes of an automotive OEM from “component‐driven” development to “system‐oriented” engineering. Based on this background the need for synchronization of all involved “players” within E/E system development will be pointed out. The development and implementation of a generic synchronization/master plan as well as the usage and tailoring of this plan for specific projects will be described. Also, embedding this E/E synchronization management within the overall vehicle development process will be discussed (e.g. how to handle changes within the development process). The paper finally highlights lessons learned during the phases of conception, implementation, and application of the generic master plan and the synchronization management process.
5.2.2 Optimizing Quality Assurance for Better Results
Authors: Malotaux Niels
Published: November 2014

We know all the stories about failed and partly failed projects. Apparently, too many defects are generated by developers, and too many remain undiscovered by checkers, causing too many problems to be experienced by users. Solutions are mostly sought in technical means like processes, metrics and tools. If this really would have helped, it should have shown by now.

Oddly enough, there is a lot of knowledge how to reduce the generation and proliferation of defects and deliver the right solution quicker. Still, this knowledge is ignored in many development organizations.

In a recent booklet: How Quality is Assured by Evolutionary Methods [2], I describe how to organize projects using this knowledge successfully. This paper extends the use of this knowledge to QA, in order to optimize the contribution of QA to project success. Important ingredients are: a change in attitude, taking the Goal seriously, focusing on prevention rather than repair, and constantly learning how to do things better.
5.3.3 SysML‐Based Systems Engineering Using a Model‐Driven Development Approach
Authors: Hoffmann Hans‐Peter
Published: November 2014

More and more, systems engineers are turning to the System Modeling Language (SysML) to specify and structure their systems. This has many advantages, including verifiability and ease of passing off information to other engineering disciplines, particularly software. This article describes a SysML‐based process that systems engineers can use to capture requirements and specify architecture. The process uses the SysML exclusively for the representation and specification of system characteristics. Essential SysML artifacts include use case diagrams, sequence diagrams, activity diagrams, statechart diagrams, and structure diagrams. The process is function‐driven and is based heavily on the identification and elaboration of operational contracts, a message‐based interface communication concept. The outlined process has been applied successfully at various customer sites.
6.1.1 The Application of Architecture Frameworks to Modelling Exploration Operations Costs
Authors: Shishko Robert
Published: November 2014

Developments in architectural frameworks and system‐of‐systems thinking have provided useful constructs for systems engineering. DoDAF concepts, language, and formalisms, in particular, provide a natural way of conceptualizing an operations cost model applicable to NASA's space exploration vision. Not all DoDAF products have meaning or apply to a DoDAF‐inspired operations cost model, but this paper describes how such DoDAF concepts as nodes, systems, and operational activities relate to the development of a model to estimate exploration operations costs. The paper discusses the specific implementation to the Mission Operations Directorate (MOD) operational functions/activities currently being developed and presents an overview of how this powerful representation can apply to robotic space missions as well.
6.3.1 Threads of Reasoning: A Case Study
Authors: Sandee J.H. , van den Bosch P.F.A. , Heemels W.P.M.H. , Muller G.J. , Verhoef M.H.G.
Published: November 2014

In the design of technology intensive products like copiers, wafer steppers and televisions, one searches for a product that satisfies the product requirements as well as the business drivers. The main need in an early design phase is to bring structure in the typical chaos of uncertainty and the huge amount of realization options present. Potential realization choices all have advantages and disadvantages, which cause tensions and conflicts. The earlier the (essential) conflicts and tensions are identified, the better it is. Turning them from implicit to explicit helps the system architect in making the trade‐off consciously or at least in selecting the most important tensions and conflicts that require further in‐depth investigation. In this respect we demonstrate the effectiveness of a technique called “threads of reasoning”. The illustrative case study is the design of the paper flow control (sensors, actuators, control architecture, etc.) in a high‐volume copier/printer.
6.3.2 No Cure No Pay: How to Contract for Software Services
Authors: Gilb Tom
Published: November 2014

50% of all software projects are total failures and another 40% are partial failures according to widely quoted surveys in UK, USA and Norway. Large government projects in all 3 countries have been reported with spectacular failure and expense to taxpayers (Royal Academy of Engineering and British Computer Society 2004). What is the problem? Most discussions have centered on improving the software engineering process itself: better estimation, better requirements, better reuse and better testing. No doubt all those can be improved. However, I suggest the motivation to improve them needs to be put in place first. Think about it. Most of these failures have been fully paid for! We not only pay well for failure, but the bigger the failure, the more people get paid!

My suggestion is simple. Pay only when defined results are provably delivered. This requires several things:

Contracts that release payment only for meaningful results;

The ability to define those results, particularly qualitative ones, and particularly the organizational ones;

The ability to deliver those results incrementally, thus proving capability at early stages and continuously.

Note: This paper specifically addresses the software problem, but I am sure that the ideas here apply to the wider systems engineering problem to some interesting degree as well.
7.2.3 Tying Requirements to Design Artifacts
Authors: Briggs Clark , Sampson Mark
Published: November 2014

A new generation of Product Data Management and Product Lifecycle Management tools offer a combination of systems engineering and design engineering capabilities with a common database. This provides the opportunity to tie requirements to elements of the design such as CAD models, drawings and analyses. Connecting the currently disjoint systems engineering and design engineering modelling domains provides a new opportunity for a rich set of relationships and the promise of alleviating much of the tedious checking of requirements usually performed by design engineers. This paper explores the use cases for joining systems engineering and design engineering modelling and proposes a set of relations that provide meaning to the new links.
8.1.3 Identification of Real Options “in” Projects
Authors: Wang Tao , de Neufville Richard
Published: November 2014

The concept of real options ‐ initiated in the field of finance ‐ has extended into engineering systems to model design flexibility in the realistically uncertain environment. However, whereas financial options are well‐defined traded contracts, real options “in” engineering systems are a priori undefined, complex, and interdependent. Moreover, systems involve many more options than designers could consider. Therefore designers need to identify the real options most likely to offer good flexibility and the most value.

This paper proposes a procedure to identify real options “in” engineering systems. It consists of a screening and a simulation model. The screening model is a simplified, conceptual, low‐fidelity representation of the system that reflects its most important issues. As it is inexpensive to run, it is used to test extensively designs under dynamic conditions. The following simulation model is used to validate critical considerations, such as the robustness and reliability of the designs, which are omitted from the screening model in order to expedite its operation.

The paper first establishes the concepts of the options identification model, and then resorts to examples to detail its application. The case of a hydro power system formulates the screening and simulation models, and presents the specific steps needed to search systematically for the interesting real options.
8.2.1 Establishing a Verification and Validation Process in Automotive Development: Increasing Product Quality while Reducing Costs
Authors: Meisenzahl Johannes , de la Cruz Marcelo , Vollerthun Andreas
Published: November 2014

In spite of continuous improvements in maturity levels of the electric/electronics development process, the structured verification and validation of automobile electric and electronics in all product phases takes on increasing importance. The methodology presented in this paper is based on the “5 dimensions” of verification and validation: what to “verify”, how, wherewith, when and by whom and focuses on a) the systematic planning and specification of verification and validation activities as a link between the requirements engineering and the testing itself, and b) the results of its successful user‐oriented implementation in an actual vehicle project of the BMW Group.

This paper describes a proven methodology that contributes to handle the increasing complexity (e.g. caused by the multitude of variants) of automotive systems while still enabling innovations and premium quality. Further the organizational tasks, which must be met in order to customize the methodology to the specific project situation, are addressed.
8.2.2 Applying Systems Engineering to Naval Shipbuilding
Authors: Wells Brian H.
Published: November 2014

The processes for naval architecture and ship design evolved before the systems engineering processes used today were defined and documented. The standard systems engineering processes based on MIL‐STD‐499 and now ANSI/EIA‐632 have been extensively applied to the development of military and commercial products. While the designs of the naval ship combat system payloads have used systems engineering methods, the ship design, and development has traditionally applied processes that are unique and not included in the standard systems engineering activities. The development of many ship subsystems has followed an evolutionary approach that has not required many of the systems engineering process steps. This paper defines some of the unique challenges of applying the systems engineering process to the design and development of Navy ships. Some of the traditional naval architecture and ship design processes are presented and contrasted with the systems engineering standards. The challenges that required the amalgamation of these two cultures are discussed. Finally, processes and methods that provide an integrated approach are presented.
8.2.3 Giving the Integrator Role a Sporting Chance
Authors: Armstrong James R.
Published: November 2014

As systems become larger and more complex, there are more opportunities for playing the role of integrator in an expanding ‘food chain’ of layered development. Many organizations are seeking to increase their integration role and move up the ladder. This paper provides guidance on what that change means and requires. It also does so with an analogy to levels of play in the world of sports.
10.2.1 The Dual Vee – Illuminating the Management of Complexity
Authors: Mooz Hal , Forsberg Kevin
Published: November 2014

The Waterfall, Spiral, and Vee models are reminder models that guide us to less perilous paths when developing solutions to problems. Dr. Royce's Waterfall (Royce 1970) provides an orderly approach to software development. Dr. Boehm's Spiral (Boehm 1988) provides emphasis on solving known software risks before proceeding with Royce's Waterfall. The Forsberg/Mooz Vee Model (Forsberg 1991) embraces full systems development by including details of integration, verification, and validation and opportunity and risk management in the symmetry of the Vee development sequence. However, all of these single solution development models fail to address the necessary concurrent development of a system's architecture with the entities of that architecture. The Dual Vee Model introduced in Visualizing Project Management, 3rd Edition in 2005, does just that and illuminates the necessary interactions and sequences recommended for orderly maturation of a system and systems of systems. This paper explains the power of the Dual Vee Model when applied as a reminder model for development of complex systems.
10.2.2 IDEF0 Lessons Learned
Authors: Smith Darold K.
Published: November 2014

The IDEF0 methodology is becoming widely used as a tool in all types of systems. If a program is considering using IDEF0, there are serious pitfalls to avoid to assure that using IDEF0 provides as accurate and complete system definition that IDEF0 is capable of supporting.

The pitfalls are illustrated with three case histories to support the lessons learned. Some lessons apply to other methodologies beyond IDEF0. Although IDEF0 has been in use for many years, it is still being applied to new programs and the lessons learned are timely.
10.3.2 An Enterprise Systems Engineering Model
Authors: DeRosa Joseph K. , Rebovich George , Swarz Robert S.
Published: November 2014

The INCOSE (ANSI/EIA 632) systems engineering model may not be adequate for an enterprise environment, in which environmental influences and the interaction of people, processes, and technology are not taken into account. This paper considers some “systems thinking” concepts and applies them to develop an expanded model that may be more appropriate in the enterprise environment.
10.4.1 Certification & Accreditation – The Role of Security Engineering in the Systems Development Life Cycle
Authors: Tysenn Jeff
Published: November 2014

Security is most effective if it is planned and managed throughout an organizations Systems Development Life Cycle (SDLC). Many security risks, analyses, and events occur during a systems or applications lifetime and these issues should be dealt with from the initial planning stages and continue through all phases of the SDLC. Many systems today must also address Certification and Accreditation (C&A) before going operational. C&A facilitates including security as an element of the SDLC assuring that a clear set of Security Requirements is developed and implemented, residual risk is minimized and clearly understood, and all security controls developed and deployed in the final operational system are documented in a System Security Plan. This paper examines the role of security engineering and their activities throughout the SDLC and the C&A process, the guidance that helps define the Security Requirements, and the roles of the people involved to provide a basic understanding of security engineering as it applies to C&A throughout the SDLC. One of the objectives of this paper is to help Program Manager's understand and take into account the C&A process into program plans and schedules.
10.4.2 Managing compatibility throughout the product life cycle of embedded systems – Definition and application of an effective process to control compatibility
Authors: Bornemann Falk , Wenzel Stefan
Published: November 2014

Due to the fact of increasing complexity in modern embedded systems, problems associated with compatibility have become an important issue when managing product life cycles. The question of how to maintain and restore the system wide compatibility throughout the entire product life cycle is yet to be answered. So far, compatibility management has not been established as a standard procedure among the traditional and established business areas. Even the CMMI (Capability Maturity Model Integration) [Chrissis, M. B.; Konrad M. and Shrum S. “CMMI – Guidelines for Process Integration and Product Improvement” Carnegie Mellon Software Engineering Institute, (2003 by Pearson Education, Inc.)] does not classify compatibility management as a specific single process area.

This paper gives a first impression of what an effective compatibility management needs to deliver and how it should be integrated into the product life cycle process.

Furthermore, in the following paper process are being defined and applied of how to manage and remedy problems associated with compatibility. Procedures will be described and their functionality will be explained. With the help of that process incompatibilities can be removed and system‐wide compatibility can be maintained throughout the entire product life cycle of an embedded system. The paper also shows that without clearly defined processes that describe and help how to remove incompatibilities, maintain and restore system wide compatibility, especially during system updates and upgrades, the time, money and effort spend to secure the functionality of complex embedded systems will reach uneconomical levels.
11.1.3 An introduction to Network Centric Warfare
Authors: Gastelum Alejandro , Dagli Cihan H. , Miller Ann
Published: November 2014

This paper gives a short explanation of Network Centric Warfare, some background information and technology that makes this a reality. It also provides an example of how network centric solutions can be used to do a kill Chain and its advantages over platform centric scenarios. NCW faces a lot of challenges to System Engineers interoperability, increased complexity, fault tolerance, distributed computing are all needed to be understood to make NCW a reality. The nature of network centric makes us focus also on wireless networks and how they can be used, its advantages, protocols, and later on two frameworks implemented by Sun, Jini an Jxta. Each has its own set of protocols, procedures and ideology, and both are being used to create very reliable networks with changing topology.
11.2.1 Challenges in the application of systems engineering principles to the design of appealing consumer products
Authors: Agouridas Vassilis , Longstaff James , Childs Tom , McKay Alison
Published: November 2014

This paper reports results of research carried out in the context of a co‐ordination action funded by the European Commission that dealt with the gathering and evaluation of state of the art tools, best practice methods and techniques deployed by leading manufacturers in developing appealing consumer products. Data was gathered through questionnaires and semi‐structured interviews. Analysis of the data showed that the design of appealing products involves an intricate web of relationships amongst understanding consumer needs, determining and verifying product characteristics, and validating products that excite consumers. The need for a systems engineering approach in rationalising such an intricate web of relationships is described based on the research findings. A number of challenges associated with the implementation of such an approach are discussed.
11.2.2 The Systems Project: Life Cycle Development/Management of as Many as Four Interrelated Systems
Authors: Paul Arthur S. , Owunwanne Chinweizu
Published: November 2014

Work presented at this Conference previously proposed the Producing System (or enabling system) as a mechanism for organizing and managing the enabling resources in the development of a Product System (Alias, required system, system‐of‐interest, intervention system, end product, operational system, etc.). It presented the producing system as separate from, but closely related to, the product system. Specifically, the relationship was equated to that of a parent: child (producing system: product system) relationship.(Paul and Yerace 2004)

This paper explores current practices regarding the identification and processing of systems that interact with, or have some form of involvement in the life cycle of, the product system. The primary focus is, of course, the interrelationship between the product system and the enabling resources or producing system; however, studies have identified diverse interactions with competing systems, context systems, collaborating systems, containing systems, and others. This paper identifies the similarities and differences among the various perspectives.

Finally, the paper expands on these concepts by introducing the Systems Project as a family of up to four closely related systems whose interactions are focused on the life cycle (birth to death) of the product system. Specifically, the Systems Project is a framework for packaging and conducting all of the systems engineering activities associated with developing/managing the product system, the producing system, the Existing System (if there is one in place, if applicable [I/A]), and the Maintenance and Support System through the life cycle of the product system.
11.4.2 Top 40 Systems Engineering Work Products From Phrase Lists and Self‐Organizing Maps
Authors: Beshore David G.
Published: November 2014

A computer‐automated method using semantic web algorithms is described that ranks the best systems engineering work products on websites and corporate repositories. The process is both server‐based and PC‐based to automate the capture and ranking of knowledge from industry experts within The Aerospace Corporation. A virtual Process Assets Library system (vPALs) economically collects and self‐organizes documents through long lists of phrases (phrase vectors) using next‐generation web engines. Ranking documents implements scoring algorithms with phrase vectors in the development of 1‐D, 2‐D, and 3‐D self‐organizing maps (SOMs). vPALs is being deployed in 1) real‐time decision making during launch vehicle systems testing and day‐of‐launch at Cape Canaveral and Vandenberg, 2) proposal technical evaluations, 3) data mining and maintenance of corporate document repositories, 4) formal design reviews with customers, and 5) web‐based systems and software engineering books of knowledge. Nine websites are used in this paper to rank order the most relevant documents related to SE workproducts: NASA‐PBMA FAA‐ASD, FAA‐IPG, SEI, SEPO‐SPAWAR, SMC, DAU, STC and Aerospace's AeroLink corporate document repository.
11.4.3 Advancing the Canadian Capability Engineering Approach
Authors: Lalancette Claire , Lizotte Michel , Nécaille Christophe , Robbins Wayne , Waruszynski Barbara
Published: November 2014

The Collaborative Capability Definition Engineering and Management Technology Demonstration (CapDEM TD) project is investigating Capability Engineering (CE) in order to support the Capability‐Based Planning (CBP) decision‐making process. This paper presents the evaluation effort being applied to the Capability Engineering approach, a methodology based on the systems engineering paradigm and articulated around three axes: People, Process and Materiel. Originating from the laboratories of Defence R&D Canada, the CapDEM effort is now evolving from theory into practice, based on an on‐going evaluation strategy concretely realized via three validation exercises that consist of realistic simulations of people applying the process and materiel to resolve capability gaps. This paper details the evaluation strategy and includes lessons learned from the first and second validation exercises. The tenets and expectations from the final exercises will form the final part of the paper, with the intent of providing insight into the advancement of capability engineering.
A Prioritization Process
Authors: Botta Rick , Bahill Terry
Published: November 2014

A prioritization process has been developed and used at National Security Solutions of BAE Systems. It has been used to derive weights of importance for the criteria in tradeoff studies and to prioritize goals, customer needs, capabilities, risks, directives, initiatives, issues, activities, requirements, technical performance measures, features and functions.
Development Program Risk Assessment Based on Utility Theory
Authors: Ben‐Asher Joseph Z.
Published: November 2014

A methodology for risk assessment is introduced based on Utility Theory. The main idea is to quantify the risk consequences by using an equivalent lottery where the probability of getting the worst possible risk outcome is taken as the value representing the risk consequences. This improves the evaluation process by making it more systematic, and justifies the use of the expected value for obtaining the risk factor. The idea is compared with other methods and is demonstrated by a case study.
Can Systems Modeling Language Impact Systems Engineering?
Authors: Orr Kevin , Ramakrishnan Sreeram , Dagli Cihan H.
Published: November 2014

This paper examines the System Engineering processes/applications transforming from being document‐centric to being model‐centric by examining the benefits and uses of the Systems Modeling Language (SysML). This paper will look at the concept behind SysML and provide a background on existing research to address the Unified Modeling Language (UML) Systems Engineering request for proposal to generate SysML. This paper will identify benefits of using SysML in the Systems Engineering process and makes a recommendation for its use in large scale integration projects and complex hardware and software designs.
Preparing SEBoK for Korea Defense Systems Acquisition Processes
Authors: Han Myeong‐Deok
Published: November 2014

Just as INCOSE tried to set up G2SEBoK, Korea Council on Systems Engineering is now trying to set up its own Systems Engineering Body of Knowledge so that its members and other people related to Korea Defense Acquisition Processes can share a common perspective about what is SE, what is the core of the SE processes, How we do it, etc. Here is the report of the first draft of KCOSE SEBoK list of contents with some description of how we approach this problem.
1.2.0 Panel 1.2.0: Heading Down a New Track: Growing an SE Practice in a Big, Bureaucratic, Legacy Enterprise
Authors: Ericsson C. , Brouwer P. , Gharatya K. , Halliday B. , O'Neil A.
Published: November 2014

After over 100 years of traditional design and construction, the rail industry is now tailoring Systems Engineering processes to cope with the complexities of its capital projects. This industry is attempting to accomplish in ten or fifteen years what has taken aerospace and defense 50 years to achieve—‐ that is, to embed an SE approach into the fabric of its business. Four panelists will share how their big, bureaucratic and very conservative organizations are transforming to meet today's challenges. They will describe how they are dealing with the driving forces of system interoperability and dynamic technologies and the restraining forces of severe SE competency shortages and institutional barriers to cross‐disciplinary teamwork. They will share how they are changing their contracts, design documents and procedures, and how they are adapting design tools and approaches to deliver successful projects and improve life‐cycle systems performance. These are the early chapters of an entire industry in flux.
1.3.4 Model‐Based Design and Verification of Fault‐Tolerant Systems
Authors: Sorea Maria , Ruess Harald
Published: November 2014

There is an increasing trend towards model‐based development (MBD) of safety‐critical systems. In an MBD approach, various development activities such as simulation, testing, code generation, and verification are based on a single formal model of the system. In this paper we show that the MBD approach can also be applied towards automating the safety analysis process. Using precise formal models of the system as the basis of the analysis helps avoiding design errors at early stages in the development lifecycle. The analysis is automated by means of model‐checking tools, which results in a more thorough analysis and reduced manual effort compared to more traditional methods. We illustrate model‐based analysis using the fault‐tolerant startup protocol for a time‐triggered middleware architecture (TTA). For a functional model of this protocol, it is verified that the specified safety requirements are satisfied in the presence of all faults within the given fault hypothesis. We demonstrate that exact, complete, and consistent safety analyses can—and in fact should—be carried out for relevant industrial designs in very early phases of the development life cycle and in an automated fashion.
1.4.2 A Model for Successful Engineering Internship: Growing Our Own Future Engineers
Authors: Malloy Mary Ann
Published: November 2014

UCLA's Higher Education Research Institute reported there has been a 60% drop in science and engineering majors among incoming college freshmen since the year 2000. Competition for the dwindling number of graduating entry‐level engineers is fierce. At the same time, the academic experience of engineering rarely emulates what students can expect in the real world. Students need relevant work opportunities to validate their career plans while keeping them engaged in their engineering degree programs. Two years ago, we established an Internship Program to respond to both sides of this challenge. Internship expands the concept of training beyond enhancing the skills of existing staff, to include a company making a training investment in student engineers they might like to hire full‐time someday. In this paper, we provide a template for our successful Internship Program as a model for other employers who would like to “grow their own” entry‐level engineers.