bluuebunny/crossref_metadata_2025_split huggingface dataset:
1.2.2 Standards: Their Significance, Uses, and Potential Meaning to the Systems Engineering Community
Authors: Velman J. R. , Widmann E. R. 
Published: November 2014

ABSTRACTWithin the technical disciplines, there has been a renewed interest in standards, especially in the commercial sector, over the past few years. With respect to systems engineering, this has been evidenced by the generation of two complementary standards, EIA 632 Processes for Engineering a System and EIA/IS 731 Systems Engineering Capability, both of which were prepared with the joint participation of the EIA and INCOSE. This paper provides an overview of the various types, or categories, of standards with the intent of providing a basic understanding of standards and their use, which have often been misunderstood. Some examples of the use of standards are provided from both the past and present. The paper concentrates specifically on those aspects of standards of importance to systems engineering. Directions proposed by the INCOSE Standards Task Force for INCOSE to pursue in the future with respect to standards are then explored. The paper concludes with a glossary of standards making organizations of interest to systems engineering.
2.2.1 The Value of Integrated Project Risk Management
Authors: Stump Evin J. , Ferguson Kevin 
Published: November 2014

ABSTRACTCurrent initiatives and trends emphasize more aggressive management of project risks. Traditionally, project risk management, when practiced at all, has been a “top down” activity involving mostly the project manager and perhaps a designated risk manager with input from selected individuals. The proactive participation of project teams was not sought. The customer was not part of the process. The process seldom required any quantification or risk metrics, although that is commonplace in other project areas. This paper describes a methodology called integrated project risk management that involves project teams and the customer, and uses a mathematically simple but valid method of quantification easily adopted by project teams. It has been used successfully on two major U.S. Air Force projects.
5.2.2 SYSTEMS BEGET SYSTEMS
Authors: Grady Jeffrey O. 
Published: November 2014

ABSTRACTProduct systems are created by process systems otherwise known as contractors, developers, suppliers, or enterprises. Owners of these process systems seldom consider themselves systems so they commonly fail to take advantage of the same powerful development process that they may be very proficient in applying to develop product systems to improve, develop, or re‐engineer their own system.This paper offers some parallels between the structured analysis process applied for the purpose of developing product systems and the application of the same process for developing the enterprise. This application is then extended to couple the enterprise identity thus formed to multiple program planning suites through a seamless planning transform.
2.3.1 Object Oriented Systems Engineering – An Approach
Authors: Hopkins Frank W. , Rhoads Russell P. 
Published: November 2014

ABSTRACTThis paper presents an approach for preparing an object oriented system design specified by object oriented specifications derived from functionally oriented customer requirements. The approach emphasizes review of each individual customer requirement to extract individual objects that may be called out or implied. Value type characteristics contained in the requirement are mapped to attributes of the objects. Interaction between objects is captured as associations and becomes the basis for scenarios or event message diagrams. By capturing the stated or implied objects, their attributes and their interactions, we find the entire requirement can be captured.The Object Based Systems Engineering methodology offers many benefits that should not be ignored including simplification of presentation, ease of preparing subordinate specifications, clear definition of interfaces, modularity in design, and smooth transition to software development.
2.3.2 Model‐Based Systems Engineering And Object‐Oriented Software Engineering: An Integrated Approach
Authors: Ali Michael 
Published: November 2014

ABSTRACTIn this paper, we explore the interface between model‐based systems engineering (MBSE) and object‐oriented software engineering (OOSE). We show that the context, behavior, and structure models captured by the systems engineering process are precisely those inputs needed to start the object‐oriented software engineering process. Conversely, the object‐oriented architecture generated by the software engineering process is needed by systems engineering to perform object‐based rather than function‐based architecture synthesis.
5.3.4 Some Experiences in the Use of Modeling to Support the Systems Engineering Process
Authors: Chan Norbert , Jansen Craig 
Published: November 2014

ABSTRACTThis paper describes how modeling and simulation can be used to support the overall system engineering (SE) effort. The authors draw from their experiences as communications systems engineers in the 1.4 billion dollar “Iris” program in which the next generation of communication systems are being delivered to the Canadian army by Computing Devices Canada (CDC). We demonstrate with examples, how modeling has made the SE effort more effective in the major phases of SE.
2.4.4 Commissioning a Distributed Operational Information Management System
Authors: Eagles Andrew , Smith Don , vanSpronssenm Rob 
Published: November 2014

