bluuebunny/crossref_metadata_2025 huggingface dataset:
2.4.2 NASA Systems Engineering Capability Pre‐Assessment Plan
Authors: Andary James F. , Kapurch Stephen J. , Chun Peggy A. , Ernst Eric W. , Gauntner Daniel J. , Kerns Robert V. , Lake Jerome (Jerry) G.
Published: November 2014

Over the past several years, several events [Ref 1] have led NASA to re‐examine how it engineers systems. As a result, NASA initiated a Systems Engineering Excellence Initiative in 2001, and established a Systems Engineering Working Group (SEWG) to form and implement a common framework for engineering systems within NASA1.

The common framework is based on the development and sustainment of a state‐of‐the‐art level of competence in systems engineering, measurable in three specific areas; Concepts and Processes; Knowledge and Skill of Workforce; and Tools and Methodologies. The framework must also include a method of providing continuous assessment and improvement.

Cursory review led a SEWG sub‐group (The Assessment Subgroup) to conclude that utilization of a recognized maturity model, such as the Software Engineering Institute's (SEI) Capability Maturity Model Integrated (CMMI®), would provide the means for ensuring continuous assessment and improvement of the framework.

Prior to launching a CMMI® assessment of systems engineering at all ten NASA Centers (estimated to cost in excess of $500,000), the Assessment Subgroup proposed to conduct a pre‐CMMI® assessment (hereafter referred to as a pre‐assessment) to evaluate the current level of competence of systems engineering throughout the Agency, and determine whether or not CMMI® should be implemented.
2.6.1 The Schedule as Independent Variable (SAIV) Process for Acquisition of Software‐Intensive Systems
Authors: Boehm Barry , Brown Winsor , Huang LiGuo , Port Daniel N.
Published: November 2014

Many system acquisitions do not achieve on‐time delivery because of delays in software development. This paper presents a highly successful approach for on‐time delivery of software‐intensive systems: the Schedule As Independent Variable (SAIV) process. The SAIV process involves prioritization of desired features; scoping a Core Capability of top‐priority features easily achievable within the available schedule; architecting for ease of dropping or adding borderline‐priority features; monitoring progress with respect to plans; and adding or dropping borderline‐priority features to meet the schedule target. The paper summarizes experiences and discusses critical success factors in applying the SAIV acquisition process across a range from small in‐house e‐services projects to very large Government systems of systems.
3.3.3 Designing sustainable processes using environmental and economic assessment
Authors: Krajnc Damjan , Glavič Peter
Published: November 2014

The paper presents a systematic approach to the problem of sustainable process synthesis of large‐scale chemical processes with respect to the resource usage and other environmental considerations. The process design is composed of three main steps, i.e. simulation step, conceptual design step (extended Pinch design method, determination of promising modifications, their assessment regarding sustainability, selection of the most promising modification) and rigorous design step (structural and parameter optimization). The ecological considerations are combined with the economic assessment of process design using indicators of process sustainability. Environmental impact of process design is quantified by a set of sustainable process indicators (specific energy and water consumption, global warming potential, acidification potential, etc.). With suitable weightings, a composite index of process sustainability is defined and served as an objective function for the assessment of process modifications. A simplified ammonia production is presented to demonstrate the potential of the approach assisting in arriving at environmentally friendly and economically favorable process design.
4.1.2 Extending UML to Support a Systems Modeling Language
Authors: Friedenthal Sanford A. , Kobryn Cris
Published: November 2014

The International Council on Systems Engineering (INCOSE) and the Object Management Group (OMG) are collaborating on an initiative to extend the Unified Modeling Language™ (UML™) to provide a general‐purpose systems modeling language. The language will support the specification, analysis, design, verification and validation of complex systems that include software‐intensive, information‐intensive, and physical systems. To achieve this goal, the OMG issued a UML for Systems Engineering Request for Proposal (UML for SE RFP) in March 2003. The modeling language that satisfies the requirements of this RFP will be a key enabler for transitioning the practice of systems engineering from a document‐centric to a model‐centric approach. This paper describes the technical approach and language features of the Systems Modeling Language (SysML), which is being proposed in response to the UML for SE RFP.
4.2.2 The Difference ‐ On the Use of Pattern‐Based Requirements
Authors: Kaffenberger Ruediger
Published: November 2014

