bluuebunny/crossref_metadata_2025 huggingface dataset:
4.3.3 Simulation‐Emulation‐Stimulation A Complete System Engineering Process
Authors: Huang Paul , Kar Pradip , Sleder Al , Kato Hiroko
Published: November 2014

The complexity of modern hardware/software systems, the reduction in defense funding levels, and the desire of DoD (US Department of Defense) to reduce the acquisition cycle using Simulation Based Acquisition have significantly impacted the manner in which new weapon systems are concepted, designed, integrated, tested, produced, and supported throughout their life cycles. The traditional approaches for engineering systems are no longer adequate for rapid developments and must be modernized in an integrated methodology to take advantage of the significant advancements in computer technologies. Many efforts using computer technology up to this point in time have been fragmented and lacked a systematic approach to make full use of the technologies. By taking advantage of the advances in microprocessors and software to create a System Integration Environment (SIE), a Simulation ‐ Emulation ‐ Stimulation (SES) Process can be developed that handles all aspects of the life cycle including system analysis, design, documentation, test and evaluation (T&E), integration and training. This paper reports on some of the advances that have been made thus far in developing such a System Integrated Environment for use in Army and Navy Combat System Developments.
5.3.1 Modeling Communication Satellite Protocols with a System Design Automation Tool
Authors: Colligan Robert , Meseroll Thomas C. , Shamash Micah , Wells Tyler , Thompson Francis
Published: November 2014

Military communication satellites use an extremely complex set of protocols for sending/receiving messages and controlling payload resources. These protocols are typically implemented in software for modern satellites because software is easier to modify than hardware and offers on‐orbit reprogramability. Traditional methods of specifying, designing, implementing, and testing payload software have proven to be expensive and error prone. Recent enhancements in system modeling/simulation tools offer the potential to automate the progression of all these life cycle phases in a “seamless” manner wherein the outputs of one life cycle phase become inputs for the next.

This paper describes our evaluation of one of these tools: Statemate Magnum, produced by i‐Logix of Andover, MA. We evaluated the tool by using it to construct a simulation of satellite communication protocols. This simulation is to be used to facilitate the training of new project personnel.
5.3.2 Teams and Organization, a Model‐Based Approach
Authors: Oliver David W.
Published: November 2014

The techniques for engineering systems with models, usually applied to products and services, are applied here to the human issues of teams, organization, and culture. This provides a means to explore solutions to human and organization issues and find near optimal solutions using the best practices of systems engineering. It provides a basis for rigorous discussion and evolution of teams, organization, and culture through execution and improvement of models. This analysis relates goals, rewards and tasks to classes of cultural behavior, and finds four basic organization architectures. This paper produces results that are consistent with industrial experience and the abstractions and representations from the fields of anthropology and psychology. The modeling generates the results in rigorous executable structure models.
5.3.3 Model‐Based Proposal Development
Authors: Fisher Gerard H.
Published: November 2014

The competition for new business is increasing. There are fewer new starts being pursued by the government. Consequently, bidders need to find ways to increase their probability of win and reduce the cost of proposal preparation. This paper addresses the application of a model‐based systems engineering CASE tool, CORE®, to the proposal preparation process. The development and application of the proposal schema is discussed. The user benefits by decreasing the cost of writing the proposal and being better prepared when the contract is awarded.
2.4.1 Using System Engineering on A C‐17 Performance Improvement Project
Authors: Hsu John C.
Published: November 2014

A complete system engineering process is applied to a pilot project that will determine the initial deployment of the system engineering process for future projects. It was a challenge to complete the entire system engineering process to include project team utilization of system engineering tools in such a short time span. Therefore, system engineering products had to be useful and productive to the project. The system requirements definition, Quality Function Deployment (QFD) evaluation, trade study, risk identification and risk mitigation processes were completed in a timely manner and assisted in the System Requirements, System Design and Preliminary Design Reviews successfully.
2.4.3 Deep Space One Spacecraft System Engineering Techniques and the Application of Heuristic Reasoning
Authors: Basilio Ralph R.
Published: November 2014

