bluuebunny/crossref_metadata_2025_split huggingface dataset:
5.6.3 The Systems Engineering Life‐Cycle Process Functional Working Group A Government / Industrial Partnership
Authors: Johnson Robert , Cheetham Christina , Fisher Gerard H. , Quinn Anne , Smith Dennis 
Published: November 2014

ABSTRACTThe Department of Defense (DoD) has recognized the relationship between good systems engineering and products that meet the customers' needs. The DoD Joint Logistics Commanders (JLC) Joint Group on Systems Engineering (JGSE) has commissioned a new functional working group called, Systems Engineering Life Cycle Process (SELCP). In July, SELCP sponsored a Systems Engineering Workshop in San Diego. The attendees were experts in systems and software engineering from industry, academia, INCOSE, IEEE and government. The issues associated with this new paradigm were discussed, a forward action plan was developed and expectations for continued cooperation were assured.This paper will describe the motivations that led to renewed government interest in systems engineering, the results of the San Diego Workshop and future plans for SELCP to collaborate with INCOSE and other industrial organizations. Joint meetings have been held with several working groups of INCOSE and plans are in place for collaboration on new systems engineering products. This cooperation between government and industry will help to ensure high‐quality products that meet customer requirements and expectations.
7.3. Crusader System Engineering Tool Set Continuous Improvement Process
Authors: Eidenschink Bruce , Kee‐Bowling Bonnie , Laedtke Patricia , Sanyal Saumya , Schweikert Tim , Zimmermann Roger 
Published: November 2014

ABSTRACTImplementation of system engineering tools on large scale development programs require mechanisms that allow for the continued evolution of the selected suite. The initial requirements for a system engineering tool selection will change and evolve as in any system. A program will have changing objectives, champions, and organizations as it progresses through its life cycle. Awareness and use of accepted industry practices for improvement to this type of system have proven vital to its evolution. This paper presents the process and techniques used for evolving one such tool suite within an Integrated Product Development (IPD) organization on Crusader, a major Department of Defense (DOD) development program.This paper documents 4 years of lessons learned during the support, maintenance, and evolution of the Crusader System Engineering (SE) Computer‐Aided Engineering (CAE) tool environment from its initial selection to its current configuration. The tool set, consisting of Requirements and Traceability Management (RTM), Requirements Driven Development (RDD‐100), and Interleaf, has undergone two process improvement cycles. The process, events, and outcomes are described within this paper.
7.9. Integrated Product and Process Development and the Use of Integrated Product Teams
Authors: Leibrandt Rob , Gunther Dave 
Published: November 2014

ABSTRACTThis paper seeks to examine the importance of Integrated Product and Process Development as demonstrated within the Department of Defense. We have focused on 3 major areas of focus. One is IPPD's focus on product and process life cycle, the second is the way stakeholders are integrated into the process early, and the third is concurrent development of the product and processes.Focusing on the life cycle means that the IPPD process plans for and manages product and process development from inception to disposal. Stakeholders are defined as important decision‐makers that have a stake in the decision at hand or the outcome of the program. Stakeholders must be included from the beginning. Lastly, we discuss the development of processes concurrently with their products. What are the processes that we want to integrate with the design and development of the product?Each of these areas is first described in detail and then specific examples of systems development efforts, which employed the technique, are described. Specific benefits and results in these examples are used to “drive home” the importance of integration or concurrency of product and process development.This paper is the basis for the development of a videotape which will be complete prior to the INCOSE conference. Very short segments of the video and/or CD‐ROM will be used if this paper is chosen for presentation.
7.10. Integration of System Engineering Tools
Authors: Rader Jock 
Published: November 2014

ABSTRACTIntegration of tools is a major issue in the provision of a useable set of tools to support system engineering. Integration can be approached from different perspectives including: infrastructures (middleware), and the integration characteristics of individual tools. This paper concentrates on integration mechanisms which a given tool might enjoy. A major portion of the paper looks at application programming interfaces (APIs) which provide the most complete range of integration possibilities: and the various dimensions of APIs are analyzed. Also discussed are internal programming languages, filters, modification of internal tool files and shared repositories. Tool enhancement techniques are mentioned in places because they are so intertwined with integration. In order to make intelligent choices of tools to support systems engineering for a project or organization, it is necessary to understand a wide range of tool integration properties in detail.
7.15. Risk in Risk Management
Authors: Armstrong James R 
Published: November 2014