It is common knowledge that a complete and correct set of requirements is the key prerequisite for a successful development project. But the size of the projects, their complexity, budget constraints, and short time to market prevent good requirements engineering. An additional obstacle is human nature: People are not able to express their needs in a way that this information is sufficient as foundation of a complete set of requirements. With the conventional requirements engineering methods, the problem of missing, ambiguous, or misleading requirements can not be solved. This paper suggests the intensive use of patterns as the more successful way to specify system requirements. In an object oriented environment patterns are found and applied much easier than in an environment where the functional view prevails. Thus a shift to object oriented requirements engineering and systems engineering is required.
4.5.1 The Capability Integration Framework: A New Way of Doing Enterprise Architecture
Authors: Conklin James H. , Evans John W. , Martin James N. , Robinson Charles T. , Diehl Jeff J. , Doggrell Leslie J.
Published: November 2014

The Capability Integration Framework was created to help Air Force Space Command leadership understand the relationships that existed within their organization. By following a modeling process developed by The Aerospace Corporation, the architecture team was able to deliver the first version of the tool after three months of work. This paper will briefly discuss the modeling process and will use the Capability Integration Framework as an example for applying this process. Some features unique to this model will also be demonstrated.
4.6.2 A Knowledge Management Approach to Change Management in Systems‐of‐Systems
Authors: Cropley David H
Published: November 2014

When a complex entity comprises, for example, a set of individually complex, geographically distributed, evolving systems, the question of how to manage change to such a system‐of‐systems takes great significance. Not only must change be managed at the level of each component system, it must also be managed across the entire interrelated and interacting set. The solution presented in this paper is based on research that treats a class of warships in the Royal Australian Navy (RAN), along with the associated operational, production and support systems, as a system‐of‐systems (SoS) and examines the management of change in this complex entity. The paper describes a Knowledge Management (KM) strategy that can be used to plan, manage, coordinate and implement change across the entire lifecycle of the target system‐of‐systems and which may be generalisable to other systems‐of‐systems.
2 Panel: Evolving to Intelligent SE
Authors: Ring Jack , Lillehagen Frank , Alessi Sam , Aslaksen Erik W.
Published: November 2014

New technologies are enabling Model‐driven Approaches and Architectures, Model‐converged Methodologies, Model‐integrated Enterprises and Infrastructures, Model‐developed Collaboration Platforms, Model‐designed Solutions and Project Environments, Model‐generated Workplaces for work execution and management, and Model‐managed Enterprise Knowledge Spaces and architectures. Knowledge engineering platform providers will within 2006 offer a completely new approach to Systems Engineering and Enterprise Integration, embedding any system in one or more enterprise knowledge spaces. An Enterprise Knowledge Space is implemented as an Enterprise Visual Scene.
5.1.3 Requirements Completeness
Authors: Carson Ronald S. , Aslaksen Erik , Caple George , Davies Paul , Gonzales Regina , Kohl Ron , Sahraoui Abd‐El‐Kader
Published: November 2014

The INCOSE Requirements Working Group has attempted to define a process and methodology for producing a complete set of requirements. We first carefully define the problem statement and terms. Various approaches to completeness are reviewed, and a formal process is proposed to quantify completeness.
5.2.3 Product and Process – Student Learning in an Undergraduate Systems Engineering Course
Authors: Ferris Timothy L.J.
Published: November 2014

The University of South Australia program, Bachelor of Engineering (IT Option) contains a sequence of four courses in the field of Systems Engineering, comprising 12.5% of the program. This paper describes the content and teaching processes used in the last course in this sequence, scheduled for the undergraduate students in the final semester of their program. The paper discusses the evidence provided by students of the learning that they have achieved through the course in the assignment assessment, weighted 40% of the course. It is found that the learning about the practice of Systems Engineering developed by students is not correlated with the achievement in the technical aspects of the project. The kinds of learning achieved are discussed in the paper.
5.4.1 The Use of Integrated Architectures to Support Agent Based Simulation: An Initial Investigation
Authors: Zinn Andrew , DeStefano Greg , Jacques David
Published: November 2014

Architecture descriptions following the Department of Defense Architectural Framework (DoDAF) will be used to aid in the acquisition of all major defense information systems. One of the primary purposes of these architectures is to help conduct military‐worth analysis. Recent work in operations analysis of information driven combat is showing that agent based simulation technology is needed to understand the military value of Command, Control, Communications, Computers, Intelligence, and Reconnaissance (C4ISR) systems. This paper investigates the utility of architecture descriptions based on the DoDAF to provide the needed data for agent based simulation. This is accomplished by means of a case study where data from a DoD architecture is used in the combat model System Effectiveness Analysis Simulation (SEAS). The research concludes that the DoDAF, if implemented properly, does provide the needed information. A process for taking information from a DoDAF architecture and importing it into agent based simulation is proposed.
6.2.3 Understanding the Value of Systems Engineering
Authors: Honour Eric C.
Published: November 2014

