bluuebunny/crossref_metadata_2025 huggingface dataset:
1.5.1 The C‐17 and BC‐17X: Systems Engineered Transport Aircraft for the World
Authors: Jackson Scott
Published: November 2014

The USAF and RAF C‐17 and the Boeing‐funded commercial derivative, the BC‐17X, are aircraft with unique requirements. The C‐17's capabilities include austere airfield landing, short takeoff and landing capability, and benign loading and unloading. Systems engineering (SE) is applied to the customer‐required Producibility Enhancement / Performance Improvement (PE/PI) and to Boeing‐initiated projects, such as Must Cost projects to improve aircraft affordability. PE/PI projects include the Dual‐Row Airdrop capability. Must Cost examples include the Wheel, Brakes, and Tires Alternate Configuration. Other Boeing‐initiated projects include the Extended Range project. BC‐17X efforts include commercial certification and the conversion to commercial missions. All of these changes have been accomplished through the fusion of SE and the expediting of changes through the Change Breakthrough Initiative (CBI). The final area of SE application is the development of the Flexible Sustainment system for aircraft support.
1.5.2 Systems Engineering in Aircraft System Design
Authors: Krus Petter
Published: November 2014

In order to be competitive, companies have to provide products that perform more and better than earlier ones at a lower cost. This inevitably leads to a higher density of functionality in products, and as a consequence there is a trend to integrate different technologies such as mechanical, electrical and fluid subsystems and embedded software. More of the engineering effort is therefore placed on system architecture and system integration. It also becomes more important to find and to express requirements more exactly in order to be able to emphasise the right ones. It also means that the product has to more tailored the customer needs and that analysis of systems of systems where the product is to operate, becomes more important.

There are several levels of design from requirement analysis and system architecture down to detail design There is a clear danger that systems engineering activities are performed only at top level of a design. In order to have an impact on the product development process it must, however, permeate all levels of the design in such a way that a holistic view is maintained through all stages of the design.
1.5.3 Lifecycle Value Framework for Tactical Aircraft Product Development
Authors: Hallander Ingrid , Stanke Alexis
Published: November 2014

Due to a dramatic reduction in defense procurement, the benchmark for developing new defense systems today is mission effectiveness at an affordable cost, i.e. best value. In an attempt to encircle a more holistic perspective of value, lifecycle value has evolved as a concept within the Lean Aerospace Initiative, LAI. The implication of this is development of products incorporating lifecycle and long‐term focus instead of a shortsighted cost cutting focus. The interest to reduce total cost of ownership while still improving performance, availability, and sustainability, other dimensions taken into account within the lifecycle value approach, falls well within this context. Several factors prevent enterprises from having a holistic perspective during product development. Some important aspects are increased complexity of the products and significant technological uncertainty. The combination of complexity in system design and the limits of individual human comprehension typically prevent a best value solution to be envisioned. The purpose of this research was to examine relative contributions in product development and determine factors that significantly promote abilities to consider and achieve lifecycle value. This paper contributes a maturity matrix based on effective practices and lessons learned through extensive interview based case studies of three tactical aircraft programs, including experiences from more than 100 interviews.
3.5.3 Managing National Defence Using a ‘Linked‐Portfolios’ Approach
Authors: Moon Terry T. , Cook Stephen C.
Published: November 2014

The current, rapidly changing technical, financial, national security and societal environment presents many challenges to those entrusted to develop and maintain national defence capability. It has become increasing obvious over recent years that the classical methods of undertaking these tasks have been found wanting around the world. This paper examines the drivers for defence capability management and proposes an improved concept, derived from systems theory, based on aggregating capabilities into portfolios for the duration of their lifecycle: from concept through to disposal. The rules for determining portfolio membership are discussed and the advantage of linking portfolios into an overall structure of portfolios is pursued. The paper concludes by exploring methods of evaluating portfolios.
3.5.4 On Flexibility in System Design
Authors: Saleh J.H. , Kaliardos W.N. , Hastings D.E. , Hansman R.J. , Newman D.J.
Published: November 2014

This paper explores the concept of flexibility in system design. Embedding flexibility in systems has become increasingly important in recent years due to the rapidly changing markets that the systems are designed to serve, their fast‐evolving technology base, and the progressively longer operational lifetimes. The concepts discussed herein are intended to persuade system designers to explicitly consider issues of flexibility early in the design process.

Flexibility is discussed in the context of two products of design: physical systems (e.g., spacecraft) and information systems (e.g., cockpit decision process). Separate frameworks are used to analyze each type of system, based upon distinct research directions.
6.5.2 Real‐Time Event Risk Assessment (RTERA) Using Artificial Neural Networks
Authors: Gronlund R.B. , Simcock A.L.
Published: November 2014