The Deep Space One Project is part of the National Aeronautics and Space Administration's (NASA's) New Millennium Program. The team is chartered with the design, development, and in‐flight validation of new technologies. The knowledge gained in flight will be instrumental in the success of future projects as they strive to build “faster, better, cheaper” spacecraft for NASA, the nation, and the world. There are a total of twelve new technologies planned to fly as part of the first deep space mission, many of which were either selected by the program and/or project manager independently or some that were coupled un‐conditionally with one another. These technologies include the miniature imaging camera and spectrometer, autonomous on‐board optical navigation, and the small deep space transponder. However, the most striking of these are arguably the ion propulsion system and advanced solar concentrator array, the combination of which will result in a ten fold or order of magnitude increase in impulse (ratio of force over the propellant mass) over a conventional chemical system. At the time of this writing, the Deep Space One Project is nearing completion of the thirty‐three month development life cycle and is being mechanically and electrically integrated and tested at the Jet Propulsion Laboratory in Pasadena, California. This paper discusses the system engineering techniques used to date, especially the application of heuristic reasoning, in the design, development, and test of the Deep Space One spacecraft.
3.4.2 Design Review Checklist for a Business Process Model
Authors: Ring Jack
Published: November 2014

Are you faced with designing a new systems engineering process to improve your organization's capability level or with customizing a standard process such as EAI 632A? If so, you are entering the domain of business process modeling. This checklist, based on systems principles and evolved from several years experience in several businesses, is intended to forestall promulgation of inadequate or inaccurate models of business processes or operations. Business models that meet the criteria in this checklist can be expected to foster success and avoid implementation problems such as organizational resistance to change.
4.4.3 System Engineering For Informal Regulation
Authors: Koehler Andrew C. , Stone Adam D.
Published: November 2014

While systems engineering has traditionally concentrated on formal regulations as the basis for design requirements, other informal regulations may have equally strong impacts on the nature of any given industry or processes' relationship to its regulators. Through SE analysis of programs at Los Alamos National Laboratory, we argue that these informal regulations can have substantial effects on project outcomes. We develop a framework which can be used to include these informal regulations in both static and dynamic SE approaches and argue that such factors can and should be included in our analyses, despite the difficulties such an approach might generate.
5.4.2 Applying Systems Thinking to Expatriate Selection
Authors: Chapin Gregory G. , Martinez Zaida L.
Published: November 2014

A key factor in expatriation success starts with an effective selection process. Unfortunately, the expatriate selection process is often rushed and unstructured, resulting in poor expatriate performance or the cancellation of assignments. Systems thinking can provide structure and discipline to improve this process and, thus, expatriates' performance potential. Systems thinking can also assist corporations in defining expatriate selection as a problem that can be solved through developing a methodology that adequately addresses the problem, delineates feasible solutions to the problem, and provides feedback to improve the methodology used. Furthermore, such methodology can reduce selection costs and enhance expatriate performance. This paper shows the need for systems thinking in expatriate selection and describes how a systems methodology may be applied to expatriate selection.
5.4.4 Revisiting Accumulated Wisdom After 100 Years Of Engineering Railway Systems
Authors: Williams John , Allan Jeff , Jin Jenny Q
Published: November 2014

There are a number of reasons why new types of segmentation of railway systems are worthy of consideration, e.g.:

New technology, particularly applied to communications and computing,

Operational economies and improvements to the recovery from disruption provided by the centralisation of control of railways,

The impact of traction power supply on both the future environment and on the diminishing fossil fuel sources,

Major changes in methods of funding large railway projects,

The extensive use of Outsourcing of maintenance and other services,

The vision that railways are part of an integrated transport system implying a need to take a flexible approach to the developing external interfaces.

The implications of these, together with the increasing emphasis on safety and the railway customers needs has resulted in a re‐evaluation of the traditional approach to railway system architecture.
5.4.5 Introducing System Engineering into a Traditional Steel Making Environment
Authors: Duggan Peter J. , Groenewald Johan
Published: November 2014

This paper discusses the lessons learnt from the introduction of the System Engineering process into a Steel Manufacturing organisation which had decided to develop a new technology. Some of the reasons for using the SE approach and the benefits obtained are discussed, as well as the pitfalls encountered. Many of the lessons are, we believe, applicable to Systems Engineering in general, and to commercial applications of system engineering in particular. A process approach is stressed.
2.5.1 Systems Engineering Standards and Models Compared
Authors: Sheard Sarah A. , Lake Jerome (Jerry) G.
Published: November 2014