The practices of systems engineering are believed to have high value in the development of complex systems. Heuristic wisdom is that an increase in the quantity and quality of systems engineering (SE) can reduce project schedule while increasing product quality. This paper explores recent theoretical and statistical information concerning this heuristic value of SE. It explores the underlying theoretical relationships among project cost and schedule, technical value, technical size, technical complexity, and technical quality, summarizing prior work by the author. It then identifies and summarizes six prior statistical studies with conclusions that relate to the value of SE. Finally, the paper provides final results of a statistical study by the INCOSE Systems Engineering Center of Excellence (SECOE) that presents evident correlations supporting the heuristics. The results indicate that optimal SE effort is approximately 15–20% of the total project effort.
6.4.1 Creating Flexible Architectures for Systems Engineering
Authors: Hause Matthew , Thom Francis
Published: November 2014

Systems Engineers have been modeling systems since the inception of the discipline. Reasons for modeling systems include among others: definition of the work to be done (requirements), allocation of responsibilities, documentation of the completed system, and communication with the various disciplines who will create, operate, and maintain the system. UML (the Unified Modeling Language) has recently been used by Systems Engineers to model systems. Many papers and articles have been written on various aspects of systems modeling with UML, most especially Use Cases, but little attention has been paid to system partitioning. Papers that address system partitioning do so with a “one size fits all” philosophy, by mandating a prescriptive structure that does not address the true needs of a particular system's development. Unfortunately, a badly partitioned system can be a serious handicap to the development of a system. The drivers for system partitioning include: process, product, team makeup, areas of interest, standards, physical boundaries of the system, legacy and COTS components, coupling and cohesion. A proper approach can also help in the establishment of a component based development approach, leading to reuse of requirements, design, test, and implementation artifacts. This paper will discuss these issues and illustrate their use by four case studies drawn from experience in consultation. Finally, it will give advice on lessons learned.
6.4.2 Concept of Application of Systems Engineering in Component‐based Planning of Manufacturing Plants in Non‐hierarchical Regional Production Networks
Authors: Näser Peggy
Published: November 2014

Manufacturing plants in non‐hierarchical regional production networks are complex systems whose structures are characterized by high dynamics. The Systems Engineering approach is suitable to analyze manufacturing plants in their complexity and to systematically support planning execution.
6.5.3 The Zachman Framework Populated with Baseball Models
Authors: Botta Rick , Bahill Terry
Published: November 2014

There are guidelines for making good models. Amongst these are frameworks, which help organizations develop integrated models of their businesses. Frameworks help people understand organizations and systems. The Zachman framework for enterprise architecture is a matrix (or schema), where the six rows represent different perspectives of the organization and the six columns illustrate the items, or models, viewed from each perspective. In this paper, a Zachman framework is populated with models for Baseball. These models should be easy to understand without a steep learning curve. Most of the cells are filled with quantitative simulatable models that have been published in peer reviewed journal papers. The other cells are filled with simple thought models. Jacques Barzun said, “Whoever wants to know the heart and mind of America had better learn baseball, the rules and realities of the game.” From the perspective of the Zachman framework, the way to learn Baseball is to define the models within the framework, as presented in this paper.
7.1.2 The Systems Engineering Sandwich: combining requirements, models and design
Authors: Dick Jeremy , Chard Jonathon
Published: November 2014

As Systems Engineering problems and solutions become more complex, it is harder for engineers to describe them and harder for reviewers and other stake‐holders to understand the descriptions. What is needed is a more powerful way of describing both problems and solutions, which combines the textual approach with the diverse world of modeling, including the use of visual representation. The result would be more accurate and complete system descriptions that are easier to understand and communicate for all stakeholders involved.

In the Systems Engineering “sandwich”, requirements management is the “bread and butter” of the development cycle, and system modeling provides the “filling“. The role of the filling provided by modeling is to hold the requirements layers together, and provide richer rationale for relationships between those layers.

In our opinion, the key to integrating requirements management with system model is the recording of design rational in an organized way. Such rationale explains why requirements have been decomposed in particular ways, and how one layer of requirements is intended to satisfy the layer above. The focus for such information is the “design document“.

The following benefits are identified as accruing from an effective process integration of requirements management and system modeling:

System modeling adds formality to the design process that lies between each layer of requirements.

System modeling supports the construction of a consistent vocabulary for the textual expression of requirements.

The design rationale gathered around the system model becomes the rationale for tracing between layers of requirements.

The structure of the system model can be used to give structure to the requirements document.

System models can be embedded in system design documents. These can provide textual context for the system model, giving rationale for design choices, explanations of diagrams, etc.

Impact analysis can be carried out uniformly through requirements and models.