ABSTRACTAlthough there has been a great acceptance of risk management over the last decade, there is still room for improvement in the practice. As with any new idea, there have been multiple variations developed in application. The situation doesn't warrant a grand effort to standardize. However, the practitioner should be aware of the differences and the risks inherent in applying risk management.With any new concept, there will be a drive for both better theoretical understanding and application to new areas. One example in the case of risk management is the application to software. However, the resulting more detailed theoretical description of risk has created a conflicting set of definitions that can cause problems when merged with the original versions. One part of this paper looks at both views and seeks to explain what the differences are, their potential impact, and which way a project lead should go when faced with such a conflict in definitions.
1.1.2 Ground Data System Risk Mitigation Techniques for Faster, Better, Cheaper Missions1
Authors: Catena John , Saylor Rick , Casasanta Ralph , Weikel Craig 
Published: November 2014

AbstractWith the advent of faster, better, and cheaper missions, NASA Projects acknowledged that a higher level of risk was inherent and acceptable with this approach. It was incumbent however upon each component of the Project, whether spacecraft, payload, launch vehicle or ground data system, to ensure that the mission would nevertheless be an unqualified success.The Small Explorer (SMEX) program's ground data system (GDS) team developed risk mitigation techniques to achieve these goals starting in 1989. These approaches have developed through the SMEX series of missions and are practiced today under the Triana program. These techniques are:
Mission Team Organization – Empowerment of a close‐knit ground data system team comprising system engineering, software engineering, testing, and flight operations personnel,
Common Spacecraft Test & Operational Control System – Utilization of the pre‐launch spacecraft integration system as the post‐launch ground data system on‐orbit command and control system,
Utilization of operations personnel in pre‐launch testing – Making the flight operations team an integrated member of the spacecraft testing activities at the beginning of the spacecraft fabrication phase,
Consolidated Test Team – Combining system, mission readiness and operations testing to optimize test opportunities with the ground system and spacecraft, and
Reuse of Spacecraft, Systems, Standards, and People – Obtaining greater efficiencies through reuse of common spacecraft components, flight and ground‐based subsystems, standardized interfaces, and project team personnel.
The SMEX ground system development approach for faster, better, and cheaper missions has been very successful. This paper will discuss these risk management techniques in the areas of ground data system design, implementation, test and operational readiness.
2.1.2 Practical Experience Applying Business Process Reengineering to US ARMY Airworthiness Qualification
Authors: Branson Ronald , Hughes Timothy , Pratcher Rebecca 
Published: November 2014

AbstractThis paper relates the experiences of the US Army Aviation & Missile Command team chartered to reengineer the Airworthiness Release and Qualification Process. Specifically, it reviews the processes the team used to identify issues and problems with the current process; development of recommended approaches for changes; definition and modeling of the current and “to be” processes; and lessons learned selling the new and improved process to the leadership and to the action officers.
2.1.4 Managing the Wood not the Trees ‐ The Smart Acquisition Approach to Systems of Systems
Authors: Arnold Stuart , Brook Peter 
Published: November 2014

AbstractThe challenge of Systems of Systems has particular significance in the acquisition, deployment and operation of defence equipment. In the UK, MOD sees that a major part of the solution to the effective creation, use and evolution of defence SoS lies in particular improvements in organisational structure, in project responsibilities and in the definition and application of systems engineering processes. These three areas of change are providing a framework for tackling SoS issues. MOD's Smart Acquisition initiative is leading to management structures and responsibilities, at the executive and project levels, and to technical processes that more effectively meet the SoS challenges.
6.1.4 Modeling Objectives on Cost in a Decision Maker's Value Structure
Authors: Snyder Frank J. , Parnell Gregory S. 
Published: November 2014

AbstractMulti‐objective decision problems involve trading off conflicting objectives and sacrificing resources (often money) to gain some level of performance or some compliment of attributes from the alternatives. This paper considers whether or not the objective of minimizing cost should be included as part of the fundamental objective hierarchy when modeling a decision maker's value structure. Specifically, it examines two approaches to representing cost (financial resources) in a value structure. In the first, minimizing cost is treated as a fundamental objective that should be included in the value structure. This approach suggests that a single numerical index should be used to rank‐order alternatives. In the second, minimizing cost is treated as an attribute of an alternative that is separate from the value structure. This second approach suggests that an alternative's utility can be plotted against the cost providing a set of utilities and associated costs. This paper explores and reports findings of interest in modeling the objective of minimizing cost.
7.1.4 Automatic Generation and Verification of Design Specifications for Railway Signalling Applications
Authors: Robinson Neil , Kearney Peter , Tombs David , Barney David , Nikandros George 
Published: November 2014

