bluuebunny/crossref_metadata_2025_split huggingface dataset:
4 The Suitability of Using Objects for Modeling at the Systems Level
Authors: Cocks Dan 
Published: November 2014

AbstractFunctional analysis has been the traditional approach to modeling systems. Now that object‐oriented analysis has essentially displaced structured analysis for software development, it is reasonable to ask whether objects should go on to replace functions for modeling at all levels of system definition. Issues related to modeling notations, methods, and resulting analytical flexibilities are discussed. While the object oriented notations and methods have grown significantly in the past few years, they may not yet be ready to replace functional analysis at the system level.
1 Implementation of a Systems Engineering Tool in the Program Post‐Production Phase
Authors: van Gaasbeek James R 
Published: November 2014

AbstractSystems engineering is applied during the development phase of a program. The continued application of systems engineering concepts during the production, post‐production and disposal phases can contribute significantly to program success. However, the resources available during development are frequently reassigned to other programs once serial production commences, and reduced even further during the post‐production and disposal phases. The introduction of systems engineering tools, even as late as the post‐production phase, can provide a resource multiplier that will allow continued and substantial system engineering support in the face of reduced systems engineering staffing. This paper addresses the implementation of a systems engineering tool late in the product lifecycle.
2 The Age of Process: Applying a Historical Perspective to the Present Day
Authors: Pajerek Lorraine 
Published: November 2014

AbstractWe are in the midst of a period in systems and software engineering that strongly emphasizes the importance of process. Process maturity has been extensively analyzed and codified, and the goal of process maturity has become pervasive throughout industry, government, and the academe. It may seem at times that more attention is paid to the process used to produce a product, than to the product itself.This paper examines the background experiences that led to the development of process maturity models, and deconstructs some of the arguments that have been posited, both for and against. By looking back at the road we have travelled thusfar, we can glean some lessons that may be applied to the path we travel in the future.
2 System Design to Affordability in a Collaborative Systems Engineering Environment
Authors: Myers Kenneth N. , Verma Dinesh 
Published: November 2014

AbstractThe Cost as an Independent Variable (CAIV) concept requires establishing aggressive but realistic total system ownership cost objectives and goals very early during system development. A balanced set of goals are identified through cost, schedule, and performance tradeoffs and the management of associated risk. Subsequently, these ownership cost objectives guide the strategic system architecture, design and technology decisions.The relationships and dependencies between different design views, schedules, and correlating infrastructure need to be rationalized in estimating the system cost of ownership. Furthermore, this has to be done within an environment of continuous flux. This becomes even more of a challenge in a Commercial‐Off‐The‐Shelf (COTS)‐intensive open system environment, with development, production, and system supportability being executed concurrently. The team can exploit a number of synergies that result from such a scenario. However, a prerequisite is the ability and infrastructure for timely and reliable information exchange between the disciplines contributing to design decisions. Effective execution of the CAIV methodology is dependent upon strong integration of multi‐disciplinary processes, methods, information and domain specific toolsets.This paper describes an initiative to integrate a CAIV methodology for COTS‐intensive combat systems engineering into a collaborative systems engineering environment. A pilot effort to implement a common information model within a COTS Product Data Management (PDM) system, CAIV processes, and engineering tools supporting the execution of COTS‐based combat systems design is described. Future extensions to the information model, the systems engineering processes, and the collaborative engineering environment supporting combat systems design, development, and life cycle engineering activities are presented.
3 Mitigating the Risks and Increasing the Gains From Teamwork
Authors: Harrison Barbara , Dube Charles 
Published: November 2014

AbstractTeams hold the potential for outperforming other types of work structures in complex circumstances, but many fail to deliver on this promise. Such failure can threaten the success of an entire project or program. In their work with teams, many of them complex in structure and makeup, the authors have developed a fairly simple and inexpensive process for forming and aligning teams that can significantly reduce the risk of team failure. While the process is fairly simple, the implementation of that process is not.
2 A Systems Engineering Framework for Integrated Automotive Development
Authors: Loureiro G. , Leaney P. G. , Hodgson M. 
Published: November 2014

AbstractThis paper proposes a systems engineering framework for integrated automotive development – the total view approach. It is a modelling framework that integrates the product, its life cycle processes and their associated organisations throughout the requirements, functional and physical analysis processes, at all levels of the product breakdown structure, deriving attributes as emergent properties of a whole integrated system. The paper justifies the framework through a review of traditional and current automotive development and two case studies.
3 Initial lessons of model‐based systems engineering for small commercial product development in the electrical domain (for Uninterruptible Power Supply System)
Authors: PAOLI Claude DE , Parrot Olivier , Rouge Alain , Dutey Catherine 
Published: November 2014