Non‐functional and performance requirements not captured in the model can be managed as textual statements.
7.3.2 Optimization of Research and Development Investment Strategies
Authors: Gormley Kevin , Fishenden James C. , Scherer William T.
Published: November 2014

An enterprise must make up‐front investments in applied research and development (R&D) to mature technologies to a point where they can be successfully deployed. These decisions are based on expected return from the investment and the cost, schedule and technical risks facing each R&D project. Periodically, the decisions are revisited to see if changes in project performance and cost/schedule/risk estimates warrant a change in project funding. Common approaches to this problem involve either Monte Carlo simulation of outcomes for a decision policy, or optimization of decision variables based on some objective. This paper outlines an approach to R&D project selection where both simulation and optimization are used to determine an investment strategy, given project interdependencies and uncertainties in utility, cost, schedule and technical performance. The problem is formulated as a discrete sequential stochastic decision problem and uses heuristics to narrow the solution space and find a reasonable (though non‐optimal) solution.
7.5.2 Testing a Requirements Pattern Language through Reverse Engineering
Authors: Merrick Peter , Barrow Patrick
Published: November 2014

This paper looks at a case study to reverse engineer an IT system that supports the Health and Safety Executive in making planning recommendations with respect to hazardous installations. It compares a Use Case model created from a requirements specification with a Use Case model derived from an inspection of the built system. The objective is to discover how accurately the final system could be predicted using a series of requirements patterns. Through the application of requirements patterns, it was possible to predict the functionality delivered to a high degree, which suggests this is a useful contribution to the prediction of functionality and thereby to system sizing. This work is part of a bigger project for the Health and Safety Executive investigating improvements to system sizing/effort estimation and its impact on the management of complexity.
8.2.1 Automated Test Generation and Execution for Automotive Embedded Software
Authors: Bouquet Fabrice , Lebeau Franck , Legeard Bruno
Published: November 2014

This article describes a model‐based testing approach that combines automated test‐case and test‐driver generation from Statecharts specifications. It focuses on how the test engineer can control the test generation process, and how he/she specify the relationship between model variables and the interfaces of the system under test. The Test‐driver mappings make it possible to support complete model‐based test automation: from requirement elicitation with Statecharts to test execution and verdict assignment using specific test execution environment. This approach has been used in the context of automotive embedded software validation. Three tools are used to completely support this model‐based test process: the I‐Logix Statecharts STATEMATE modeler, the LEIRIOS Test Generator and the National Instruments test execution environment TestStand. In this article, we illustrate this automated test process on a small car cruise control example.
8.2.2 Verification and Validation as it Applies to Simulation Based Acquisition
Authors: Gibson Ralph D.
Published: November 2014

Weapon systems developed for the United States military are provided by government contractors with the hope that their system is selected for large‐scale production and use. In the past the contractor would build and provide to the military fully functional systems that were then tested to see how well they worked and whether they fulfilled the requirements. As weapon systems have grown more complicated, the ability of the contractor to build multiple systems to support testing has decreased dramatically due to the expense of those systems. In light of this fact, the Department of Defense, in cooperation with industry, has initiated a new procurement program that utilizes modeling and simulation (M&S) to augment weapon system testing. This program is titled Simulation Based Acquisition (SBA). An important factor involved with SBA is the verification and validation of the modeling and simulation models used to supplement system testing. In this paper I will describe the development of SBA, and how it augments system testing. Next, I will address the role modeling and simulation plays in SBA and how it supports system testing. I will then discuss how verification and validation is used for the M&S models as well as the results of system testing.
8.3.2 A Perspective on System Engineering Under the New US Department of Defense Acquisition Policy
Authors: Spenny C.H. , Jacques D.R.
Published: November 2014

The Department of Defense (DoD) acquisition policy, as stipulated in federal documents reissued in 2003, include substantive changes to the manner by which systems are to be defined and developed. Requirements have been replaced by integrated architectural views as the preferred means for documenting the capabilities of a system, and detailed procedures have been defined for converting user needs into required capabilities. The intent is to facilitate integration and interoperability and to assure technology development needs are identified and addressed at the appropriate time during the system development process. This paper provides the viewpoint of its authors on how system engineering might be applied at various times during the DoD requirements and acquisition process in support of these reforms. Challenges associated with implementation of the new policy guidance are highlighted, and tools that might facilitate development for each phase are listed.
8.4.3 Total Ship Design Approach
Authors: Neri Paolo , Dazzi Natalino , Mangiarotti Michele , Palazzo Luca Michele , Cirillo Marco , Traverso Stefano
Published: November 2014