AbstractWe describe a project to develop a set of design tools for a railway signalling application, which is safety critical and has complex functional requirements. The toolset generates design specifications from functional requirements and verifies them against safety principles. The project addresses the overall engineering design process and has applicability to other domains.
8.1.1 Adding ‘ilities’ to Capability Maturity Modeling: The Safety CMM
Authors: Plowman Catherine , Alessi R. Sam 
Published: November 2014

AbstractBuilding a strong behavior‐based safety culture within an organization is accomplished by evaluating its current safety climate and designing organizational changes in a way that will prevent occupational injuries, minimize work‐related illnesses, and promote better safety practices. The organizational changes must be integrated across the complete business environment in order for safety to become truly institutionalized. Currently, few approaches to safety improvement are effectively integrated. To address this need the INEEL is developing a new method entitled Safety Capability Maturity Appraisal. This work is based on a popular approach used by the Department of Defense and the Federal Aviation Administration to evaluate organizational, management, and technical performance. The approach uses an extensive normative questionnaire to establish a baseline of organizational performance, then conducts exploratory interviews with a sample of the organization's personnel to gain greater understanding of the underlying cultural issues that prevent change. An organization is scored on a maturity scale that measures its current capability to perform work in a systematic manner. Finally, an organizational intervention plan is designed and implemented that includes simultaneous changes to organizational, management, and technical business areas. Although Capability Maturity approaches have been used successfully, they currently lack the ability to assess the component of safety within an organization. Our current research is testing a comprehensive set of safety‐related questions that we have added to an existing Capability Maturity model. An experimental design will be used to determine the extent to which a safety capability maturity appraisal can provide valid information for the design and implementation of timely organizational changes that enhance both business and safety related practices. The initial research will be performed at Yellowstone National Park during the first quarter of 2001.
3.2.1 The Regulatory History and Environment for Development of Telecommunications Systems in the United States
Authors: Mackey William F. 
Published: November 2014

AbstractThis paper explores the development of telecommunications systems in the United States as a result of regulation and deregulation of the telecommunications industry. The systems engineer should understand evolution of the structure of the telecommunications industry from multiple viewpoints. This paper examines the industry from the legislative history, major court decisions, and the regulatory activities of the federal and state governments. A comparison of the Telecommunications Acts of 1934 and 1996 is developed and the historical environment, as well as the technologies and innovations that stimulated their creation, is also examined. The thesis of this paper is that the telecommunications industry is creating global changes that will alter the international community during the 21st century more significantly than the industrial revolution did in the 19th and 20th centuries.
3.2.2 A Systems Approach to Telecommunications Regulation
Authors: Mackey William F. 
Published: November 2014

AbstractThis paper explores the global development of the telecommunications industry using the United States as the primary example for telecommunications regulation and deregulation. The systems engineer must be prepared to examine the development of the telecommunications industry from multiple viewpoints. This paper examines the industry from several viewpoints including a legal viewpoint, regulatory process viewpoint, and economic viewpoint. The present global changes in privatization and liberalization are also examined in the United States, Europe, Latin America, the Asia‐Pacific region, and Africa and the Middle East. The thesis of this paper is that the telecommunications industry is creating global changes that will alter the international community during the 21st century more significantly than did the industrial revolution in the 19th and 20th centuries.
4.2.4 An Enterprise‐Wide Systems Engineering Process Improvement Framework
Authors: Walden David , Shi Yan‐Chi , Kennedy Alan 
Published: November 2014

AbstractGeneral Dynamics has established an enterprise‐wide Systems Engineering process improvement framework. The General Dynamics Technology Council sponsors several Corporate Technology Area Teams (CoTATs), with one specifically focused on Systems Engineering. This paper addresses the successes, challenges, and lessons learned in the establishment, execution, and evolution of an enterprise‐wide Systems Engineering process improvement activity.
6.2.1 A fresh view on model‐based systems engineering: The processing system paradigm
Authors: Muth Thomas , Herzberg Dominikus , Larsen Jens 
Published: November 2014

AbstractModel‐based systems engineering and graphical notations have an enormous potential for increasing design productivity, system quality and lifetime by shifting the bulk of design efforts to early phases. In spite of that this is hardly questioned, the shift towards model‐based approaches has not come to a break through, as we are experiencing in software engineering. It is believed that a major reason is lack of a common system view that can act as a framework for developing modelling languages and methods for a broad community of system engineers.This paper suggests such a framework. It identifies the systems of concern as a processing system that consist of a process control system and a resource system, and applies two related views on processing systems: A functional view and a solution view. The framework has been successfully tested on telecommunication systems and networks for some years. It is believed that it holds for many other system domains as well.
6.2.4 Investigating Risks in Systems Engineering Tool Data Exchange
Authors: Herzog Erik , Törne Anders 
Published: November 2014