1 ABSTRACT AND INTRODUCTIONFor years the development of systems engineering has been led by industries and systems that can be characterized by single‐customer projects and large systems with long development life‐cycle. As market starts to be driven by other features (smaller systems and shorter projects, mass commercial products), it is necessary to examine how far current systems engineering practices support the new rules and whether these new rules affect established systems engineering practices. This is of course an ambitious and long‐term job but this article would like with other papers sharing the same concern and presented at INCOSE'99 to pave the way for this endeavor. We present herein the intermediate results of an experiment carried out by MGE UPS Systems, a world class provider of Uninterruptible Power Supply (UPS) systems and that investigates the interface between marketing and engineering to identify if better work in this area can improve time‐to‐market.
1 An Application of Object Oriented Systems Engineering (OOSE) To an Army Command And Control System: A New Approach to Integration of System and Software Requirements and Design
Authors: Meilich Abe , Rickels Michael 
Published: November 2014

AbstractThe purpose of this paper is to demonstrate how an Object Oriented Systems Engineering (OOSE) methodology developed at Lockheed Martin (LM) Management and Data Systems (M&DS) is being applied to the Army Global Command and Control System (GCCS‐A). This system is now migrating from a legacy Army system to a modern integrated Army wide system that supports the Joint GCCS. The focus of this paper is on providing practical examples of how some fundamental issues for using System Engineering methods (previously accomplished with structured analysis and design techniques) in conjunction with software OO methods were resolved using this OOSE methodology. These include: (1) how the system and software requirements specification must be synchronized; (2) capture of requirements and system design information using Object Oriented (OO) techniques and relationships; and (3) using the system objects to better manage the allocation of functionality in the system, maintenance of a legacy system, and ease of system analytical model maintenance during periods of requirements change.
2 Building a re‐use infrastructure: Optronics Reference Architecture and Layered Reference Model
Authors: Sillitto H.G. 
Published: November 2014

AbstractPilkington Optronics supplies sensor equipment and systems to a wide range of customers. These systems generally follow one of a few recognisable “design patterns”. However with a few notable exceptions re‐use between projects is limited.The company wants to improve the leverage of its substantial technology investment into products; and to reduce the amount of investment required to produce variants and derivatives of current products.To facilitate effective re‐use it is necessary to provide a common framework for identifying reuse opportunities. Several complementary tools established to provide this framework are presented. They include the “Reference Optronics System Architecture”, which describes a superset of all optronic systems at a particular level of decomposition; and the “8‐layer optronic system reference model”, an analogue of the OSI layered model for processing systems.The paper describes these models and their significance for management of re‐use, technology planning, and teaming relationships.
3 The Systematic Methodology of Inventive Problem Solving ‐ TRIZ: A Review
Authors: Savransky Semyon D. ,   The TRIZ Experts
Published: November 2014

AbstractThe weak point of traditional methods of innovation management is transformation of customer needs to the concept of new technique. Usually some creativity methods are used, but most of such methods cannot guaranty optimal result. TRIZ is a methodology to solve problems as close as possible to the Ideal Final Result by clarifying functions of the system under consideration even if contradictions rise during problem solving. The TRIZ methodology for inventive problems solving is used for the innovative resolution of various technical and physical contradictions in the artificial systems. TRIZ methodology developed by G.S. Altshuller, the author and TRIZniks in the former Soviet Union during last 50 years is reviewed. It is shown how TRIZ provides a possibility to find the best conceptual design of a new technique.
4 V & V in Plain English
Authors: Lake Jerome G. 
Published: November 2014

AbstractThe purpose of this paper is to discuss in plain English the role of V & V in confirming that a system product conforms to its appropriate set of related specified requirements. It is not expected that this discussion will once and forever settle the differences that exist in perceptions and practices of V & V. It is the intent, however, to remove some of the confusion and misunderstanding surrounding V & V with the expectation that the engineering of a system can thus be improved.This paper first presents the basic concepts for engineering a system in order to place the functions of end product V & V in context. Second, the confusion and misunderstanding of V & V found in existing standards are pointed out and resolution provided. Third, considerations for proper implementation of V & V are given so that “verification” and “validation” can lead to efficient and effective engineering of world class systems.
1 Workgroup Software Tools applied to the Space Shuttle Orbiter Configuration Change Impact Assessment Study Process
Authors: McCallister Timothy P. , Weeks Donald P. , Hines James E. , Ouellette Fred A. 
Published: November 2014