This paper describes a novel technique that is being developed to create a decision aid for Real‐Time Event Risk Assessment (RTERA). RTERA allows the user to enter Real‐Time Events (RTEs) during a mission to identify and prioritise risks in relation to the mission. This decision aid uses Conventional Programming Techniques that use an Algorithmic approach to reach a specific result and also use Artificial Neural Networks (ANNs) to interpret RTEs and produce relative risks to the mission. Information on the current mission is entered, including which systems are to be used, the area of operation and the environmental conditions. The RTERA ‘user’ will be able to choose from a list of RTEs that will be determined during the development phase by a risk analysis of the platform/mission combination. The model then uses this information to determine a list of risk factors and their priorities in relation to the mission. The use of ANNs and Conventional Programming Techniques allows for previously undefined missions to be entered and appropriate risks to be displayed.
7.5.2 Internal Capability Assessments
Authors: Bollinger Peter , Miller Darren
Published: November 2014

This paper describes an internal capability assessment against EIA/IS‐731 expanded to cover a range of engineering disciplines1 – namely software, hardware and logistics engineering – in addition to Systems Engineering. It also compares the outcomes, in terms of resources and result, with a subsequent “full‐blown” external assessment against the Software Engineering Institute (SEI) CMMI model, and concludes that internal assessments can, in certain circumstances, provide valuable results at a fraction of the cost of formal assessments.
8.5.1 What Is The INCOSE Guide To The Systems Engineering Body Of Knowledge (Sebok)?
Authors: Leibrandt Robert
Published: November 2014

This paper seeks to explain the thinking behind the decision to develop an INCOSE Guide to the Systems Engineering Body of Knowledge (SEBoK). You will learn; how the concept was conceived; how the requirements were determined; what the process for development and delivery will be; where there are similar initiatives that will add to the benefit; and how it may be used by a variety of user types. The guide will meet their needs whether the user is looking for detailed information complete with hyperlinks to the major contributing documents or is just seeking a basic understanding of what systems engineering is all about.
8.5.2 Systems Engineering Heuristics – Is there a need to innovate, integrate and invigorate?
Authors: Mar Brian W. , Morais Bernard G.
Published: November 2014

This paper reports the results of a survey to evaluate the current systems engineering heuristics and determine if there is a need to innovate, integrate and invigorate the existing set. By identifying the trends and needs of systems engineering heuristics, a research agenda for SECOE can be improved. This paper uses the Pragmatic Principles (DeFoe, 1993) as a bench mark for systems engineering heuristics and the INCOSE 2000 proceedings as the state of the art of engineering practice to identify the heuristics many systems engineers support. The results of this investigation indicates that there are heuristics that are generic for both product and product development systems (process), and others that are focused on product not process, but there is not complete agreement on any heuristic. The FRAT concept (Mar, 1991) is used as a framework to organize and simplify these heuristics.
2.6.4 Active Co‐operation Networks – Key to a Competitive Advantage in a Global Marketplace ?
Authors: Wieser Michael , Schulz Armin , Vollerthun Andreas
Published: November 2014

In recent years rapid developments in information technology have dramatically changed the availability of information. It is now almost possible to get any information at any place in the world at any time. The economy has adapted to these changes and will continue to do so in the future. To keep up with competitors strategic alliances can be observed in many markets. Virtual enterprises and communities are the consequence. Due to the globalisation of markets the economy is getting increasingly networked and consequently complex. It will be significant in future to analyse and model these processes and it must be clarified to what extent systems engineering methods/tools can be used to handle this complexity.

The strategy how to initiate and scale modern networking is described on the basis of two projects in the European satellite business.
7.6.2 Completeness of Conceptual Models Developed using the Integrated System Conceptual Model (ISCM) Development Process
Authors: Gonzales Regina M.
Published: November 2014

There exists a semantic gap between developers and users of systems. Requirements engineering is addressing this gap by introducing requirements methods, techniques, and processes that facilitate greater understanding of the customers and users needs. Many of these methods and techniques rely on the analyst or developer to model the product domain. With the complexity of systems developed today, this can be a formidable task. These systems have multiple users with diverse needs and require the integration of multiple domains in order to develop them.

Customers, users and developers are the stakeholders for a system. Increasing the communication and decreasing the semantic gap between diverse stakeholders are the aims of the Integrated System Conceptual Model (ISCM) Development Process. This process uses a combination of elicitation methods and techniques. However, the stakeholders create the initial models for the system based on their own mental models of a proposed system. This paper focuses on completeness indicators proposed in order to regulate the ISCM process.
7.6.4 Capability Dynamics: An approach to Capability Planning and Development in Large Organisations
Authors: Flint Shayne R , Boughton Clive V
Published: November 2014