The purpose of Total Ship Design (TSD) is to perform both, Cost and Mission Effectiveness analysis and Cost and Risks analysis. This paper presents a part of this process: the Value Analysis. In particular the discussion will be focused on the Value Analysis methodology set‐up and its main entities, Cost Analysis and Effectiveness Analysis.
8.5.3 Rule‐Based Design Reviews
Authors: Gilb Tom
Published: November 2014

Design reviews would benefit from the support of formal rules. By the use of relevant rules, it should be possible to ensure prior to a review that all the relevant information for a review is present in the design specifications, and that all the minimum review criteria are met. This will ensure management time is not wasted and aid better decision‐making. This paper recommends that the Specification Quality Control (SQC) method be used to do this additional quality control.

In addition, this paper outlines the impact of Evolutionary Project Management (Evo) on the design review process.
10.6 How Many Systems Are There? – Using the N2 Method for Systems Partitioning
Authors: Bustnay Tamir , Ben‐Asher Joseph Z.
Published: November 2014

An algorithm for partitioning a complex system into its independent constituents is developed. The N2 method is used for the problem formulation whereby the objective is to obtain a system presentation in a simple flow. The development of the algorithm is based on graph theory techniques. The algorithm is formulated using graph theory and N2 charts. Several examples are presented to demonstrate the relative ease of the algorithm employment.
10.9 iThe Multi‐dimension Metric for the Assessment of Organizational Complexity
Authors: Song Hualing , Wang Jinli , Reiman Cornelis
Published: November 2014

This article applies the theories and methods of physics, mathematics, dynamics, information science, statistics and management science to develop concepts, definitions, basic theorems and research scopes in the area of management complexity; based on the theories of management entropy, it will establish a new metric for assessing management complexity and vectorial space, as well as mathematical modules. Some methods to enhance managerial effectiveness and efficiency have been proposed as a result of progress in this field. The researches so far have tried to enrich the complexity theories in management circles. As a case study of Shendong Coal Co. Ltd, the multi‐dimension metric assessment of the organizational complexity has been drawn up and verified.
1.3.1 Modeling DoDAF Compliant Architectures The Telelogic Approach for Complying with the DoD Architectural Framework
Authors: Kobryn Cris , Sibbald Chris
Published: November 2014

No industry is more demanding than aerospace‐defense when it concerns the complete integration of software and hardware architectures. Tasked with defending our nascent Information Age economy, the aerospace‐defense industry must be capable of waging Information Age warfare, whose key concepts include information superiority and network‐centric warfare. By most quantitative metrics, aerospace‐defense systems are among the largest and most complex ever constructed. The complexity of individual aerospace‐defense systems (e.g., an aircraft) is frequently compounded when we integrate many of them together to form a system‐of‐systems (e.g., an air traffic control system) that satisfies more global requirements.

This white paper describes a technical approach for improving how we specify system and system‐of‐systems architectures using frameworks in general, and the Department of Defense Architecture Framework (DoDAF) in particular. The model‐driven approach to architectural frameworks explained here, which is based on UML™ 2.0, Telelogic TAU® Generation2™, and Telelogic DOORS®, can substantially improve productivity and quality.

The information contained in this White Paper represents the current view of Telelogic on the issues discussed as of the date of publication. Because Telelogic must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Telelogic, and Telelogic cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. Telelogic makes no warranties, express or implied, as to the information in this document.

The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.

2003–2004 Telelogic AB and PivotPoint Technology Corporation

TAU, TAU Generation, TAUG2, TAU/Developer, TAU/Architect, TAU/Tester, TAU SDL Suite, DOORS, SYNERGY and DocExpress are either registered trademarks or trademarks of Telelogic.

Unified Modeling Language, UML, Model Driven Architecture, and MDA are either registered trademarks or trademarks of Object Management Group.

All other product and service names mentioned are the trademarks of their respective companies.
2.1.1 Revisiting the notion of system ‐ Organizations and Enterprises as systems
Authors: Faisandier Alain
Published: November 2014

This paper reports on a study performed for NATO about the opportunity to tailor and use the ISO/IEC 15288 standard as well as Systems Engineering concepts for such an Organization. The objective of applying the standard and SE concepts was to help prioritise, rationalise or align processes, activities and organisations.

The result of this study was a report for NATO including explanations of the concepts and their potential application, rules for tailoring the standard, as well as a set of recommendations. The recommendations are not reproduced in this paper; only the “system aspects” are considered here, along with its application to NATO as a complex Organization. Some considerations about ANSI/EIA 632 are added to introduce the notion of “enabling product” and “enabling systems“.