ABSTRACTTransitioning a distributed information management system into live operations is performed over a period of time, using an incremental buildup strategy to establish and verify data, functionality, external interfaces, infrastructure and organization. These five operational views of the System have dependencies which must be identified, controlled and managed during the pre‐commissioning process.The system pre‐commissioning plan, which addresses the relationships between the operational views of the system, is bound by multiple constraints. This planning is also influenced by issues which face both the client and the vendor, independent of the information management system itself. The system pre‐commissioning plan is a “living” document, it is constantly being updated as the activities progress and new dependencies and issues arise.After successfully commissioning several such systems, MacDonald Dettwiler has learned valuable lessons which will benefit future pre‐commissioning activities.
5.4.1 Systems Engineering in Developing Nations
Authors: Applegate John D. 
Published: November 2014

ABSTRACTSystems Engineering has become a recognized engineering discipline in the developed countries and is widely applied to both military and commercial development programs. Not so well known, however, are the efforts to establish this discipline in developing nations. Several countries in South East Asia are investing in high technology manufacturing, including original design capabilities for turbine‐powered aircraft. The engineering departments of these new ventures are staffed with bright young graduates of local or western universities. However, systems engineering is generally a new concept to engineers with traditional aerodynamics, structures and electrical training.This paper describes the introduction of systems engineering as a discipline at the national aerospace endeavor of Indonesia. The initial situation is described, followed by the steps taken to establish a systems engineering capability, resulting in a successful first flight of the prototype aircraft, the N250. The importance of management support and adaptation to local cultural values are stressed. Lessons learned have application not only to systems engineering within developing nations, but for the established technology leaders as well.
1.5.3 A Method for Measuring Cycle Time Using Engineering Orders
Authors: Clouse Aaron J. , Barton Troyce 
Published: November 2014

ABSTRACTThere are several methods which may be used to measure cycle time for programs. Some lack the ability to correlate the data to the development process tasks. One reason to measure cycle time is to use the data to perform cycle time estimates for future programs. The method discussed in this paper analyzes the data collected from a labor collection system. Every direct employee uses the labor collection system to enter the time they worked on specific tasks. This method correlates the hours worked to the development process tasks. This involves standardized cost accounting and Engineering (work) Order (EO) practices as well as the deployment of an Integrated Product Development System.
1.5.4 Systems Engineering Process Metrics: The easy way?
Authors: Stemm Douglas J. 
Published: November 2014

AbstractThis paper discusses various types of metrics for evaluation of the Systems Engineering Process in an enterprise. It discusses Continuous Measurement Improvement (cmi) and how these metrics fit. It presents in detail one metric that should be applied at the start of cmi and a unique way of gathering information across a diverse enterprise. Finally, the paper will discuss the purpose for which this information is being used. Readers should take note that the principles discussed in this material are applicable to any engineering discipline. These methods are of ever increasing importance in today's environments of mergers and acquisitions. Enterprises want a metric that is useful and applicable to a wide variety of business components and yet not painful to gather the information.
2.5.3 Two Approaches to CMMSM Integration
Authors: Sheard Sarah A. , Ibrahim Linda , Rose Susan , Makhlouf Wafa 
Published: November 2014

ABSTRACTThe number of process improvement models and standards is vast. [Sheard 1997], [Quagmire 1997]. Even restricting consideration to official Capability Maturity ModelsSM (CMMSM)1 leaves a large enough number of models that an organization attempting to mature its processes has a variety to choose from, each with a different focus. The decision of which model to select may be difficult, as there may be parts of two or more models that are needed to meet all of the organization's improvement objectives. In these cases, perhaps the best choice is not to choose, but to integrate. Two U.S. government organizations, the Federal Aviation Administration (FAA) and U.S. Army Simulation, Training and Instrumentation Command (STRICOM) have consolidated existing CMMs into integrated models that best fit each organization's needs. This paper describes the two approaches used to accomplish the CMM integration.
3.5.2 Predicting Technology Operational Availability Using Technical Maturity Assessment
Authors: Kenley C. Robert , Creque Terry R. 
Published: November 2014

ABSTRACTA technical maturity assessment method was performed by systems engineers in collaboration with an advisory panel composed of team members from different Department of Energy sites and from different engineering and science disciplines. Various stabilization technologies were assessed annually as to their relative maturity and availability for use in stabilizing nuclear materials. After three years of assessments, several of the technologies are now components of operational systems. A regression analysis of the historical assessments was performed, and it was concluded that the numerical technical maturity score produced by a team of experts can provide a powerful predictor of the time remaining until the operational application of technologies.
3.5.4 An Economical Approach to Conducting Assessments of Systems Engineering Capability
Authors: Widmann E. R. , Mindlin W. J. 
Published: November 2014

