bluuebunny/crossref_metadata_2025_split huggingface dataset:
6.3.4 Threads, Reference Cases, and System Models: Adapting OOA to Complex System Specification
Authors: Steiner Rick 
Published: November 2014

AbstractBehavioral system models are often necessary to specify top‐level system dynamic characteristics, especially for complex systems. Representing system stimulus/response behavior is often problematic, however. The scenario used to stimulate the system model may be overly simplistic, and won't be validated operational experts. On the other hand, operational experts will often develop a very broad set of system scenarios so detailed that they obfuscate the key system characteristics. This paper discusses a technique for aggregating operational system scenarios into a meaningful essential set of “reference cases”, which then serve as the functional baseline for system development and design verification.
7.3.3 Using Measurement to Assure Operational Safety, Suitability, and Effectiveness (OSS&E) Compliance for the C2 Product Line
Authors: Smith David L. 
Published: November 2014

AbstractAir Force Policy Directive 63–12, Assurance of Operational Safety, Suitability, and Effectiveness, establishes the Air Force requirement to assure operational safety, suitability, and effectiveness (OSS&E) through a system's operational life. Electronic Systems Center (ESC) of Air Force Materiel Command (AFMC) is responsible to provide this assurance for each Command and Control (C2) system developed, procured, operated, maintained, modified, or employed.This paper discusses the role measurement must play in the OSS&E assurance process, and offers guidance to develop effective measures. While specific measures must be adapted for each system, the concepts needed to develop effective measures are the same. A combination of product, process, and performance measures may serve as indicators to show the project manager the overall project OSS&E status. These could include trends that show compliance being maintained or in jeopardy, or the positive (or negative) effects of a particular course of action. Example measures are presented to reinforce the concepts being presented.
1.4.1 Enterprise Systemics: Systems Thinking for plotting Strategy at the ‘Extended Enterprise’ level”
Authors: Fairbairn Allen , Farncombe Andrew 
Published: November 2014

AbstractThis paper demonstrates the value of various systems techniques, and the system of systems concept in particular, to the design and management of key Extended Enterprise activity. By the Extended Enterprise (EE) we mean the context for the complete set of activities undertaken by companies operating together in a competitive market environment to deliver commercially viable products and services to consumers. We have coined the term ‘Enterprise Systemics’ to describe the use of a portfolio of systems techniques that facilitates, inter alia, plotting strategy at the EE (or network) level – perhaps the most challenging of corporate activity.We describe what we mean by the Extended Enterprise and some of the difficult challenges that it presents for current design methods and techniques. We report on work done to develop an approach that draws from diverse sources of systems type thinking. Case Study material is provided, from work done with a shared learning group in the UK over the last two years and from the successful industrial development of a UK Government funded research project.
1.4.2 Best Value Solutions: A Systems Engineering Perspective
Authors: Donnelly John J. 
Published: November 2014

AbstractKey aspects of Systems Engineering create an environment that encourages the development of best value solutions. These elements include requirement analysis and allocation, trade studies, risk management, and program evaluation. In this discussion, the term “best value solution” is defined as a balanced solution between cost, performance, schedule and risk (Cook et al. 1999), (Kaye, Graham 1999).
1.4.4 U.S. DoD Legacy SE & Implications for Future SE Implementation
Authors: Simpson Mary J. , Simpson Joseph J. 
Published: November 2014

AbstractThis paper presents a high‐level, simplified view of systems engineering to establish a common context for discussing systems engineering environments. It examines often unstated bases and assumptions upon which systems engineering implementation in the U. S. Military is based, and offers observations regarding factors that deserve consideration in implementation of systems engineering outside of the military domain.
5.4.2 A Solution to the Risk Management / Innovation Dilemma
Authors: Cogliandro J.A. 
Published: November 2014

AbstractRisk management is a proven, accepted form of control for large, multi‐faceted technical development programs; however, it may be ‘detrimental’ to some or all of these programs due to inaccuracies in its mathematical and cultural basis. We hypothesize that Risk Management is inappropriate for many programs; particularly small projects, technology development and insertion programs, and R&D projects. Risk management can also hinder ingenuity and promote mediocrity in larger programs, especially during the critical concept exploration and preliminary design phases. In short, a modified version of Risk Management is proposed. This new version is directly linked to the strategic goals of the organization; it is designed to foster innovation without sacrificing robust design and good program management. The method is called Strategic Risk Management and is also known as Three Dimensional Risk Management (3DRM“©®, Pat. Pend.). It uses a newly constructed risk consequence chart designed to correct the flaws in today's risk management programs and is easily applied to existing risk programs or developed in new programs. Each point on the likelihood/consequence curve is numerically linked to the organizations goals, tactics, and strategies, and is program phased, hence the third dimension. In effect, 3DRM creates three totally new risk management quadrants organized by phase, and maintains the traditional curve as quadrant three. A powerful graphical summary view is also presented, which highlights the juxtaposition between the risk level and expected return of each item, and overlays the original goals of that item. In the following pages we will attempt to quantify several of the assumptions behind the statements above while proposing a modified form of Risk management for use in all programs, large and small, conceptual and mature.‐Author's note: This paper is written for the risk management professional and assumes a basic knowledge of risk management; including identification, consequence and likelihood setting, mitigation planning and tracking. Our desire is not to dismantle any currently implemented risk management program or preclude a future program, but to offer the possibility of amending and improving the process.
1.5.4 Adaptation of a Generic Systems and Software Engineering Process for Component‐Based Development
Authors: Lykins Howard 
Published: November 2014