AbstractThe Space Shuttle program is transitioning from the development phase to the operational phase. The National Aeronautics and Space Administration (NASA) is restructuring the management of the Space Shuttle Program by turning over the day‐to‐day operations to a prime contractor, United Space Alliance (USA), a joint venture partnership between Boeing and Lockheed Martin (LM). Most Space Shuttle related contracts have been consolidated into one Shuttle Program. This consolidation move is intended to save millions of dollars in costs by eliminating duplicate resources, streamlining operations, and reducing nonessential program requirements. NASA, USA, Boeing and LM are working closely together to provide the American public a Space Shuttle Program that continues to be technically viable, safe, and now more cost effective. Central to organizational consolidation and expected efficiency gains is ensuring people from all organizational elements of the program think and work together as integrated teams.Shuttle ground processing and flight operations have been consolidated under the USA banner. The Orbiter hardware/software design center remains at Boeing. NASA retains configuration control of the Shuttle system. This new arrangement, while providing efficiencies, can present challenges. Diverse requirements and incentives must be considered in identifying and implementing technically viable, safe, and cost effective changes while maintaining the design baseline configuration of the Orbiter. A concurrent engineering team process involving NASA, USA and Boeing is used to resolve design configuration issues when they arise. This paper deals specifically with the application of Lotus Notes workgroup software technology and the Internet to provide an on‐line collaborative environment used during configuration change studies. This environment facilitates the use of a systematic concurrent engineering process by study teams as they assess proposed Orbiter modifications.
2 A Requirements Driven Approach to Synthesis of Military Satellite Communications Payloads
Authors: Henkle Thomas G. 
Published: November 2014

AbstractThis paper presents a structured approach to synthesizing communications payloads based on expressed requirements of a military client. The approach stresses the functions performed by a communications payload rather than technologies that facilitate their implementation. Benefits of a structured approach include increased focus on client requirements, timely development of realistic payload concepts, enhanced acceptability of those concepts, and a more robust design relative to technology driven designs. A process model is developed. Payload synthesis models are presented.
3 Metrics for Full Systems Engineering Lifecycle Activities (MeFuSELA)
Authors: Tugwell GC , Holt JD , Jobling CP , Neill CJ 
Published: November 2014

AbstractComplexity is perhaps the single most cited cause of project failure. Complexity exists throughout the whole of the project lifecycle and is not always apparent until the project is running into difficulty. The aim of this paper is to present a suite of metrics that can be used to highlight complexity at all phases of the project lifecycle, rather than just after the system has been built. A basic assumption of the work is that all models for the system are represented using the industry standard Unified Modelling Language (UML).
4 Taming the Expanding System Complexity of a Commercial Product: Embracing Systems Engineering Principles in a Commercial Development Environment
Authors: Miller Paul 
Published: November 2014

AbstractThe development momentum of complex commercial products are often choked by an interminable cycle of test and corrective action that devours and overwhelms valuable resources. The root cause of this class of problem is that traditional commercial development environments do not make use of sound Systems Engineering principles as their products mature into highly complex systems. This paper provides an account of how Fujitsu Australia's Telecommunications Research and Development (R&D) centre is exploiting the years of experience gained by the Aerospace and Defense industries, and adapting their highly tuned and proven Systems Engineering practices into the commercial development environment. The centre piece of this paper is the adopted generic Systems Engineering Model that has become the central focus of development capability maturation within the R&D centre.
Optimizing Systems Engineering Specification Quality Control Processes
Authors: Gilb Tom 
Published: November 2014

AbstractInspection is a proven technique for achieving quality control of specifications and, identifying associated process improvements. In fact, Inspection can be applied to any discipline which produces documents. It has been applied with excellent results to hardware engineering (e.g. aircraft and electronics), management and sales contracts documentation.Software Inspections are widely known within the software industry, but most organizations do not make the most of them. This is because many people misunderstand and misinterpret Inspection. This paper aims to provide some direction as to how to get the most value from your Inspections.
Enhance Quality in Complex Systems with a Common Project Model
Authors: Ogren Ingmar 
Published: November 2014