This paper discusses how the notion of System can be applied to an Organization and extends the application to Enterprises. The discussion revisits the concept of System in light of current engineering studies and coming back to fundamentals, provides a more precise and more complete definition of this notion. This enhanced definition of System rationalizes the engineering of any kind of system and particularly brings benefits to Organizations and industrial Enterprises viewed as systems. Whether the idea of engineering Organizations and Enterprises as systems is attractive to engineers or others raises questions of feasibility and relevance. Organizations and Enterprises are composed of human beings, hence, defined as “Human Systems“; so the paper ends with some words about human factors that could help or hinder the adoption of these useful rational ideas.
3.1.1 Systems Engineering for the Development of a Decision Support System to Help Manage the Railway Wheel ‐ Rail Interface
Authors: Thanh Vu , Roberts Clive , Williams John , Stirling Alan , Madelin Keith
Published: November 2014

Interactions and interrelationships between the railway wheel and rail are complex, and managing them effectively would require an integrated systems approach. This paper describes how systems engineering has been applied to the development of a decision support system for the management of the railway wheel – rail interface. This work can be considered as a case study on the application of systems engineering in the railway industry. Stakeholder requirements, system functional requirements and architectural design of the system are described. A brief description of the prototyped system and its initial applications are also included.
3.1.3 Applying quantitative methods for architecture design of embedded automotive systems
Authors: Larses Ola
Published: November 2014

Architecture design is often referred to as an art, performed in the conceptual stages of a design process. However, it can be supported by quantitative methods. At the highest level of abstraction a goal oriented approach is applicable. This can be realized by a keyfigure based methodology similar to the management directed Balanced Scorecard.

The automotive industry requires that a system architecture is optimised not only for a single product, but for reuse over a range of products, and also for reuse over time with continuous improvements. To achieve these goals the product should be modular. Keyfigures are useful for managing trade‐offs but do not easily describe modularity. For this purpose DSM (Design/Dependency structure matrix) and cluster analysis is more useful. A combination of the methods is proposed for design of automotive control system architectures. The proposed method has been applied and evaluated in architectural work at Scania CV.
3.2.3 Systems Reliability Demonstration
Authors: Benyamini Zvi , Zonnenshain Avigdor
Published: November 2014

This paper discusses the issue of system Reliability Demonstration. The classical reliability demonstration methods are discussed, as well as the difficulties associated with application of these methods in today's complex system and competitive project environment. Some insights are discussed, regarding the changes required in reliability demonstration methodologies, in order for them to be effective in today's environment ‐ from both RAFAEL's experience and trends throughout the world. The methods presented are being successfully implemented in several projects.
3.3.1 Quantifying Cost Risk Early in the Life Cycle
Authors: Kenley C. Robert , Nail James
Published: November 2014

A new method for analyzing life cycle cost risk on large programs is presented that responds to an increased emphasis on improving sustainability for long‐term programs. This method provides better long‐term risk assessment and risk management techniques. It combines standard Monte Carlo analysis of risk drivers and a new data‐driven method developed by the Hoy and Hudak (1994). The approach permits quantification of risks throughout the entire life cycle without resorting to difficult to support subjective methods. The Hoy‐Hudak methodology is shown to be relatively straightforward to apply to a specific component or process within a project using standard technical risk assessment methods. The total impact on system is obtained using the program WBS, which allows for the capture of correlated risks shared by multiple WBS items. Once the correlations and individual component risks are captured, a Monte Carlo simulation can be run using a modeling tool such as Analytica to produce the overall life cycle cost risk.
3.4.2 How the Pro‐Active Program (Project) Manager uses a Systems Engineer's Trade Study as a Management Tool, and not just a Decision‐Making Process
Authors: Felix Arthur
Published: November 2014

This paper takes the Program (Project) Manager's (PM or manager's) point of view in strategic decision management when trade studies are used as the decision‐making tool. The application of trade studies as a tool in the strategic decision management process transcends commercial and defense industries. Industry, government, and academia projects can benefit from using this robust, structured decision‐making process discussed herein as a management tool in overseeing and providing guidance in the project's direction. The trade study created and developed by the systems engineer for decision‐making should follow a clear pre‐defined decision‐making process. Such a process would result in unambiguous interpretation and understanding thereby improving buy‐in from all stakeholders. The focus of this paper is the major stakeholders' acceptance, buy‐in and in understanding the underlying information and knowledge used in the trade study decision‐making process.