This paper describes Capability Dynamics, a synthesis of system dynamics, control, agent based simulation and distributed systems techniques, which aims to increase the likelihood that decisions made throughout and at all levels of an organisation contribute in a coordinated way to satisfying the organisation's requirements and those of its stakeholders.

The focus of Capability Dynamics is on the identification of systems that need to be developed, modified and retired within a whole‐of‐capability, and whole‐of‐life context of required capabilities and evaluation criteria. It is left to other research and existing systems engineering practice to improve individual systems within this context.
8.6.1 Project Kookaburra: Educating Systems Engineers Using Design of Unmanned Aerial Vehicles
Authors: Smith E. Price , Bollino Kevin , Rogers Anthony J. , DiSebastian John D.
Published: November 2014

This paper presents the results of an educational initiative to bring aircraft systems design into the systems engineering curriculum at the United States Air Force Institute of Technology. The project spans preliminary design, mission analysis, aircraft modification, test planning, flight testing and system analyses for a small multi‐mission unmanned aerial vehicle system. Educational and mission outcomes are presented.
8.6.2 Providing an effective learning environment for future practitioners of systems engineering
Authors: Godau Ralph I.
Published: November 2014

Adapting the learning experience to the needs of the students and the industry that employs them is critical if any university or educational consultant is to provide an effective learning environment for future practitioners of systems engineering. This paper explores a methodology used by one academic institution to facilitate learning in the Systems Engineering Masters Program.
1.7.2 System Approach of Electric Utility Restructuring in Developing Countries: An Outlook in Asia
Authors: Leeprechanon N. , Moorthy S.S. , David A.K.
Published: November 2014

The design of a suitable power market is a major concern, particularly for the deregulation of the electricity supply industry (ESI) in Western countries. This has led to a realization of the need for reform and competition in developing countries also. However, there are fundamental differences between the two groups of economies in the maturity of the ESI structure, economic priorities and the role of the state in development. This paper, therefore, synthesises a model of reform which is sensitive to these realities. Consequently, the outlook is different from the prevailing tendency to simply transpose experience from elsewhere. The core issue that we identify is the approach to the transmission system. The case of the Electricity Generating Authority of Thailand (EGAT) is used as the main reference point due to its medium size and orientation towards restructuring. In addition, short sections on Sri Lanka and China are included to broaden the relevance of the discussion.
3.7.1 Creating High Value Future Architectures
Authors: Parnell Gregory S.
Published: November 2014

Government and commercial organizations have realized that system architectures (complex large‐scale systems of systems) are critical to their future success. Architecting involves many decision‐makers and stakeholders; significant future uncertainties; and complex value trade‐offs. System architects, systems engineers, and systems analysts must develop and use objective, credible, and traceable methodologies to create high value future architectures. This paper provides a process to develop a system architecting methodology to meet this need.
3.7.2 Discovering the Architecture for Product X
Authors: Ring Jack
Published: November 2014

This paper describes how the architecture for a high tech product was discovered by a work group of diverse individuals who had little prior grounding in systems engineering principles or methods. This report provides a running account of the iterative hypotheses and tests that enabled the traverse from problem situation to solution specification. The resulting architecture and rationale were understood and supported by all project members. The architecture differed significantly from pre‐project concepts but clearly simplified both the product and the product realization process. A companion infrastructure was defined, as well. A post‐project survey indicated that the client felt the effort was worth both the time and expense and saved them from several “bad ideas.”
3.7.3 The Architecture View Set in Action
Authors: Morgan Tara , Frank Rodger
Published: November 2014

Architecture Based Design™ (ABD™) is a system engineering design process being used at Lockheed Martin Management & Data Systems (LM M&DS). This process is based on the use of an Architecture View Set (AVS) to capture the executing architecture of a system This paper provides a case study of the use of the ABD™ process and the AVS to design and develop a system on a current program. These experiences are presented through a series of observations and conclusions about the impact of this methodology and its relationship to the following topics:

Incremental Development Cycle

Use of Composite Views

Power of the Meta‐CASE Tool

Customer Presentations

Requirement Traceability

Documentation Methods

Relationships between the Views

Executing vs. Construction Aspects

Test Program
3.7.4 Validating a Commercial Product Architecture
Authors: Adifon Leandre , Lentz V. A. , Lerner Bruce , Marvin Daryl J.
Published: November 2014

