bluuebunny/crossref_metadata_2025_split huggingface dataset:
3.2.3 An Overview and Assessment of the Current State of Telecommunications Operations Support Systems
Authors: Bassett Brendan 
Published: November 2014

AbstractThe paper defines and traces the evolution of software‐based Telecommunications Operations Support Systems (OSSs). The paper provides a definition and architectural overview of the major functional units of an OSS. These major functions are also compared to the standard operations of a telco service provider. A brief evolution of OSSs is described in order to indicate how OSS evolution is similar to the telecommunications marketplace as a whole. The issue of OSS integration and the evolution of integration approaches is also explored. Finally, the impact of the modern OSS within a telco – positives and negatives – are detailed. The theme running through the paper is that OSSs are just as dynamic and fragmented as the telecommunications industry they are engineered to support, with the conclusion that major integration improvements must be made in order to optimize operations for OSS users.
4.2.1 Process Tailoring in Iterative Development
Authors: Murdoch John , McDermid John A. , Wilkinson Philip 
Published: November 2014

AbstractThe organisational context in which systems engineering is practised is changing. Organisations are becoming increasingly concerned with the flexibility of their processes. Fundamental issues of responsiveness to innovation in product concept, system architecture, component technologies and inter‐working relationships are of growing importance. Current developments in management thinking and in e‐business technologies are also pushing in the direction of flexibility and adaptability.This paper addresses the tailoring of systems engineering processes to iterative product development, using a role/responsibility‐based approach. Two levels of tailoring are discussed: (1) from standards and the systems engineering literature to an organisation's capability resources and (2) from the capability resources to an individual project. The approach is motivated by the wish to apply standard reference models developed by the systems engineering community in a flexible way, especially to link and scale up innovative and entrepreneurial activity into projects. Simple examples are provided to illustrate the approach and some issues involved in a practical application are discussed.
4.2.2 Agent‐Based Process Management
Authors: Debenham John 
Published: November 2014

AbstractA categorisation of business process covers the full business process spectrum from routine production workflows to high‐level emergent processes. The first of these categories is activity‐driven processes; they are managed by a single reactive agent architecture. The second of these categories is goal‐driven processes; they are managed by a multiagent system. The third of these categories is knowledge‐driven processes; they may not be managed as such. Two agent‐based architectures manage activity‐driven and goal‐driven processes respectively.
8.2.1 Putting It All Together: Entity Relationships Between Requirements, Components of System Design, and Verification to Requirements
Authors: Piraino Daniel W. , DeBardi Gary , Peterson Ken , Johansen Curt 
Published: November 2014

AbstractThis paper outlines entity relationships for the information used in the development of requirements and system architecture. These entity relationships can and have been used for database development to organize the information in various meaningful and useful ways. We have done this using inexpensive tools which is necessary in our industry, medical devices.Requirements at the system level are developed from hierarchical Functional Flow Block Diagrams (FFBDs) and measures of effectiveness. Requirement documents are modelled as “Input‐Process‐Output‐How_Well” constructs in which the various components of the requirements are extracted from the entity which represents the information.Architectural information is viewed at the highest level as System Transforms which relate to the FFBDs. The system is further modelled as a collaboration of modules, each with Module Transform that relates to the System Transforms which they are implementing. We call this collaboration a “Module Path.” In all cases the measures of “how‐well” contained in the requirements “flow down” to the Module Transforms so that information is not replicated. These measures, which we call “measures of effectiveness” (MOEs), are also hierarchical so that allocation and budgeting of requirements is supported. Similar to system requirements documents, module requirements documents are modelled as constructs of combinations of information extracted from the various tables.Finally, verification to requirements is seen as a number of test cases which relate to one or more functions and/or measures. Test cases may test system requirements, modules requirements or a combination. In this way, test cases may be examined for test coverage and duplication. and the impact of inevitable changes in requirements during the development process may be examined.
2.3.4 Military Experimentation: A Systems Engineering Approach to Force Development
Authors: Bowley Dean , Brennan Michael , Cook Prof Stephen 
Published: November 2014