AbstractComplex systems concern multiple stakeholders and will often have multiple system representations such as the “real system” and various simulators. If the understanding of the system differs among the stakeholders and if the system representations differ from the “real system”, this is a quality problem.One way to attack this quality problem is to create a “Common Project Model (CPM)”, which is then common in two ways:
it is common among the system's stakeholders
it is common among the different representations of the system.
To build a useful CPM, you need a tool‐supported modeling technique, which is understandable and sufficiently formal to model the structure and behavior of a complete system including the missions of the system with their connection to the different components in the system.The CPM should preferably be evolved together with the system. It can then be used to support various technical and application activities.
Introducing Requirements Engineering for the Basic Engineering Phase of Automation Concepts
Authors: Wenzek Hagen R , Scherff Birgit 
Published: November 2014

AbstractBasic engineering for automation concepts becomes more demanding for the companies that want to employ state‐of‐the‐art technologies. To overcome the typical heuristic processes in the planning departments and to respect the high significance that software now has for automation technology, requirements engineering is being introduced for this matter. This paper describes the important aspects that need to be considered in the plant engineering context, how tools and methods can be implemented and what evaluations are being done.
Year 2000 Triage for Non‐IT and Embedded Systems
Authors: Biggs Bruce B. , Jackson Harry 
Published: November 2014

ABSTRACTThis paper describes the Year 2000 (Y2K) problem and explains how it extends beyond the renovation of application software, to operating system software and embedded systems. It will show why fixing the Y2K problem in embedded systems will be difficult, yet crucial to preserving the defense of our nation ‐ and specifically maintaining our warfighting Command and Control (C2) systems. It also discusses the Enterprise TriageSM methodology, a Y2K solution based on the idea that mission‐critical system changes, and the risks to the systems' operation, must be identified and addressed as early as possible.
Infrastructure Management Model: A Case for Examining Relationships
Authors: Godau Ralph I. 
Published: November 2014

ABSTRACTTraditionally, infrastructure management has been the realm of the technocrats. This has led to the assessment of infrastructure systems as standalone technical entities as opposed to a interdependent homologous systems comprising technical, social, environmental, economic and political influences.Recent infrastructure 'crises' in Australia highlights a need to have a fresh outlook and examination of the way infrastructure is managed.This paper explores the concept of using visual qualitative analysis for examining and capturing the complex nature of the relationships that bind infrastructure management systems together. This will be done through the examination of stakeholder perceptions in relation to current infrastructure management practices.
Implementing Risk Management as part of a Systems Engineering Process
Authors: Laporte Claude Y. , Boucher Guy 
Published: November 2014

ABSTRACTDuring the last five years, Oerlikon Aerospace developed and implemented engineering processes. In this paper, we discuss the application of risk management to the re‐engineering of operator console stations of a missile weapon system. We briefly describe the systems engineering process. Finally, twelve lessons learned are discussed.
4 Who Teaches Whom
Authors: Ball Jenny , Ogleby David , Hardaker Chris 
Published: November 2014

ABSTRACTAs we are all well aware, Systems Engineering is a diverse field. It is a changing field. It means different things to different people. The words ‘Systems Engineering’ are difficult to define in one phrase that people can agree on and that means something tangible. Given these factors, the task of providing training in Systems Engineering is fraught with difficulty from the outset. Add to that a delegate base from a large, diverse, geographically disparate organisation, and you have quite a challenge. This, however, is the arena in which we work, and this paper describes some of the approaches we have taken and lessons we have learnt in providing Systems Engineering training for the Marconi branch of the General Electric Company over the last few years.
Managing in an Environment with a Level 1 Customer
Authors: Radke Neill B. 
Published: November 2014

AbstractFrequently, a systems development organisation encounters a customer that can be characterised in terms of the Systems Engineering Capability Model (SECM) as a Level 1 organisation. The developer must identify that customer as Level 1 early in the project development cycle and manage the project accordingly. Agreement must be reached with the customer as to what is to be built and how the system will be accepted. Requirements and acceptance criteria must be clearly defined and negotiated with the customer.
Process Measurement: How It Changes As Process Maturity Increases
Authors: Minnich Ilene 
Published: November 2014

AbstractMany of the domains we work with every day are described by Capability Maturity Models® – including systems engineering, software engineering, secure systems engineering, etc. Each CMM describes the domain's primary process activities, as well as methods for improving the organization's ability to perform its processes. But in order to determine a process' current capability level, as well as to be able to improve a process, certain measurements must be in place. How do we know what measurements to take? How do we know if the resultant number(s) are “good enough”? How do we know what changes to make to our processes based on the measurements? And how do the characteristics of the data and our resultant actions change as our organization's processes move up through the maturity levels? This paper will give a brief look at each of these issues.