AbstractComponent‐based development, in which systems developers rely on the marketplace and other sources of components external to the project, is becoming the norm in many applications of systems engineering. Even highly specialized systems such as those used by the military and aviation contain a significant proportion of off‐the‐shelf components. This paper describes a tailoring of an integrated process for systems and software engineering for use in a development context that emphasizes component‐based development. It discusses some key requirements for the tailored process, and provides examples of the process architecture and the process information model. It concludes with a brief discussion of using the tailored process for a specific project.
3.5.1 System Engineering in System Avionics
Authors: Kagan Jakob , Levy Boaz 
Published: November 2014

AbstractSystem of systems development requires design of the integration and testing process with a system perspective. Efficient and effective development requires in‐depth system analysis leading to the need of specific tools, integrated into the system at different levels. System levels can be divided to Design, Integration and ProductionA Missile, is a product that can't be recovered from its mission, therefore each flight test is extremely expensive. The flight test has to be the final stage in a in‐depth and integrative test process. A primary guideline for missile testing and integration is: “If a specific function has not been tested, it will not work“. This rule was implemented into the development of the ARROW‐2 missile avionics subsystem. In the system design process of the Arrow missile, the tools and processes required for development were included as an integral part of the system. The human factor was also considered an integral part of the process and taken into account in the planning stages.This article presents the systems oriented testing methods used for the Arrow missile in preparations for flight tests. The issues presented include:

The unique principles that were applied to the testing process.
The guidelines of determining the integration team.
The End to End (E2E) tests methodology as part of the integration process.
The different integration sites and the use of each within the process.
The types of tests performed within the process.
The contribution of the system design approach in improving the integration process by enabling integration of product system features as part of the testing system
7.5.4 Improving the Systems Engineering Process At Israel Aircraft Industries ‐ A Case Study
Authors: Engel Avner , Winokur Michael , Goshen Drora , Geva Izhak 
Published: November 2014

AbstractThis paper describes Israel Aircraft Industries (IAI) efforts in improving the systems engineering process. To put the subject in its right perspective, the paper provides some background information about IAI and its engineering culture. The paper describes the Advanced Systems and Software Engineering Technology (ASSET) program, which started in 1992. The paper describes a company‐wide effort to improve systems engineering processes in four important areas:

Manage and plan systems engineering.
Adopt systems engineering database tools.
Improved Systems Testing.
Train Systems Engineers.The paper concludes by citing our lessons learned. The participation of personnel from both headquarter and divisions, the concentration of improvements in the most critical areas, the importance of the Systems Engineering Management Process Group (SEMPG) and the usage of pilot projects as a dissemination vehicle for concepts and methodologies.
4.6.4 Requirements process and traceability issues in a SE methodology
Authors: HELLOUIN Laureen , Beaugrand Jean Luc , SAHRAOUI Abd‐El‐Kader 
Published: November 2014

AbstractThis paper describes an approach for multiple domains system design, especially for systems mainly composed of electronic and computer technologies. The systems engineering concepts are taken as basis; such concepts are available through standards, working group's documents and other similar approaches being carried out for various systems. The methodology is tailored to fit specific needs coming from encountered problems at practical and applicable levels. It is limited to requirements process and traceability issues. The objective of the work was oriented to set up a good practice of system engineering approach in the elaboration of a methodology to deal with electrical, electronic and computer systems requirements to improve specification documents completeness.
6.6.1 RACE for Faster, Better, Value
Authors: M'Pherson Philip K. , Pike Stephen 
Published: November 2014