Currently there are five systems engineering standards in various stages of release and three systems engineering capability models. This makes it difficult to know what to use as a basis for process improvement. This paper discusses the similarities and differences among the standards and models. The standards have been evolving from the U.S. Military to international and commercial, with recent standards taking a broader scope. Two capability maturity models have been merged into a third, which is tied to the standards.
2.5.2 Key Features of the “Merged” EIA/IS 731–1 Systems Engineering Capability Model
Authors: Widmann E. R.
Published: November 2014

In the past few years, several models have been developed to measure systems engineering process or capability maturity. Two models, the INCOSE SECAM and EPIC SE‐CMM, have gained a great deal of attention and have been used as source models, along with their application methods, to create a US standard, comprised of a single “merged” model and application method, for measuring and improving systems engineering capability. The “merger” effort has been conducted by the EIA SECM Working Group, which has representation from the EIA, INCOSE, and EPIC and was formed under the auspices of the Electronic Industries Association (EIA). This paper provides key features of the “merged” model, a synopsis of each of the two source models, and relationships between the “merged” model and its two source models. A description is provided of some significant factors affecting the merger effort. The information provided should assist in gaining an understanding of, and in transitioning to, the “merged” model, which is the EIA/IS 731–1 Systems Engineering Capability Model (SECM).
5.5.4 A Soft Systems Methodology to Support Business Process Change Towards Concurrent Engineering
Authors: Clegg Ben , Boardman John
Published: November 2014

This paper discusses the fundamental commonality of ‘total quality management’ (TQM) and ‘business process reengineering’ (BPR) that originates from their roots in ‘systems thinking’. The authors draw on the same ‘systems thinking’ origin to develop a new soft systems methodology known as the Boardman Soft System Methodology (BSSM). The BSSM has been evolved specifically for modelling business processes to support change management initiatives such as BPR and TQM. Evidence is given in a case study which reports on improving the use of concurrent engineering (CE) tenets in a medium‐sized engineering firm.
1.6.3 A Quantitative Metric of System Development Complexity: Validation Results
Authors: Thomas L. Dale , Mog Robert A.
Published: November 2014

Each day, engineers cope with the challenges of building complex systems – challenges which place the project cost, schedule, and technical performance at risk. Can a measure of the inherent complexity of a system provide any insights regarding the risk to cost, schedule, and technical performance? Perhaps it can. This paper briefly reviews the development of a complexity metric and subsequently presents results from a validation assessment. These results indicate a significant relation between system complexity and program development cost.
2.6.1 A Case for Priority Classifying Requirements
Authors: Fellows Larry , Hooks Ivy
Published: November 2014

Prioritizing requirements can play a significant role in reducing requirement problems and increasing customer satisfaction. This paper describes our experiences in teaching requirement prioritization, describes how to prioritize requirements and the benefits of doing so, and describes the responses of our students.
2.6.2 Innovation in the Context of Systems Engineering
Authors: Walden David D.
Published: November 2014

This paper analyzes the relationship between innovation and Systems Engineering. Innovation is essential in high technology companies. However, System Engineering's emphasis on process, documentation, and control is often perceived to inhibit innovation.

We performed an in‐depth literature search on the topics of innovation and Systems Engineering. This research led to the conclusion that Systems Engineering is basically consistent with innovation, with the recognition that radical innovation may require special consideration. We also provide suggestions for better accommodating innovation within Systems Engineering.
7.2. CEENSS and Simulatable Specifications – A Progress Report
Authors: Driver L. , Thullen M. , Gearhart L. , Winn A.
Published: November 2014

The Continuous Electronics Enhancements using Simulatable Specifications (CEENSS) project was begun in 1995 to define a methodology and provide CAD/CAE tools to improve the electronic design process. More specifically, TRW, along with the University of Cincinnati, Motorola and Mentor Graphics, is defining the system requirements methodology for applying formal methods to the specification of board/module‐level products, and the associated impacts to the development process, tool integration, and electronic data interchange (EDI). A key activity of the project is the definition of a Simulatable Specification (SimSpec) that is compatible with and complementary to the methodology. Now in its fourth and final year, CEENSS has met most of its objectives and will achieve additional goals in 1998. This paper presents a CEENSS status report, focusing on accomplishments in enhancing CAD/CAE tools to support the CEENSS methodology.
7.5. Development of the Reference Design Description for a Geologic Repository
Authors: Daniel Russell B. , Rindskopf M. Sam , Teraoka Gary M.
Published: November 2014