AbstractThis paper relates the emerging analytical technique of military experimentation to force development and systems engineering practice. A definition of military experimentation is proposed and the purpose, principles and characteristics are described, based on an analysis of current overseas and Australian programs. A model of scientific inquiry is used as the basis for describing how and why military experimentation programs should be constructed. The purpose of military experimentation for different levels of system engineering problems and force development stages is described.
3.3.2 Idaho National Engineering and Environmental Laboratory Pilot Project An Integrated Approach to Accelerate Facility Disposition
Authors: Gibson Patrick L. 
Published: November 2014

AbstractOver the next 70 years the US Department of Energy (DOE) will spend more than $50 billion to deactivate, decommission and dismantle (D&D) facilities throughout its complex of production sites and Laboratories. This amount of funding will be difficult to obtain in an era of level or declining Federal budget. Therefore, the DOE must find more efficient, less costly ways to dispose of excess facilities. The Idaho National Engineering and Environmental Laboratory (INEEL) Pilot Project demonstrated an innovative, integrated, systems approach that offers opportunities to achieve significant savings in the long term. The INEEL concluded that this methodology would achieve significant efficiencies and improvement in their baseline over the life of the D&D program.
3.3.3 Confronting the Challenges of Integrating R&D and Operations at the Idaho National Engineering and Environmental Laboratory
Authors: Caliva Robert M. 
Published: November 2014

AbstractThe Idaho National Engineering and Environmental Laboratory (INEEL) is a Department of Energy (DOE) national laboratory that has been performing environmental cleanup and stabilization. The INEEL is a very unique site because it has both an environmental cleanup mission and a full spectrum of scientific research and development (R&D) which supports customers inside and out of DOE. Unfortunately, the R&D focus tends to be outside the INEEL rather than on the operational mission of environmental cleanup. With two‐thirds of the work scope directed at this cleanup mission and a flat to decreasing funding profile, the integration of R&D with Operations is essential. This paper will address how systems engineering is contributing to bringing these two sides of the laboratory together and helping to improve the INEEL's ability to manage its science and technology investments. This integration will enable the INEEL to successfully complete the cleanup mission in compliance with the customer's requirements, within schedule and cost limits, and yet still contribute to the revitalization of the laboratory.
5.3.2 Design of the Reconnaissance, Surveillance and Target Acquisition Squadron for the U.S. Army's Interim Brigade Combat Team
Authors: Willis or John B. 
Published: November 2014

AbstractThe primary source of battlespace intelligence for the U.S. Army's proposed Interim Brigade Combat Team (BCT) is the Reconnaissance, Surveillance and Target Acquisition (RSTA) Squadron. The fundamental role of the RSTA Squadron is to provide detailed situational understanding to the BCT Commander facilitating freedom of maneuver and the concentration of combat power at the decisive time and place. Technologically advanced systems should substantially enhance RSTA Squadron operations. Among the proposed systems in the Squadron are the Future Scout and Cavalry System (FSCS), tactical unmanned aerial vehicles (TUAV), ground‐based networked sensors (acoustic, seismic, magnetic, infrared, radio frequency), radio frequency (RF) detectors, and nuclear, biological and chemical (NBC) reconnaissance systems. This paper outlines the process used to date for designing the RSTA Squadron and proposes an alternative approach: a systems engineering methodology to formulate, analyze and interpret RSTA Squadron design alternatives.
7.3.1 System Test Metrics on a Development‐Intensive Project
Authors: Davies Paul , Hunter Neil 
Published: November 2014

AbstractNo software is bug‐free, despite what certain large corporations would have us believe, and the opportunities for introduction of defects or unintentional behaviour between requirement and delivery are enormous. This paper presents the experiences of Thales Sensors (Racal Radar defence Systems at the time) in attempting to quantify the effectiveness of our system testing procedures, as a metric to be used in assessing fitness for delivery. This method is suitable for current, ‘black box’ MoD procurement processes. The paper goes on to propose a similar metric to assess fitness of a statement of requirement as a basis for procurement or release for design. This could be used as a basis for co‐operative, ‘white box’ procurement processes under consideration for Defence Acquisition reform.
8.3.2 System Surety
Authors: Ekman Mark E. 
Published: November 2014