Commercial products in existing industries have an architecture. The functional architecture is implicit from the domain, as envisioned by the founder of the company. The only representation of the functional architecture may be enveloped in the physical architecture. The physical architecture has evolved over time to keep up with innovation and changes in the marketplace. As technology is investigated and sometimes subsequently inserted, the occasion arises to more formally reassess the functional architecture and validate the evolved Physical architecture in regard to expanded functionality and new technology. Today, independent modifications in the various pieces of the product drive substantial changes in the physical architecture. This paper addresses the journey of one commercial company to validate the architecture of the flagship product. The methods and approach will subsequently be used with the other product lines. The goal is a modular architecture with standardized interfaces to enable significant decreases in time to market, and reduction in the cost of production and support. The paper addresses 1) the business drivers for taking the time and resources to do the validation, 2) the methods employed and 3) the plan for evolving the engineering and operations within the company to realize the advantages sought when starting the effort.
4.7.2 Getting to Requirements: The W5H Challenge
Authors: van Gaasbeek James R , Martin James N
Published: November 2014

Most systems engineers have a clear idea on how to transform a set of top‐level requirements into detailed requirements that drive subsystem design and development. However, very few know an effective manner of “discovering” these top‐level requirements themselves. It is often assumed that they will “appear” from somewhere. This paper describes a generic W5H technique that works well in extracting the true requirements from various stakeholders. W5H is shorthand for What, Who, Where, When, Why and How. The W5H technique is a handy mental framework to assist the engineer in transforming the needs, wants, and expectations of various stakeholders into a cohesive and complete set of top‐level requirements.
6.7.3 Towards Modelling and Analysis of Internet Open Trading Protocol Transactions using Coloured Petri Nets
Authors: Ouyang Chun , Kristensen Lars Michael , Billington Jonathan
Published: November 2014

Electronic Commerce (E‐Commerce) is a rapidly growing area with new companies entering the market place and existing companies moving their commercial operations onto the Internet. The Internet Open Trading Protocol (IOTP) is a standard being developed by the Internet Engineering Task Force aiming at providing an interoperable framework for E‐Commerce over the Internet. In this paper we use Coloured Petri Nets (CP‐nets or CPNs) to construct an executable model of the IOTP Deposit Transaction. Due to the formal semantics of CP‐nets, this CPN model constitutes an unambiguous specification of the Deposit Transaction and allows us to conduct a formal analysis of the Deposit Transaction. This initial analysis has already revealed minor deficiencies in the Deposit Transaction procedures demonstrating the benefit of applying formal methods for the specification and development of complex communication protocols.
7.7.4 A System Approach to the Conceptual Design of an Upgrade Mission Payload for Maritime Helicopters
Authors: Kusumo Raden , Sinha Arvind K. , Scott Murray L.
Published: November 2014

The global budget climate has laid restrictions on the design and development of new military aircraft to meet the demands of additional mission capabilities. To enhance mission capabilities, mid‐life upgrade of in‐service aircraft, involving placement of advanced technology mission systems onboard, is acknowledged as a cost‐effective option. To facilitate the mid‐life upgrade process, a “Decision Support System” is required to identify the state‐of‐the‐art mission systems that will provide the required mission capabilities. An “Integrated Decision Support System” (IDSS) that analyses the mission requirements holistically, to identify mission systems that enhance the capability of the aircraft is presented in this paper. A brief outline of the IDSS framework developed by a systems approach is presented initially, followed by a detailed discussion of the ‘Mission Payload Design’ (MPD) sub‐model. The MPD sub‐model prioritises the identified mission systems based on their relative dependence and degree of contribution in mission accomplishment, to formulate mission payload alternatives for aircraft upgrade.
9.1.1 An Experiential Approach for the Training of Systems Engineers
Authors: Fisher Jack , Terry Kathleen
Published: November 2014

For the last five years, the California Institute of Technology Industrial Relations Center has provided systems engineering training for engineers from the Northrop Grumman Corporation. The program has evolved over this period and is recognized by the participants and Northrop Grumman management as an effective means of training prospective systems engineers. The course includes seven class meetings over a period of six months with an instructor‐defined class exercise. The class of typically 24–28 students is divided into two teams. The exercise requires each team to develop a system with a number of pre‐defined steps that are described by the instructor tutorials. The exercise originates with an instructor‐written Operational Requirements Document and culminates with a student‐prepared Preliminary Design Review and life cycle cost estimate. The tutorial material prepares the students for each step in the system development process. Each 8‐hour, monthly class meeting involves a tutorial by the faculty as well as student team reports on their progress with the exercise.
9.1.2 Legacy Software Testing – A Current Methodology
Authors: Gibson Ralph D. , Chapman Michael D.
Published: November 2014