As the Management and Operating Contractor for the Department of Energy (DOE), TRW developed the “Reference Design Description (RDD) for a Geologic Repository.” The document describes the current design expectations for a potential geologic repository that could be located at Yucca Mountain in Nevada. The Reference Design Description conveys the surface and subsurface repository and the disposal container design. Additionally, it presents the expected long‐term performance of the potential repository. This paper presents the systems approach used to develop the document. In addition, the role of the Reference Design Description in the overall systems design approach to the Mined Geologic Disposal Systems (MGDS) is discussed. Finally, the overall benefits provided to the Civilian Radioactive Waste Management System (CRWMS) and Yucca Mountain Project (YMP) by the Reference Design Description are discussed.
7.11. Lessons Learned in Applying the Capability Maturity Model to Systems Engineering Process Improvement
Authors: Johnson Howard , Breininger Alan
Published: November 2014

GDE Systems has initiated a systems engineering process improvement program to align with industry movement towards systems engineering process maturity, improve risk management, and focus on up‐front system requirements. The approach was to obtain the current state of the practice from the GDE Systems projects and from industry (INCOSE, SPC, etc). This information was used, together with the Systems Engineering Capability Maturity Model, to establish the company systems engineering process. The initial systems engineering policy and company operating manuals were then generated to establish the process requirements and to document the methodology. The projects were then internally assessed to determine their individual level. The results were used to improve the processes and prepare for a formal appraisal at the end of 1997. The formal appraisal was conducted and future actions were planned to meet Level 3, 4, and 5 goals.
7.12. LPD 17: Adding People and Profit to IPPD
Authors: Dube Chuck
Published: November 2014

In its contract for development of a new amphibious ship, the LPD 17, the US Navy required the use of Integrated Product and Process Development (IPPD). Raytheon Systems Company's Naval and Maritime Systems (NAMS) is one of the four members of the partnership which won the contract. NAMS is leading the Integrated Ship Electronics Team (ISET), the top‐level LPD Integrated Product Team (IPT) responsible for integrating the ship's electronic systems. In a unique adaptation, ISET purposefully enhanced its implementation of IPPD by special emphasis on two additional “Ps” people and profit. This “IPPPPD” approach produced some significant changes in certain program practices and activities. The focus on people manifested itself in how the program chose its team leaders and team members, how it aligned the individual teams and its team structure, and how it shaped the behavior of its people to support its IPPD practices. Its emphasis on profit required its teams to take responsibility not only for their technical work, but also for the related programmatics and contract issues.
7.13. Process Management for Skeptics (or The Case for Process Management in Modern Naval System Development)
Authors: Steiner Rick
Published: November 2014

The need for large, complex systems has fostered a need for large, multi‐disciplined organizations to design, build, and maintain them. At the same time, customers of large, complex systems are demanding unprecedented levels of efficiency and quality. To achieve these demands, builders of complex systems must employ a formal mechanism for managing their design and development processes. Understanding and controlling top‐level processes across large multi‐disciplined organizations, alliances, or consortia, is referred to as “Process Management”. To be successful, any process management activity must have the understanding, input and support of all key participants. This paper was originally developed as a step in getting that understanding and support, especially from domain specialists without any process engineering experience. The arguments presented here are applicable specifically to a large Navy development program, but they may be useful in gaining process management understanding for the development of other complex systems.
7.18. Systems Engineering for Software and Hardware Systems: Point‐Counterpoint
Authors: Sheard Sarah A.
Published: November 2014

Abstract1

Why has a problem between “systems engineers” and “software engineers” been documented every year of INCOSE's existence? Is it because there is a difference between systems engineering of hardware‐intensive and systems engineering of software‐intensive systems, and this difference is not understood or respected? This paper presents several of the issues involved and presents opposing factors for consideration by those who will have to face them, such as hardware systems engineers addressing systems with more and more software components.