AbstractData exchange capabilities are generally regarded as a desirable (but in many cases absent) property of systems engineering tools. While such capabilities are desirable it is also the case that there is a substantial risk that tool data exchange impose modifications to the data transferred. In this paper we illustrate how modifications are introduced based on the capabilities of individual tools, present an analysis of potentially adversary effects of data exchanges and discuss measures for preventing data exchange related errors from being introduced in a specification. The paper also discusses requirements for data exchange information models for heterogeneous domains to support representation of multiple semantic variants of basic concepts. Aspects of the emerging ISO standard AP‐233 is evaluated against these requirements and an example is presented to illustrate the point.
7.2.1 Help! How Do I Make My Organization Comply With Yet Another New Model?
Authors: Sheard Sarah A. 
Published: November 2014

Abstract“Help! We have to revise all our ISO 9000 processes to meet the CMM!” Or, “Help, we're compliant with the CMM but now we have to write new processes for ISO 12207!” Or, “I don't want to write systems engineering processes to EIA/IS 731 because I'm only going to have to rewrite them to CMMI.”If these sound familiar, it is because organizations are currently faced with the prospect of having to shift their process improvement attention from a current model, such as EIA/IS 731, ISO 9000, or the Capability Maturity Model for Software (SW‐CMM) to a new model, such as the Capability Maturity Model Integrated (CMMI)sm.1 To some shifting seems a daunting feat; in many cases it has taken years to adapt to the current model, and to start all over seems to negate the value of the current investment.This paper shows that capability models (and other process standards such as ISO 9000) generally ask the organization to do similar or identical things, and adopting a new model should be approached as mapping and modifying rather than as starting over.
7.2.3 Is it only Systems Engineers that do Systems Engineering?
Authors: Hoyle Tim A. 
Published: November 2014

AbstractMisunderstanding and confusion surround the use of the words “system”1 and “systems” in conjunction with engineers and engineering. Some engineers describe themselves as systems engineers but does this tell us what they actually do? Some organisations describe themselves as producing software systems; does this mean they need only software engineers to do this? The words “system” and “systems” are all‐embracing terms which at the corporate level can usefully indicate an ability to take on large complex engineering tasks but when used at a more local level can obscure and confuse an individual's roles and tasks. Such confusion hampers communication, understanding of project responsibilities, allocation of project resources and identification of recruitment needs.This paper summarises how a business formed from many legacy organisations is adopting a common engineering process model and language to describe its engineering activities. It concludes that the use of the qualifier “systems” is not helpful in conjunction with the individual engineer. There are two reasons for this: ‐ i) systems engineers require different skills in their various roles and ii) engineers need to do systems engineering whatever their level in the project hierarchy.
8.2.4 The Successful Application of Risk Analysis To The Redesign of a Major System
Authors: Palmer John A. , Dechoretz Jason A. 
Published: November 2014

AbstractThe Crusader, a new, state of the art self propelled howitzer system for the US Army, has been designed and a firing prototype is in the field for test. However, the Army Chief of Staff has determined that a much more mobile and transportable system of armored vehicles is necessary for the US Army to successfully project force and respond to urgent situations on the battlefields of the future. As a result, he directed that Crusader be drastically reduced in weight within a short period of time. The purpose of this paper is to describe how risk assessment and analysis were applied to materially assist in successfully reaching the Chief's goal without the need to completely redesign the vehicle.
2.3.1 On the Acquisition of Systems of Systems
Authors: Cook Stephen C. 
Published: November 2014

AbstractIn this paper we examine the term “Systems of Systems” (SoS) and form a distinction between them and large monolithic systems based on system attributes and acquisition approaches. Importantly, for this paper, one of the distinguishing attributes is that SoS are formed from component systems that are acquired using multiple asynchronous projects. We raise the issue that the current stovepiped, project‐centric, prescriptive acquisition paradigm is not well suited to the acquisition of component systems for military systems of systems. The paper proceeds to identify more detailed issues that need to be addressed to improve acquisition outcomes and provides some mitigation strategies. The major recommendations are to increase the influence of top‐down, force‐structure planning, move away from project‐centric capability development and acquisition to broad, force‐area development, and to raise the importance of systems characteristics that will enhance their ability to be integrated into systems of systems, such as, adaptability, flexibility, and open interfaces.