ABSTRACTThe INCOSE SECAM and EPIC SE‐CMM have been used to measure systems engineering process or capability maturity within industry and Government. Both models have been the subject of a “merger” effort that resulted in the release in August 1997 of EIA/IS 731–1 Systems Engineering Capability Model (SECM), draft Version 0.5; Version 1.0 is expected to be released in the first half of 1998. The “standard” methods of conducting assessments using the first two models (the “merged” model assessment method has not yet been released) is usually of four or five days duration, depending upon the model selected. This length of time presents an economic hardship to many business entities and perturbs the activities of the programs involved for approximately a week. This paper describes a structured, economical approach to conducting assessments in two days. Specific cost savings are presented based upon previously conducted “standard” assessments and more recently conducted “mini‐assessments”, termed “Progress Measures”, using this economical approach. The “mini‐assessment” method, termed a “Progress Measure Assessment Method”, can be used with any of the above three models of systems engineering capability, or concurrently with two or more of them should a business entity desire to assess their systems engineering capability in different ways.
5.5.2 The Application of a Systems Engineering Process to the Re‐Engineering of an Air Defense System
Authors: Laporte Claude Y. , Guay Alain , Tousignant Jacques 
Published: November 2014

ABSTRACTDuring the last five years, our organization has developed and implemented software and systems engineering processes. In this paper, we briefly describe the systems engineering process development, its application to the re‐engineering of two major components of an air defense missile system, and some lessons learned from the two projects.
5.5.5 Improvement of Systems Engineering on a Mature Program
Authors: van Gaasbeek James R. , Sunday David A. , Manuel Gregory C. 
Published: November 2014

ABSTRACTThis paper discusses the activities involved in improving systems engineering (SE) on a large, mature program. It discusses the reasons for improving SE for a fielded product and then provides a description and discussion of the program environment the SE environment and the various steps taken to accomplish the task.
1.6.1 Systematic Course Design at The Aerospace Institute
Authors: Mosher Todd 
Published: November 2014

ABSTRACTA new course design methodology has been created to aid instructors at The Aerospace Institute, the education and training division of The Aerospace Corporation. This methodology's heritage is an approach described in “The New Professor's Handbook” by Dr. Cliff Davidson and Dr. Susan Ambrose that compares planning a course with planning a research project.1 For The Aerospace Institute this analogy has been modified to an analogy between course design and systems engineering, which is a concept very familiar to its instructors. This paper walks through this methodology and offers suggestions for implementation that should be useful in a variety of educational environments. Examples are provided throughout to illustrate the concepts.
1.6.2 An Experience with a Multiformalism Specification of an Avionics System
Authors: Traore I. , Jeffroy A. , de Chazelles P. , Romdhani M. , Sahraoui A.E.K 
Published: November 2014

ABSTRACTThis paper introduces a novel approach1 in the development of systems. The approach is based on a selective use of formal/semi‐formal specification languages by using the multiparadigm/multiformalism approach. It allows to combine different specification languages in the same environment. Used methods are StateCharts, SAO, and SDL for a specific avionics system as CMWC340. We give also an extended approach based on the same framework using Statemate and VDM to derive a global formal specification for the systems. This work can be considered as an experience return with preliminary results and also in an infrastructure/exploratory study. An ongoing perspective is the use of a common format based on industrial standard as VHDL‐AMS.
7.1. Applying the Systems Engineering Process: Building Improvements to a Business Management System
Authors: Stemm Douglas J. , Ahearn Susan M. 
Published: November 2014

AbstractThis paper describes a practical application of the Systems Engineering (SE) process to the continuous improvement of a Business Management System (BMS) at Raytheon Systems Company, Naval and Maritime Systems (NAMS) division, which documents how an enterprise conducts its business via processes. It further explains how to improve the BMS by requirements management and an architectural structure which accommodates merging the process documentation from two or more companies. In today's business environment of merger and acquisitions, a solid process merger strategy is of increasing importance. A consolidated company wants to leverage the best practices from each company that has been merged. BMS improvements also rely on a “recipe” approach and object modeling.This paper will describe the ongoing results from a BMS improvement activity to verify, validate, and improve a BMS for an enterprise with multiple sites and a variety of customers and programs. The paper's first pass through the SE process focuses on aligning an enterprise's BMS to its drivers, so that it only documents and performs that which is necessary. The second pass through the SE process deals with mergers, where two or more companies with separate BMSs align into a cohesive enterprise.
7.4. DEVELOPING TECHNICAL STRATEGY WITH SYSTEMS ENGINEERING
Authors: Wray Richard B. 
Published: November 2014