The author posted fourteen assertions, based on personal experience, to the INCOSE discussion list server. Twenty responses2were received, providing views, examples, and additional information. Respondents agreed on a number of differences between the systems engineering currently performed on software systems and that on hardware systems. Those differences are thought to be decreasing as software evolves as a field. Recommendations are made for changes that may improve both dialogue and system development.

Open questions generated by the discussions are suggested in the hopes that research efforts may address questions of importance to the improvement of the engineering of systems.
2.1.1 Thought Systems, and Thought Warfare and Anti‐Warfare
Authors: Burke Martin
Published: November 2014

The notion of Thought Warfare and Anti‐Warfare (TWAW) has been introduced in earlier work as a way of thinking about future military conflict and its avoidance. TWAW involves the dynamic interaction of allies' and adversaries' Thought Systems. Current Thought Systems involve entities capable of cognition, emotion and volition ‐ typically (groups of) people ‐ interacting via networks of information and data systems.

This paper summarises a conceptualisation, ie a system of ideas, of the domain of Thought Systems. This affords various new insights that may be of significance to both the Defence and systems thinking communities.
2.1.3 Systems Engineering in Support of Defence Logistics
Authors: Wright D M H
Published: November 2014

The paper examines the application of Systems Engineering (SE) principles to the complex system that is Defence logistic support operations. This system exists at a hierarchy level above that usually considered by SE and is distinct from the more traditional project or product view of a system. The establishment of a unified Defence Logistics Organisation in UK and its ambitious programme of change are described. Central to this programme is the gathering of information to understand and to manage the system more effectively. The paper proposes a programme of modelling and simulation should be established to make best use of the information. This would enable a more accurate understanding to be developed of the dynamic behaviour of the system. If this were achieved, then measures for change and improvement could be introduced, using the principles of systems engineering, thereby making a successful outcome in this complex setting more likely.
4.1.3 Smart Information Architectures – Systems Engineering Information within an Enterprise
Authors: Schulz Armin P. , Igenbergs Eduard , Wehlitz Pamela
Published: November 2014

In the past decades the world has been changing in almost every aspect. Systems development is facing ever rapidly changing and increasingly global environments in markets, competition, technology, regulatory and societal systems.

The resulting increase in complexity within system development can be only handled by mastering the information describing the system (product development data)1. In most companies product development data is captured in an extremely heterogenous environment, that is various proprietary tools along the development processes request, manage, and provide product data. The heterogenity is causing user perceived information losses, in terms of redundant or inconsistent, incomplete, reduced, or mismatched information.

Four properties (user orientation, integrity, adaptability, intelligence) of smart information architecture to overcome these shortcomings are introduced. A structured approach to model and analyze the existing information landscape of an enterprise, to develop a reference architecture incorporating the proposed properties and migrate the existing one, is developed and discussed. An application of the model within an automotive environment and the subsequent implementation of the results within a PDM‐system provide valuable insights as well as validate the basic applicability of the model.

The results presented are based on various research projects with industry the authors have been involved in and in particular a Ph.D. thesis in preparation [Schulz, 2001].
4.1.4 Definition of Enterprise Architecture‐centric Models for the Systems Engineer
Authors: Osvalds Gundars
Published: November 2014

Enterprise Architecture definition provides guidance to the systems engineer so that the enterprise system better reflects the needs of the customer. With the current systems engineering approach, the systems engineer can allocate requirements to systems without considering enterprise‐wide considerations. The architecture‐centric approach for system design provides enterprise‐wide information for systems engineers, who can utilize it to affect systems design. This paper describes Enterprise Architecture and related concepts, and explores the state of the art of Enterprise Architecture and Enterprise Architecture frameworks. The Zachman Framework is used as the basis for creating models of the architecture. This paper proposes a bridging concept to define the models for the architectural perspectives. The bridging process provides a traceable methodology for developing architectural models of the enterprise that are directly traceable to the Zachman Framework primitives, thereby ensuring that the architecture models all elements that are necessary to completely describe the enterprise.
5.1.4 The Benefits of Integrated, Quantitative Risk Management
Authors: Roberts Barney B.
Published: November 2014