AbstractThe Rapid Assessment of Cost Effectiveness, ie RACE, is a key tool for the early concept and synthesis stages of systems engineering projects, during which the best candidate system has to selected for delivery from a ‘faster, better, cheaper’ project. The selected system should then offer the best value for money throughout an often long operational life. The paper outlines an integrated methodology for through‐life cost‐effectiveness analysis. Its structure is conventional, but it incorporates some novel features that provide (1) a powerful and fast ‘system builder’ to synthesise system candidates within mythical future operations, (2) tests to show that user, system and architecture requirements are matched, (3) a measuring multidimensional value criterion to serve for effectiveness, (4) whole‐life cost‐effectiveness analysis conducted in a true value for money sense. RACE has been tested on a real task, and specimen (but disguised) results are presented.
7.6.1 Front‐end Operational Concepts ‐Starting from the Top
Authors: Gabb Andrew 
Published: November 2014

AbstractThis paper addresses the need for, use and development of operational concepts at the start of large projects. It is derived in part from the author's work in INCOSE's Requirements Working Group and acquisition reform in the Australian Department of Defence, but also from the author's experience in developing operational concepts for defence projects. The front‐end operational concept, derived in consultation with the system's potential users and other stakeholders, should serve as the driving document for the acquisition and supply of the system. However, there is often uncertainty about what such a document should contain, how it should be developed, and its relationship to other project documents. The paper addresses these issues, as well as the evolution of the Operational Concept throughout the life of the project.
1.7.1 Applying Systems Engineering in the mining and ore processing industry
Authors: Wilcocks Hillegert A. 
Published: November 2014

AbstractTraditionally, acquisition projects in the South African mining and ore processing industry have followed an approach geared towards employing mature and well‐known technology. Recently, De Beers recognised that this approach would not satisfy the needs of complex systems that employ more technically advanced diamond sorting technology. As a result De Beers established a new systems acquisition approach that includes systems engineering principles and related activities appropriate for projects of this nature. This new approach is the subject of this paper.
4.7.4 Putting Cost in the Cost verses Performance Trade‐Off
Authors: Redman Quentin , Stratton George 
Published: November 2014

AbstractCost Performance Trade‐Off analysis is fundamental to the Systems Engineering process. A cost performance trade study, is a procedural search for a design solution that balances achieved systems performance, effectiveness and cost against the desired or required values for these features and the system. Within this paper we will discuss the methodology and rational behind that methodology for preparing the cost estimates to be utilized within these trade‐offs. Also included is a short discussion on appropriateness of cost modeling and analysis tools.
1.1.3 Educating Systems Engineers: Encouraging Divergent Thinking
Authors: McCumber William H. , Sloan Crystal 
Published: November 2014

AbstractParallels between divergent thought processes, studied in creativity research by developmental psychologists, and the intellectual control imperatives of systems engineering are examined. A metaphorical template of the systems engineer's thought processes as defined by and taught from the standpoint of convergence is presented, and a core set of training modules to aid in evolving systems engineers from domain engineer stock is recommended. A. D. Hall's 1969 model of the systems engineer's thought structure is resurrected and is found to still apply to the convergent mode of systems engineering training. It is suggested that teaching systems engineers to develop divergent thought processes is analogous to teaching “creativity” in other fields. An examination technique, employed with success in a related field (e.g., Microsoft certification), that uses the traditional “convergent” multiple choice question, but forces divergent thinking to arrive at the “correct” answer, is discussed.
1.1.5 Systems Engineering in COTS‐Based Systems
Authors: Fan Lin H. 
Published: November 2014

AbstractAs more and more software systems are developed by extensively making use of COTS products in recent years, applying systems engineering disciplines to a COTS‐based system is essential for building a successful system. A COTS based system is different from the traditional software system in that it uses COTS components as the basis of the system functionality. This means the new activities will become part of the software development process and the risks will bring into the system development process.This paper identifies these differences and difficulties from the system engineering's point of view, and focuses on the major system engineering activities in all stages of a COTS‐Based System life cycle. These activities are not only considered the technical aspects of the COTS based system, but also none technical aspects, such as marketplace research, management and business strategy and process. In order to provide a cost‐effective software development solution in COTS based system, this paper introduces the Adaptive Enterprise Solutions (AES) platform system as an example.
2.1.2 Use of constraint programming techniques for systems pre design involving several technical fields (Application on an example of an Aircraft Weapon Delivery and Navigation System)
Authors: Kou P. , Regniez C , Pagniez P 
Published: November 2014

AbstractSystems pre‐sizing involving several technical fields is generally based on a method where up‐going validation phases follow down‐going analysis phases. Meanwhile, the usual tools, when they exist, are often optimised to work in a single way.The Constraint Satisfaction Solving Method (CSSM) introduces a technique, which fulfil the needs of preliminary design, putting aside the notions of “input” and “output“. Moreover, Constraint modelling is a way to ensure the consistency between the different technical fields.A simplified example illustrates the problem on the Weapon Delivery and Navigation System of a military aircraft, underlining the many capabilities of the method.As a conclusion a feedback on its introduction at Dassault Aviation's Systems Directorate is presented and specifications for a Constraints Models Managing tool are introduced.
3.1.2 Organizing for Successful System Development
Authors: Rosen Peter A. 
Published: November 2014