ABSTRACTA successful technical strategy is critical for success in the high technology industries. But defining a successful technical strategy can be difficult, in part because there is little in the literature on developing and implementing successful technical strategies in Corporate America. The basis for much of the advanced thinking on effective strategies comes out of the military environment: what an effective strategy is and how it can be implemented. This paper briefly reviews some military thinking on strategy.The major thrust of this paper applies systems engineering to the business system development problem. It identifies key technical elements of the business strategy, technologies to be used, company practices for a successful business, and positive feedback from customers. In this context, the issue is to systems engineer a business solution and an effective technical strategy.A second thrust of this paper is to summarize the systems engineering process thus needed to perform this front end business system development. This paper describes the systems engineering process elements needed to implement technical strategy in the commercial environment.
1.1.3 Concept Exploration into an Australian Indigenous Space Launch Capability
Authors: Rogers Anthony J. , Tragesser Steven G. , Smith E. Price 
Published: November 2014

AbstractThis paper endeavours to explore the possibility of establishing an Australian indigenous space launch capability. The paper examines a trade space made up of a series of requirements and alterables derived from a mission statement and a set of objectives. This trade space is then optimised in an effort to maximise the benefits of such a capability, in order to determine whether the proposal is worth pursuing at the next level of system design.
1.1.4 Developing the International Space Station Integrated Verification Measurement Program
Authors: Haskins Bill R. 
Published: November 2014

AbstractThe International Space Station (ISS) Program Master Integration and Verification Plan (PMI&VP) requires that the systems engineering verification team establish and implement an integrated verification measurement program. This paper captures the knowledge and experience acquired through the International Space Station systems engineering efforts to develop, implement, and report a detailed set of integrated stage verification planning and closure metrics. The information and lessons learned, contained in this paper, may provide insight, direction, and a starting point for other large engineering organizations seeking to institute a measurement program.
4.1.1 Agent Systems Architectures for Complex and distributed Product Development Systems
Authors: Wenzel Stefan , Igenbergs Eduard 
Published: November 2014

AbstractIn complex system development projects the agent system describes the company's organization with its structures and resources carrying out all the tasks as agents. This includes all the individuals and organizational units (e.g., departments, teams, employees) as well as important resources like installations, machinery, equipment or tools, methods, software, specific know‐how (Negele, 1998; Negele & Wenzel, 2000). But when should we use which organizational structure or tool/method? Basically an adequate architecture and design of the agents/means to conduct a system development is highly interdependent from product and process architecture.This paper provides a methodology, which allows us to measure the degree of integration within a distributed product development environment and to specify the cost associated. Thus, cost/benefit ratios can be calculated for different scenarios. Upfront it describes a framework, how product development environments, and the process‐, product‐, and agent‐system can be structured, classified, and how they are interrelated. On the basis of the product and process architecture organizational‐ and tool‐structure decisions for complex product development systems can be made
4.1.2 The Concept of a Decision Architecture For the Systems Engineering Development Process
Authors: Buede Dennis , Powell Robert A. 
Published: November 2014

AbstractThe purpose of this paper is to introduce the concept of a decision architecture for a life‐cycle balanced systems engineering process that addresses not only the design of an operational system but also the qualification of that design. This paper motivates the need for such a decision architecture, namely to drive the operational architecture of the development system. Elements and uses of the decision architecture are discussed. Sample topics in a decision architecture are shown for the operational and development systems. Finally some historical case material is presented on this topic.
5.1.3 How to Organize System Engineering in a Company – A Case Report
Authors: Zonnenshain Avigdor 
Published: November 2014

AbstractSystem Engineering (SE) is an emerging area of expertise that comprises activities essential to project success.Defense industries around the world are searching for an effective method of incorporating SE into Project Management.The Ordnance Division of RAFAEL has taken a radical strategic step in strengthening its SE by creating a new department – The Systems Department.The Systems Department comprises all System Engineers dedicated to SE project activities in the division and is responsible for the development and implementation of modern SE methodologies.The Systems Department is dedicated to fulfill the following tasks within the organization:

Support concurrent engineering in projects
Incorporate support engineering (i.e. ILS, RAMS, Quality Engineering) in the project's life cycle.
Support planning and control of projects
Initiate ideas for new systems.
Promote strategic thinking and planning within the Ordnance Systems Division:
Launch knowledge management within the division.The Ordnance Systems Division Management is ready to meet the challenge ahead, and believes that the Systems Department will prove to be successful in the short and long range.Ordnance Division customers will benefit from the new department's “wise” approach on a multitude of issues such as:

Requirements Definition
Concept Development
Tests and Evaluation
Design Reviews.If successful, this Systems Department could well become the organizational model for another companies and other RAFAEL divisions.