The PM is responsible and accountable for the successful execution of a program (project) given the necessary resources. As part of those duties, he/she is responsible for making the major decisions of the program and will also be accountable for those decisions. The leadership/executive management can and should ask the PM to explain, defend, and demonstrate the decision‐making methodology used in each major decision. Those demanding answers may include but are not limited to Director level, Vice‐President/ President of an organization, Board of Directors, contracting agency, Government representative, and/or any other sponsoring stakeholder. There may also come the expectation by major stakeholders to reproduce the major steps in the methodology of the decision‐making process. This expectation should in‐turn, be demanded by the PM and come as no surprise to the systems engineer developing the decision making study thus establishing and enforcing accountability. The process used for the trade study in arriving at the recommended decision, as a matter of good engineering/business practice, should be documented and archived in the program artifacts for future reference.
4.3.2 Engineering and Implementing RMS Engineering's DTC Metric
Authors: Redman F. Quentin , Stratton George , Casey Ed
Published: November 2014

Architecting a product requires a defined set of requirements for the finished product; e.g. size, weight, volume, range, power, color, cost, payload, etc. One very necessary requirement is the anticipated product production cost. Failure to set the production cost requirements at design kick‐off allows for unexpected and unacceptable production costs. Previously, all too often, programs were allowing establishment of the production cost goal to slip, or they would wait for their customer to establish it for them. Raytheon Missile Systems' (RMS) Engineering Directorate has specified that all development programs will now establish a production cost goal using the Design‐To‐Cost (DTC) metric described within this paper and will monitor their design progress towards meeting this goal. Each program's DTC metric is now collected monthly and reviewed by senior management. This paper discusses creation of the RMS DTC metric, the metric's details and its implementation across RMS.
5.3.2 Didactic Recommendations for Education in Systems Engineering
Authors: Muller Gerrit
Published: November 2014

Teaching systems engineering differs from teaching a mono‐disciplinary course, because the focus is much more on skills and less on transferable facts. The teacher must trigger a learning process in the students that stimulates the student to become active with the subject in a perceptive, reflective, and explorative way. This paper provides a number of recommendations for interaction, illustration, soft skill development, the use of media and student feedback.
6.2.2 Measuring the Performance of the Risk Management Process
Authors: Roberts Barney B. , Kitterman Richard
Published: November 2014

Measuring the performance of the risk management process is difficult in that there is generally no physical outcome to measure. The best risk management processes ensure that nothing “bad” happens, hence nothing to measure. Even when something “bad” happens, it could have been predicted by the process, accepted by the project, and the project got a bad roll of the dice, and the project may even face cancellation. But would that outcome indicate that the risk management process malfunctioned? So the problem faced by the risk management community is that either a good or a bad outcome can be a result of the performance of the risk management process or simply good or bad luck.

The professionals in the risk management community and the measurement community have posed several possible ways to measure the performance of the process. Those techniques are presented along with suggestions as to how the project manager may use the metrics to make adjustments to the process.
6.3.1 The MSOCC Data Switch Replacement: A Case Study in Elicitating and Elucidating Requirements
Authors: Kasser Joseph E. , Mirchandani Chandru J.
Published: November 2014

This paper is a case study of a situation in which a soft‐systems methodology coupled with an object‐oriented approach for viewing the requirements was used in a complex environment to gather a set of requirements. By considering the cost, priority, and risk attributes of the requirements, as well as clarifying the wording of the requirements for verifiability, an optimal systems architecture and development process was achieved in a relatively short period of time compared with the standard systems engineering process. Moreover, the Systems Requirements Review was deemed complete and comprehensive by the customer.
7.1.1 Integrating Views in a Multi‐view Modelling Environment
Authors: El‐khoury Jad , Redell Ola , Törngren Martin
Published: November 2014

The development of modern technical systems requires the close collaboration of various specialist teams and engineering disciplines in order to reach the expected complex functionality. Even though working with the same system towards the same goal, developers from the different domains use their own specific tools, providing their own specific views of the system to be developed. For the successful integration of the efforts from each of these disciplines, the different views produced need to be appropriately integrated, preventing any inconsistencies and divergences from creeping into the system design.

We present an approach to multi‐view modelling which systematically integrates the two generally accepted complexity reduction techniques of hierarchical decomposition and multi‐viewing. While these techniques are common practice in many modern design tools, the approach presented in this paper defines how the inter‐view relationships can be used to tightly interweave the views' hierarchies. This provides a good basis for an information sharing environment enabling model based, multi‐disciplinary development.

A small case study is used to exemplify how the proposed method simplifies the process of allocating system functions to a hardware architecture in a truck.
7.2.2 Learning from Lessons Observed–Mitigating Resistance to SE Process Change
Authors: Holzer Thomas H.
Published: November 2014