In the simulation world, software upgrade is more common than new development. Thus it is extremly important to ensure proper operation of of the simulation model as it is enhanced. The big question is how does one keep the current model operating correctly while adding new capabilities? The Model Development Team at the Air Combat Environment Test and Evaluation Facility, Patuxent River Naval Air Station, Maryland, has developed an approach that is useful in making sure that the current simulation model keeps its current capabilities operating correctly as well as testing any new capability that is added. The purpose of this paper is to present the approach used by the Model Development Team to answer the question put forth. This paper discusses the software development and maintenance criteria used as the overarching guide for testing. The testing process used and how this process ensures that the model meets the criteria is then given. Specific test examples and expected output are provided as a model testing approach. Finally, the future of development testing for the Model Development Team is presented.
9.1.4 Comparison of Residential Broadband Systems and Services
Authors: McNeill Ronald P.
Published: November 2014

This paper provides a high‐level overview of residential broadband technologies. First, the paper describes the two main broadband technologies currently offered in the consumer market: DSL (digital subscriber line) and the cable modem. Next, the paper provides a view on some of the factors that are generating demand for residential broadband. This includes bundled services, interactive television, HDTV, and telecommuting. Lastly, the paper touches on future residential broadband technologies such as fixed wireless services and fiber optics. The paper demonstrates that there will be a significant increase in demand for home broadband services over the next several years. As costs continue to decrease, new and better technologies will continually be developed and home broadband use will become ingrained in our daily lives.
9.1.6 Generation of a Service Language for the Resource Reservation Protocol Using Formal Methods
Authors: Villapol María E. , Billington Jonathan
Published: November 2014

The Resource Reservation Protocol (RSVP) is a signalling protocol, which transports and maintains Quality of Service (QoS) information along the path of a data flow. It is being modelled and analysed using a verification methodology proposed by (Billington et al 1986). The methodology includes a service and protocol specification. This paper is focused on the definition, modelling, and analysis of the RSVP service specification. A service language including all the possible service primitives sequences was also generated. It is being used as part of the verification process of RSVP. Also, this service specification will allow other resource reservation protocols to be developed that satisfy this service.
9.1.7 Prediction of SAP based ERP Systems Capacity Using Stochastic Processes and Spectrum Analysis
Authors: Zuniga Roberto B.
Published: November 2014

This paper presents an innovative approach to predict system resources consumption within an ERP production environment running SAP R/3 applications. It combines ‘Discrete Event’ modeling technologies with Digital Signal Processing (DSP) methodologies for analysis of stochastic (random variable described) phenomena. The approach consists in considering the samples collected by system monitoring tools as discrete stochastic signals representing system resources behavior. These signals are filtered and processed by Time – Frequency transformation algorithms to extract a set of sinusoidal mathematical sequences that characterize the periodicity of each signal. These set of discrete frequency components uniquely identifies system resources (CPU, Disk IO, etc) behavior as effected by the transaction been executed.
5.2.4 FRAT – A BASIC FRAMEWORK FOR SYSTEMS ENGINEERING
Authors: Mar Brian W. , Morais Bernard G.
Published: November 2014

Systems engineering can be difficult to implement if the words and framework are not clearly understood by all parties involved. INCOSE has adopted a definition of systems engineering; yet a debate continues over what systems engineering is and how to do it. The authors have developed over a period of many years the FRAT framework for describing the process used to implement systems engineering for any task, the name for which is derived by the first letters of the series of words function, requirement, answer, and test. FRAT is based on the hypothesis that four views of a system are needed to completely define any system. These views are what it does (functions), how well the functions are performed (requirements), a physical or actual description of the system (answers), and verification and validation of the system when completed (tests). The FRAT framework has been validated by reviewing all the papers published at INCOSE proceedings. It is important to recognize that the system of interest (a product) is produced by another system (a production system). Both of these systems can be described by the four FRAT views when developing a shared vision of the development process as well as the product that is developed.
2.1.4 Use Case Development Integrated in a Systems Engineering Environment
Authors: Smith Darold K.
Published: November 2014

The ability to capture stakeholder interests early in a system's evolution is critical to successful deployment of the system over its lifecycle. The concept of capturing user functionality as use cases is beginning to be used in systems engineering. Most use case content development consists of the manual process of documenting use case information as text in a CASE tool or in a word processor.

This paper describes one approach to integrating use case development in the systems engineering environment. Each element of the user‐defined use case template is an object in the SLATE1 database. The benefits include: capturing relations among user needs, use cases, requirements, architecture, implementation, product lifecycle, affected parties, and external CASE tools.

