bluuebunny/crossref_metadata_2025_split huggingface dataset:
3.1.2 Architecting the Raytheon Production Cost Model
Authors: Stratton George , Redman F. Quentin , Kehret Matthew 
Published: November 2014

AbstractThe 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

AbstractOne 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

AbstractThe 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

AbstractThe 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

AbstractRequirements 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

AbstractModular 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

AbstractAt 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

AbstractThis 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

AbstractUsing 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

AbstractOrganizations 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

AbstractThis 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

AbstractThe 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

AbstractThe 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

AbstractProcesses 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

AbstractSystem 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.
1.7.3 Incorporating Risk In the Programmatic Decision‐Making Process – A Case Study
Authors: Kepchar Ken , Stack Toni , Newnam Bill 
Published: November 2014

AbstractWhile the need for good risk management as part of project and program management is well established, risk management practice has often lagged its potential to assist the management team in identifying the need for decisions, framing courses of action, and providing objective evaluation of alternative courses of action. This paper provides an analysis of the role that risk management plays in supporting programmatic decision‐making. Specifically, it looks at how risk management supports the intelligence, design, choice, and review functions of decision‐making as formulated by Herbert Simon. It includes a case study that illustrates the application of risk management to an on‐going program at the Federal Aviation Administration (FAA). The paper also discusses the application of available analytical tools to support the programmatic decision‐making process.
3.7.2 Exploiting Inspection: Some New Practices and Some Reminders
Authors: Gilb Tom 
Published: November 2014

AbstractInspection, a proven technique for achieving quality and identifying process improvements, should be applied to technical specifications throughout systems engineering. The greatest value from inspection can be gained through a proper understanding of its purposes and benefits. Newer practices, such as sampling, should be incorporated into the more traditional application of this technique.
4.7.3 Multi‐Criteria Decision Analysis: Limitations, Pitfalls, and Practical Difficulties
Authors: Kujawski Edouard 
Published: November 2014

AbstractThe 2002 Winter Olympics women's figure skating competition is used as a case study to illustrate some of the limitations, pitfalls, and practical difficulties of Multi‐Criteria Decision Analysis (MCDA). The paper compares several widely used models for synthesizing the multiple attributes into a single aggregate value. The various MCDA models can provide conflicting rankings of the alternatives for a common set of information even under states of certainty. Analysts involved in MCDA need to deal with the following challenging tasks: (1) selecting an appropriate analysis method, and (2) properly interpreting the results. An additional trap is the availability of software tools that implement specific MCDA models that can beguile the user with quantitative scores. These conclusions are independent of the decision domain and they should help foster better MCDA practices in many fields including systems engineering trade studies.
1.8.1 Risk Management: Observations and Lessons Learned
Authors: Robinette G. Jeffrey 
Published: November 2014

AbstractThis paper describes some observations and lessons learned from over ten years of doing risk management at the Air Force Aeronautical Systems Center (ASC), Wright‐Patterson Air Force Base, Ohio. This work is based on implementing the ASC Integrated Risk Management (IRM) process at Wright‐Patterson and other government and industry facilities. It also provides an overview of the Aeronautical Systems Center's Integrated Risk Assessment (IRA) approach.This paper discusses lessons learned from performing the three parts of an integrated risk assessment: the Technical Assessment, the Schedule Assessment and the Cost Estimate. It covers their interaction and interrelationship when accomplishing each of the three parts. It also presents lessons learned from the other major tasks required of a healthy risk management process. The highlights of this paper come from approximately thirty different risk assessments performed by the author, visits to many government program offices, visits to contractor facilities, and annual surveys accomplished at ASC.
2.8.3 Tri‐Cities Chapter Community Project
Authors: Baynes Patrick A. , deLamare Michael A. , Hendel Brian J. 
Published: November 2014

AbstractIn an effort to revitalize the Tri‐Cities Chapter of INCOSE, our Chapter took on a project to analyze the facility needs for the Tri‐Cities Chaplaincy, a local non‐profit organization. The Project examined existing and future space requirements to support the Chaplaincy's expanding services and organizational growth. In addition to active chapter members, the Project attracted the participation of both inactive chapter members and some non‐chapter members. The Project succeeded in energizing the Chapter and in helping the Chaplaincy understand the increasing demands for its valuable community services. This paper discusses how the Project proceeded, some lessons learned from the process, and the benefits it provided the Chapter.
4.8.1 Visualization of Multi‐Attribute Utility Models
Authors: Fishenden J.C. , Singleton G.R. , Maier M.W. 
Published: November 2014

AbstractMulti‐attribute utility models are usually thought of as direct quantifications of stakeholder preferences. A system alternative that receives the highest utility score is the preferred solution. However, in practice users often attempt to use multi‐attribute models for complex forms of decision making, such as new alternative synthesis or investment selection. Since more complex decision‐making requires more insight into the multi‐attribute data than a single number, we have investigated methods for visualizing high‐dimensionality utility data, especially for utility‐over‐time applications. This paper discusses the visualization techniques and presents examples.
1.1.1 Applying Systems Engineering to Warship Topside Design
Authors: Montigiani Marco , Manzini Mauro 
Published: November 2014

AbstractThis paper presents a high level warship topside design process. All the aspects involved such as Human Factors, Electromagnetic Engineering, the Platform, the Combat System and so on, are taken into account. To manage, plan and coordinate all the activities, a Systems Engineering approach is applied. Starting from requirements definition and their analysis, through an iterative optimization loop, the whole Systems Engineering process is described. To assist supervision, graphic tools such as risk matrices are introduced. These matrices allow a global vision of the whole process in a very simple way. So we provide an effective path towards an efficient topside configuration that minimizes the risks which would otherwise occur in a non‐interdisciplinary approach. Finally a way to “measure” the process is given.