AbstractWhile many options are available to organize a development organization for success, applying basic elements of system engineering management in defining, building, controlling and maintaining the organization chartered to develop the system will provide a solid foundation for the system engineering effort. This foundation will provide focus on the system under development and the processes to be applied to the development, rather than on organizational roles and responsibilities. While the proper organization will not guarantee success, inadequate organization of the effort will make the difficult process of system engineering a monumental challenge.
3.1.5 Partitioning National Defence into Portfolios
Authors: Vencel Les , Moon Terry , Cook Stephen 
Published: November 2014

AbstractPartitioning national Defence into portfolios, where key capabilities and activities are appropriately aggregated together, has been suggested as an effective way to manage national Defence. This paper examines in detail the application of a heuristic approach to achieve this, assessing the efficacy of various ways of partitioning national Defence using the established heuristics of systems architecting. The insights gained may then be applied to configure or refine the structure and to establish linking of the portfolios.
4.1.2 Geographic Information Systems (GIS) Applications And Trends
Authors: Raza Shahbaz 
Published: November 2014

AbstractThis paper presents an overview of GIS technology, its impact on various industries, current GIS technology trends, GIS standards, and systems engineering roles and challenges in the field of GIS. It introduces an overview of GIS technology i.e. what is GIS, how does GIS work, and what distinguishes GIS from other information systems. GIS is very much a multi‐disciplinary technology and can accommodate several application areas by integrating data from a variety of sources in a detailed and efficient manner. The paper discusses the impact of GIS application upon various disciplines e.g. business, engineering, political boundaries management, transportation, environmental management, natural resources, health care, and education. The development and application of geographic information systems is vibrant and exciting. The paper further reviews the existing and latest trends in GIS technology including new data sources, hardware and software developments. GIS is a rapidly growing field and requires an inherent need to have a set of common standards and rules to successfully complete GIS projects within time and budget. The paper also provides an overview of existing and future GIS standards and discusses the roles of various organizations involved in the development of GIS standards. Many areas in GIS are systems related and systems engineering can play a major role in helping GIS industry to be more productive and efficient to meet its customer needs. GIS technology, however, is relatively new and almost no formal systems engineering processes and practices are being applied. The paper addresses the major challenges faced by Systems Engineering in the development and management of GIS based systems.
5.1.5 A Systems Engineering Methodology for Combat Systems Development
Authors: Merritt Roger , Cropley David 
Published: November 2014

AbstractCombat system development is difficult to do well; many issues surround the development of such systems. The history of the creation of large, complex, socio‐technical systems has been marred by a litany of project failures. Poor project outcomes result in business failure and significantly reduce the capability that can be achieved for the modest defense budgets of countries like Australia, Austria, Belgium, Canada, the Netherlands, Spain and Sweden. This situation is being exacerbated by the increasing dependence of modern military systems on software and the increasing complexity of such systems. This paper highlights major issues faced by the defense industries of ‘intermediate’ nations such as those listed. It proposes a solution in the form of a systems engineering methodology appropriate to combat system development.
1.2.3 A Structured Approach to Developing a Systems Capability
Authors: Goodlass Sue , Phillipson Alan 
Published: November 2014

AbstractIn November 1999, British Aerospace and Marconi Electronic Systems merged to become BAE SYSTEMS, one of the 3 largest Systems, Aerospace and Defence companies in the world. In order to maintain and improve the company's capability, Engineering Developing You (EDY), has been created. EDY forms part of an integrated framework for personal and professional development – but with over 20,000 engineers just in the UK, and almost the same number again in overseas divisions and joint ventures ‐ the task itself is far more complex than may at first appear.For an (ex‐)Systems Engineer now working in the Virtual University, given the task of designing and developing this framework, using a structured Systems Engineering approach seemed to be a sensible approach. So how easy was it to apply a ‘soft system’ approach and how successful has it been ??
4.2.1 A Case Study in the Replacement of Legacy Systems with an Enterprise Resource Planning System
Authors: Raynor Rashad 
Published: November 2014

AbstractThis paper presents two case studies that involve the process of replacing multiple legacy systems with a comprehensive Enterprise Resource Planning (ERP) system. The paper will focus on the processes that each company took in evaluating the systems and the data housed in these systems. The lessons learned and an assessment of each company is presented at the conclusion of this paper.