The collaborative environment assures that all users work with current data. Custom reports and metrics allow tracking use case progress, issues, etc.
1.1.3 Heuristics in Planning for Advancing Technologies: a Comparison of Heuristics Used on the X‐33 Program vs. the Heuristics Used on the Apollo Program
Authors: Spurlock D. M.
Published: November 2014

Projects in advancing technologies require planning like any project in any other field. Unlike most projects, those in advancing technologies will benefit from using architectures that are open and evolvable. By comparing the planning of the Apollo lunar landing and the X‐33 projects, certain heuristics can be identified to aid future project's planning. A basic set of heuristics can be identified to be used by projects that are part of an advancing technological field. This paper looks at heuristics from Apollo and X‐33 planning. This paper also presents results from a survey of current engineering planning and how the heuristics identified in the main body of this paper are or are not used in current engineering planning.
2.1.3 Applying Systems Engineering to Clinical Trials
Authors: Bamdad Julie A.
Published: November 2014

The clinical trials industry has remained largely untouched by the application of systems engineering principles, perhaps due to the intangible nature of its product. This complex and growing industry could benefit greatly from a more widespread application of systems engineering. Work in clinical trials Data Coordinating Centers (DCCs) includes managing unique tasks and complicated flows of communication, processes that systems engineering can improve. The focus narrows on one study group as a case study, as some systems engineering principles are explored and suggested applications of them are made that could improve workflow and alleviate problems.
3.1.2 Architecting the Raytheon Production Cost Model
Authors: Stratton George , Redman F. Quentin , Kehret Matthew
Published: November 2014

The Advanced Systems Economic Analysis (ASEA) Department in Systems Engineering at Raytheon Missile Systems (RMS) was presented with the challenge to develop a software tool to track and report costs on production programs. This challenge was driven by the Guided Projectile product line, which had an immediate need to provide production cost projections for three similar programs. The goal for the tool was to track and manage costs to meet the Design to Cost (DTC) goal for each production program. The tool tracks the recurring system costs and accumulates the cost of components in a hierarchy which allows each model user to derive the necessary information needed to manage their own program's cost.

RMS Information Technology (IT), in conjunction with ASEA, developed the Raytheon Multi‐Program Production Cost Model (RPCM). This cost model provides Raytheon with a cost tool that can provide management and control cost, thus aiding the company goal of providing quality products at the least cost. Cost data is presented to developers and managers in a form that allows them to make decisions in a timely manner. With this cost tool, they are able to understand projections of cost for baseline programs, and evaluate design changes, preplanned product improvements, productivity improvements, changes to business practices, and other factors which impact production costs. This tool is different from all currently available COTS tools is the ability to track costs and take advantage of commonality across all production programs.
3.2.1 Economical Assessment of Product Platform Concepts under Uncertainty
Authors: Steuer Christian , Whitcomb Clifford
Published: November 2014

One major problem of manufacturing companies is the contradiction to offer a wide variety of products, meeting diverse customer needs at low or competitive costs. Engineers and managers agree that modularization of products or so‐called product platform strategies could help to achieve the necessary variety in products (mass customization) the market is demanding at relative low costs.

This paper focuses on financial valuation of product platform concepts in the strategic product‐planning phase. The challenge is to incorporate market uncertainty to determine the value of flexibility a modular product platform architecture offers and compare it to the additional costs. The results can be used to rank different alternative platform concepts by their economical attractiveness including uncertainty and flexibility.

The developed assessment process is based on the real options approach. The real options method is a generic method to assess investment projects including flexibility and uncertainty.
6.2.2 Tailoring Processes to Business Scenarios
Authors: Schoening William W.
Published: November 2014

The notion of standard organizational processes and activities seems to have morphed into the notion that one size fits all with but a few minor variations. Instead, the choice and nature of the processes and activities should reflect the business needs of the organization and individual projects. One of the most fundamental business needs is minimizing the risks while capitalizing on opportunities. An examination of how these important objectives for business success impact the choice and nature of the processes and activities reveals that more than simple tailoring is required. Furthermore, the strategy issues are often complex and require major involvement of senior management to decide issues well beyond the normal scope of systems engineering.

In this paper, several classes of underlying business scenarios described, narrowed to those of interest, and then examined for variations in processes and activities that result from minimizing risk and capitalizing on opportunities. Dimensions of the scenario space examined are (1) the business relationships between the developer, users and who funds the developments, (2) time horizon with quick time‐to‐market at one extreme and focus on long term supportability at the other, and (3) development phase. Each combination of underlying scenarios over the life of a program is part of the overall business strategy. Armed with a well‐articulated relationship between the scenarios and the consequences of either appropriate or inappropriate choices for processes and activities, senior managers can then make well‐informed choices about business strategies and the tactical implementations.
4.3.2 Requirements Definition ‐ A Plea For a Return To English
Authors: Aslaksen Erik W.
Published: November 2014