AbstractSystem surety is an essential part of an overall system engineering approach, particularly for the design and development of high‐consequence systems. High‐consequence systems are systems that are subject to catastrophic loss due to accidental or malevolent causes. Surety incorporates elements of reliability, safety, and security to define the level of confidence that a system will operate exactly as planned under both expected and unexpected circumstances. Surety assures reliability under normal operating circumstances, safety under off‐normal circumstances, and security under malevolent or hostile circumstances. Surety provides an alternative to compliance‐based philosophies for high‐consequence systems, providing a robust systemic framework for understanding and solving issues associated with achieving desired levels of safety, security, and reliability. This paper will explain the system surety philosophy and approach. Examples from ancient Rome's water supply infrastructure will illustrate the system surety philosophy and approach.
1.4.3 The Role of Systems Engineering in Make‐or‐Buy Technology
Authors: Doukas Louis , Simatupang Tota 
Published: November 2014

AbstractTechnology is one of the strategic factors in an enterprise. Sooner or later, every organisation will be faced with the problem of how to acquire the needed technology. An enterprise can acquire technology either through ‘making’ (the pursuit of new technology development though internal R&D) or ‘buying’ (acquisition from external sources). This is known as the “make‐or‐buy” or “sourcing” problem. This paper will discuss how and what role systems engineering discipline can play in approaching this problem. The results show that systems engineering approach can play a major role in solving this problem especially through the requirements and decomposition analysis.
5.4.4 Managing Customer Expectations through an Integrated Approach to Risk Management, Program Performance Measures, and Trade Studies
Authors: Dean Joe H. , Safford Edward L. 
Published: November 2014

AbstractStandard practices in systems engineering do not take full advantage of data collected and organized by those performing risk management, program performance measurement, and trade study management tasks. Adjustments to existing systems engineering practices, presented in this paper, allow integration of these separate tasks in a way that significantly enhances program management's ability to manage customer expectations and reduce the cost of development. This paper presents real‐world examples of extensions to risk assessment practices that allow risks to be rolled‐up to program performance measures in addition to a traditional work breakdown structure. Integration of existing risk abatement planning tasks are explained in sufficient detail to show how key decisions embedded in risk abatement plans are included on the trade study list and evaluated in terms of program performance measures.
7.4.3 Systems Engineering an Assessment Method
Authors: Armstrong James R. 
Published: November 2014

AbstractThis paper addresses two points of interest to the systems engineering community. First, systems engineering processes and principles are applied to a development that is both smaller in scope than the usual system and other than a hardware product. Second, the birth of the Capability Maturity Model Integration (CMMIsm1) (SEIc) and its associated assessment method, Standard CMMI Assessment Method for Process Improvement (SCAMPIsm1) (CMMI Product Development Team, 2000), significantly raises the cost of assessing systems engineering process maturity. With application of systems engineering processes, both the performance and the cost impact of the CMMI assessments can and should be reduced.
7.4.4 Extending the Integrated Capability Maturity Model® (CMMISM) for Safety‐related Applications
Authors: Robinson Neil , Lindsay Peter , Pitman Adrian 
Published: November 2014

AbstractThe recently released CMMI offers a Capability Maturity Model integrated for software and systems engineering. The Australian Defence Force intends to use CMMI to assess suppliers of software intensive systems. A key aim is to identify the strengths and weaknesses of system and software suppliers, and to address identified weaknesses early in the acquisition process. This paper describes an extension of CMMI to explicitly deal with safety engineering, for use in assessment of suppliers of safety‐related systems.
8.4.1 Systems Engineering at the Bottom of the Food Chain
Authors: Armstrong James R. 
Published: November 2014

AbstractThe application of systems engineering at the component level encounters difficulties both from the perceptions of the component‐level developer and the basic assumptions of the existing systems engineering standards and practices. This paper identifies several of these difficulties and proposes ways of treating them. It is aimed at both the component‐level developer as well as developers making decisions about system components.
1.5.1 The C‐17 and BC‐17X: Systems Engineered Transport Aircraft for the World
Authors: Jackson Scott 
Published: November 2014

AbstractThe 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

AbstractIn 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

AbstractDue 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

AbstractThe 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

AbstractThis 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

AbstractThis 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

AbstractThis 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

AbstractThis 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.