There is no question that risk management (RM) has a value much greater than its financial cost for implementation. Hall1reports return on investments (ROIs) on the order of 20–1. While our experience supports this finding, we believe that the return would be much higher given comprehensive metrics. To date, we have been unable to compile metrics as Hall has done because of the collateral effects that occur in application. Thus, we cannot calculate the true cost avoidance based solely on the application of risk management. This occurs because our approach is intense, focused on quantitative analysis, and designed to produce risk‐based decision support information for decision‐makers. We have dubbed the process risk‐based decision support, (RBDS). A particular characteristic of RBDS is the requirement that an ‘integrated’ result be presented to the decision‐maker. That is, the decision‐maker must have a result that integrates the various risk factors (i.e., cost, schedule, technical, mission, etc.) into a single, consistent, parameter for decision‐making – usually cost.

The execution of such a risk management process means stringent demands for quality information are levied on projects. In fact, the coincidental discovery of deficient information during the process has yielded the greatest benefit to programs we have supported with RBDS.

Qualitative techniques typically result in subjective risk estimates of likelihood and consequence such as high, medium, and low. Our intent is not to be critical of qualititative techniques; as a matter of fact, we use them. Furthermore, we find great value in qualitative processes, as they yield quick and efficient communication of risk issues across the program/project.

However, we always go one step further. We implement a triage procedure to discriminate the ‘high’ risks that require further analysis usingquantitativetechniques. These quantitative techniques demand quality information from within the program. Typically, examples of deficient information discovered in our application of RBDS include low‐quality program plans, poor cost estimation, missing project elements, inconsistent integrated master plans and integrated master schedules, poor system‐level requirements, and unstable requirements. Each of these deficiencies themselves constitutes a risk to the program.

In the following pages, we present a discussion of these management risks and how their identification has contributed to the success of numerous programs and projects. For some of our cases, we will provide semi‐quantitative judgments about the ROIs for RM.
6.1.1 Systems Thinking for Managing Projects
Authors: Mawby Dave , Stupples David
Published: November 2014

Systems thinking is a discipline that has developed substantially over the last few decades but most project managers remain unaware of its potential power in helping analyse, refine and deliver their complex projects. In fact, over the past 30 years several hundred of the world's largest and most complex projects have successfully used the technology to improve their outcome. Traditionally, a time‐consuming technique to implement, it has only been utilised for the most complex projects. However, these methods are fast becoming more accessible for large projects in general.

Through modelling the rework cycle and the feedback loops that drive it, using system dynamics it is possible to analyse and hence improve the dynamic behaviour of our projects. In this paper we show how a system dynamics model of a project is constructed and used to assess project outcome. Examples of its application include: cost versus schedule trade‐offs, project improvement strategies, risk assessment and assessing resource constraints. The ability to deliver such answers quickly and accurately during the bid and project definition phases provides the project management team with a powerful decision making tool for project strategy formulation. The improvement in project outcome that can be achieved at this stage of the project is massive because of the low cost of change combined with a high leverage into project commitment, risk mitigation and outcome that is available early in the project's lifecycle.
2.2.2 System Safety – A Medical Perspective
Authors: Elahi Bijan
Published: November 2014

This paper examines safety aspects of medical devices such as: electronics, software, biological, toxicological, physiological, environmental, and even psychological factors. The views of different regulatory bodies in the world on approvals of medical devices are compared and contrasted. Examples of tradeoffs in design of medical devices and issues that face medical device engineers are presented. Risk assessment and mitigation techniques are discussed. Also, legal aspects of medical device safety are visited.
2.2.3 Simplifying Risky Business: An Improved Risk Management Approach
Authors: Shoults John
Published: November 2014

The Risk Management process used on the Theater High Altitude Area Defense (THAAD) Missile Program is discussed. Approaches for integrating risk management activities based upon a simple risk sources checklist questionnaire, standardized assessment templates, and easy‐to‐use tracking templates are presented. The human aspects of implementation, the real keys to success, are discussed. Specific recommendations for achieving success are provided.
3.2.3 An Overview and Assessment of the Current State of Telecommunications Operations Support Systems
Authors: Bassett Brendan
Published: November 2014

The 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

The 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

A 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

This 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

This 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

Over 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

The 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

The 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

No 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

System 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

Technology 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

Standard 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

This 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

The 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

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