The formulation of requirements continues to be a problem in systems engineering, despite considerable efforts over the last several decades and the emergence of a number of formalised languages. In this paper, we argue that a natural language, i.e. English, is still the most appropriate for most cases, and that it would be beneficial to concentrate more effort on ensuring the proper use of English rather than on inventing new formalisms to circumvent the perceived weaknesses of English.
4.3.3 An Architecture for an Intelligent Requirements Elicitation and Assessment Assistant
Authors: Scott William , Cook Stephen C.
Published: November 2014

Requirements engineering is crucial to the success of the system engineering process. Unfortunately, while current generation tools provide good support to requirements capture, they offer only modest assistance for cognitive tasks such as requirements assessment. This paper opens by introducing the attributes needed to define a requirement and the qualities of good requirements and requirements sets. An argument is then presented for the inclusion of artificial intelligence to perform requirements analysis and this is followed by a review of intelligent requirement analysis tools identifying the need for enhancements. From this basis, the paper describes the architecture of an intelligent requirements elicitation and assessment assistant that is currently under construction.
6.3.1 Modular Design Approach for Development of Electrical, Electronic, and Software System Architectures for Multiple Product Platforms
Authors: Rushton Gary , Zakarian Armen , Grigoryan Tigran
Published: November 2014

Modular systems provide the ability to achieve product variety through the combination and standardization of components. Modular design approaches used in the development of electrical, electronic, and software (EES) systems allow sharing of architectures/modules between different product lines. Modular products provide economies of scale, reduced development time, reduced order lead‐time, and easier product diagnostics, maintenance and repair. In this paper, new optimization algorithms and software tools are presented that allow EES system design engineers to develop architectures/modules that can be shared across product platforms (for OEMs) and across OEMs (for suppliers). Approaches presented in this paper use matrix clustering and graph based techniques. The application of the approach is illustrated with an example from the automotive industry on the development of a modular EES system that can be shared across multiple vehicle platforms.
4.4.1 Will Object‐Oriented Systems‐Engineering Reshape Requirements Engineering?
Authors: Kaffenberger Ruediger
Published: November 2014

At the 2002 Annual INCOSE Symposium Joseph Kasser's presentation ‘Does Object‐Oriented Systems Engineering Eliminate the Need for Requirements?’ provoked a lively discussion and his conclusion that there was no need for requirements when an object‐oriented approach to systems engineering similar to object‐oriented software engineering was followed, met strong resistance. This paper briefly reviews traditional requirements. The evolution of object‐oriented programming is presented and the important role of use‐cases in the requirements engineering process is shown. On the basis of this information this paper comes to the conclusion that object‐oriented systems engineering indeed will use a different way to cope with requirements than traditional systems engineering.
4.4.3 Managing System Interface Requirements Reconciliation Using Design Structure Matrix Method
Authors: Hommes Qi D. Van Eikema , Berry Paul W.
Published: November 2014

This paper presents a study at Ford Motor Company using the Design Structure Matrix (DSM) method to reveal the true workload associated with reconciling the requirements concerning major system interfaces. This study found that the common management practice underestimated the workload because the focus was on locally owned responsibilities. The workload associated with system interfaces was not accounted for. Three levels of responsibilities were uncovered—local responsibility, first order system interfaces, and second order system interfaces. The results of this study provide engineers and managers a framework and a vocabulary to better understand and manage system interface requirements reconciliation.
2.5.2 Reuse for Real
Authors: Mroczek Debra , Beckley Jennie
Published: November 2014

Using a real world example this paper attempts to illustrate the benefits of using XP ‐ eXtreme Programming (Beck 2000) principles to obtain reuse benefits during the development process. Key to this methodology is embedding reuse and refactoring into the everyday processes rather than attempting to force reuse at the beginning or end of the development cycle. XP doesn't work for every type of project and this paper doesn't attempt to push projects into using XP where it is not appropriate. However, the key principles mentioned in this paper can benefit most projects in their quest to apply reuse and reap its rewards.
7.5.1 The Heritage and Power of the Integrated PM/SE Project Cycle
Authors: Mooz Harold (Hal) , Wilson Mark A.
Published: November 2014

Organizations that successfully transition from ad‐hoc work practices to a repeatable, controlled process usually transition first to a project cycle and then to a gated project cycle to manage accomplishments.

By examining past and present project cycles, we can identify the primary concerns of the industries for which the cycles were designed. For example, project cycles of government projects tend to be representations of the technical development or systems engineering (SE) process, while project cycles of commercial organizations tend to reflect the pursuit of the business case and project management (PM) approach. It is unusual to find fully integrated project cycles that address both the business (PM) and technical aspects (SE) as an integrated process.