Changing a Systems Engineering process culture is difficult. There can be organizational and individual resistance to change that needs to be effectively overcome. As good systems engineering practices call for, at the start of the change activity the process change team needs to look back on the problems faced by similar programs. Most importantly, the team must learn from those ‘lessons observed’ and implement improvements in conducting their activity. Fifteen critical lessons observed about resistance and the mitigations applied are summarized. A highly successful process improvement program was achieved by applying mitigations learned from earlier problems. The lessons apply to changing SE processes in a government and commercial organization. For anyone seeking to change the culture and systems engineering processes, acquisition methods or business methods, these findings are their head start to identifying problems and reducing change activity failures.
7.2.3 Tailoring Systems Engineering Lifecycle Processes to meet the challenges of Project and Programme applications
Authors: Adcock Richard David
Published: November 2014

The application of Systems Engineering to real world problems relies upon an understanding of lifecycle and process. Many attempts have been made to produce generic models of Systems Engineering process, which can then be applied to real world problems. More recent Systems Engineering (e.g. ISO/IEC 15288 and ANSI/EIA 632) standards have taken a more abstract approach. The standards describe a lifecycle and process framework, and give guidance on how to tailor the framework to specific problems. This paper explores the approach taken by the standards to describe Systems Engineering in this way. The difference between a project and a programme are defined; and the application of lifecycle tailoring to each is discussed. Finally, a generic lifecycle framework is described, and examples of its application given.
7.3.3 A Lifetime Extension Strategy for Simulation Models
Authors: Grainger Steven
Published: November 2014

Using a systems engineering approach, a lifetime extension strategy for legacy simulation systems is presented. This lifetime extension strategy establishes a bridge allowing legacy simulation systems to participate in a larger more diverse simulation community. Previous recommendations to solve this legacy simulation problem have been narrow in scope viewing the solution in terms of a single technical solution. However, like systems engineering, this strategy describes a solution using a multilayered interdisciplinary approach. This approach takes advantage of existing technologies across the hardware and software spectrum and presents a five‐year convergence strategy.
8.2.2 A Mark‐Up‐Language to Support the Exchange of Requirements during a RFQ
Authors: Kaffenberger Ruediger
Published: November 2014

Requirements are the foundation of the project. Consequently the issues of requirements management and requirements engineering are emphasized in the context of the preparation of acquisition activities and during the early phases of the development project. In contrast, the role of requirements management and engineering during the acquisition phase has received negligible attention. In a world where sub‐system developers compete against each others for development contracts offered by system integrators effective requirements management and engineering during the bidding phase is vital for success. A smooth exchange of requirements is needed in this situation but there are numerous obstacles. In this paper a solution for the necessary kind of requirements exchange is proposed. It is based on the possibilities of XML and the STEP information exchange standards.
9.3.1 Specialised Requirements Management system for Maintenance Service Industry
Authors: Chen Yang‐Cheng‐Kuang , Sackett Peter
Published: November 2014

Companies in major aerospace, automotive and electronics consumer products industries now consider Requirements Management important in realizing business performance. As companies review and enhance their product development processes they will increasingly demand various types of requirement management capabilities. There is lack of clarify on how to use Requirements Management effectively even in conventional product development applications.

This paper identifies a research and applications gap in the Maintenance and Service Requirements Management System domain. The authors identify the special needs of the sector classified as Requirements Derived Service Maintenance. Through a case study in high end mass market consumer electronics they illustrate the application of the requirement management technique in the maintenance service environment.
9.3.3 System Engineering Application to Knowledge Intensive Service Industry Development Strategy and Mechanism Formation
Authors: Wang T.J. , Chang Larry , Chin David
Published: November 2014

The Taiwanese government realized the fact that the service industry has reached 67.8% of the national GDP in 2003, also recognized the successful outcome such as GE and IBM companies to shift from manufacturing to knowledge intensive service business. In order to keep a good momentum of GDP growth rate for Taiwan economic development, the government has to set out for a new industry development policy through Service Industry Program, which could meet with the needs of the existing service industry. It is very crucial to enhance their capabilities with modern technology and management, encourage them to join the feasible and profitable pilot system service projects. The major purpose of this program is trying to generate higher value added and/ or new business with innovation technology and new business model to create a new system service industry, which can be duplicated in the global market.
10.1.2 Canadian Capability Engineering Process Foundations
Authors: Mokhtari Marielle , Lizotte Michel , Lam Sylvia , Lalancette Claire , Dussault Geneviève , Couture Mario , Bernier François
Published: November 2014

This paper describes the fundamental characteristics (goals, scope, stakeholders, inputs/outputs and conception principles) upon which will be based the development of the first version of the Canadian Capability Engineering Process being investigating by the Department of National Defence and the Canadian Forces, to bridge the gap between the Capability‐Based Planning and Acquisition processes.