Fully integrated project cycles that reflect both project management and systems engineering strategic objectives and tactical approach should depict the three aspects of phased expectations: business, budget, and technical. The business and budget aspects are highly project management‐centric, while the technical aspect reflects the systems engineering (solution development) cycle. The three aspects must be constructed congruently and must remain congruent to ensure project and system integrity and the associated high probability of success. Imbedded control gates should punctuate the cycle to focus development creativity on the elaboration of the technical baseline and satisfaction of the business case, which may be evolving over time due to market forces independent of the evolving technical baseline.
2.6.2 Evolution of Agile Processes on a Small Program
Authors: Beckley Jennie , Mroczek Debra
Published: November 2014

This paper discusses our experience attempting to develop and introduce a web‐based collaborative engineering environment into an organization working in a government contract environment. In a previous paper, we described how we had evolved our processes from ones that control change to processes designed to adapt to a rapidly changing environment. In this paper, we continue the story by discussing how those processes compared to “Extreme Programming” (XP), and how we subsequently benefited from adopting additional elements of XP. To illustrate the points, we use our 2002 task to automate the enterprise Data Management process as an example.
3.6.3 Trade off Between Model Based Systems Engineeing and UML to Develop Communication Based Train Control
Authors: Ahn Chi Kyoung , Park Young Won , Park Joong Yong , Park Min Shin
Published: November 2014

The purpose of this paper is to evaluate UML for use to model the Communication‐Based Train Control (CBTC) system for an Automated Guided Transit (AGT). In the previous study, a computer‐aided systems engineering tool, CORE from Vitech Corp., was used for the same purpose. The study demonstrates UML diagrams illustrating the system view obtained at each development life cycle such as operation concept construction, requirement analysis, functional analysis, and synthesis phase. This research attempts to establish not only a smooth interface with software engineering, but also various system views unavailable from the traditional systems engineering tools. As a result, there are more abundant system representions that facilitate the system design process.
5.6.2 Emergence: An Illustration of the Concept for Education of Young Students
Authors: Ferris Timothy L.J.
Published: November 2014

The concept of emergence in systems is a difficult concept for beginners in the analysis of systems to appreciate. The essence of the emergence concept is that when a set of components are brought together and assembled into a system, that system exhibits properties that are different than the aggregation of the properties of the components taken separately. Systems educators have, amongst other roles, the task of providing students with an intuitive sense of the nature of the emergence phenomenon. This paper discusses the use of tennis, a sport with a hierarchical scoring structure, as an illustration of the nature and characteristics of emergence in systems.
6.6.2 Factors Contributing to Space System Failures and Successes
Authors: Kaslow David
Published: November 2014

Processes and procedures, concepts, requirements, and design specifications, and design and productions standards are necessary but not always sufficient for building a robust space system. These entities are only documentation and not knowledge. The preponderance of these entities are success‐centric and are created from within the system. That is, they generally do not provide enough emphasis on addressing what can go wrong and they are limited by the knowledge of the people developing the system.

This paper is divided into three parts. The first part examines specific occurrences of space mission degradation, failure and recovery. These examples will illustrate the notion that anything can go wrong in a space mission, but a robust design and ingenious work‐arounds can often save the mission. The second part provides examples of recovery from failures. The third part provides an overview of six methodologies that are critical to building a robust system. These methodologies should be standard practices in any program, but can be overlooked or under‐worked when a program first encounters the prospect of missed milestones and insufficient funding.
7.6.3 Requirements Driven Quality Assurance
Authors: Buhr Kerstin , Dörr Heiko
Published: November 2014

System development in practice is accompanied by two quality assurance measures for controlling and assessing development results: the review and the test. The form, frequency and scope of these measures must meet the quality and safety demands of the system, and take into account the working methods of the developers, the time available and budget of the project.

High‐quality quality assurance has to be closely linked to the actual system development. Up to now this link has only been defined on the level of processes. This article describes a stronger content‐oriented and methodological integration of construction and quality assurance methods. On the basis of the central system development process Requirements Management, well‐known quality assurance processes have been embedded into comprehensive quality management. The result is a method for the generation and execution of an integrated quality assurance plan that runs parallel to and extensively supports the development of safety‐critical systems. The method is strongly focused on the requirements of a system and the ensurance of their implementation. The integrated method has already been successfully applied to real system development projects.

The consistent application of quality assurance clearly improves the consistency and completeness of development items and their interfaces and ensures a complete realization of the requirements made of the system.