bluuebunny/crossref_metadata_2025 huggingface dataset:
7.2.2 A Systems Engineering Tools Taxonomy
Authors: Oliver David W. , Steiner Rick
Published: November 2014

The goal of this paper is to provide a classification of tools that may be useful to systems engineers in understanding tool choices for the automation of their work. The material here draws upon input from the NCOSE tools committee members and published work.

The tools automate the systems engineering process. Each kind of tool performs particular functions and captures particular sets of information. In this paper the tools are classified into several categories that are helpful in making tool selections. The classification of tools by how they are used is considered in detail through several layers of decomposition.

The tool classes defined by classification by use can be mapped to the systems engineering process to show exactly how the tools are used, what functions they perform what information they capture, and how they interface with one another. That mapping is considered in a companion paper. In the sections that follow descriptions are given for:

A general classification of tools

A detailed classification of tools by use
PARAMETER‐BASED REPRESENTATION FOR MODELING COMPLEX SYSTEMS
Authors: Friedenthal Sanford A.
Published: November 2014

This paper describes a concept for a parameter‐based representation (PBR) to model complex systems. The representation combines features from both process and object‐oriented representations including IDEF0, data and control flows, entity relationship attribute (ERA) diagrams, and parameter flows.

The parameter‐based approach provides enhanced capability over existing representations because it represents the multiple attributes of a system, including the performance, physical, design, and process parameters, and explicitly defines the relationships between them. This approach enables the systems designer to perform critical analysis and better assess the impact of design decisions and changes on the overall system performance, while maintaining design traceability.

The systems engineering process provides the framework for applying PBR to construct and analyze the system model and fully describe the system. The application of a systematic approach using PBR to develop a system model will provide improved ability over current representations to capture critical systems information, analyze complex system interrelationships, and communicate the information among the development team.
1.3.3 Training System Risk Management
Authors: Boggs William B.
Published: November 2014

This paper examines the role of risk management within the training system segment of major weapon system development organizations. Too often the risks associated with the training system are overlooked because the same criterion is used to evaluate all program risks. This approach prohibits technical and programmatic problems associated with the training system from being adequately identified and mitigated early in the weapon system life cycle; thus, adding cost and eliminating technical solutions. The intent of this paper is to increase awareness of the Risk Manager, Systems Engineering Manager, Training System Manager and Program Manager as to the typical approach of training system risk management. Risk management solutions that address training system risk management problems are provided within this paper.
2.3.2 PROGRAM RISK THE BALANCING OF PERFORMANCE, SCHEDULE, AND COST RISKS
Authors: May Charles , Olson Robert
Published: November 2014

This paper addresses the need for a risk management program to provide the program level decision makers a quantitative assessment of the level of risk associated with their program. Included are the characteristics of a suitable indicator of program risk, and one approach for obtaining an assessment of program risk and making adjustments to the level of program risk.
2.3.4 FAILURE MODE ANALYSIS IN SYSTEMS ENGINEERING
Authors: Armstrong James R.
Published: November 2014

The concept of failure mode analysis can be more productively applied than as a critique of the completed detail design. In fact, it can be effectively applied in the initial systems engineering analysis of the desired system requirements and functionality. This takes a little thought and may not be well received by failure analysis purists due to lack of hard failure data as is available for hardware components. However, it can be an effective tool in the systems engineer's bag of tricks.
3.3.3 TEAMING TECHNIQUES DERIVED FROM HUMAN SYSTEMS THEORY: NEUTRALITY, HYPOTHESIZING AND CIRCULARITY
Authors: Alessi R. Samuel , Mayhew Michael E.
Published: November 2014

Systems engineers who work effectively with teams of engineers and stakeholders can improve the efficiency of the overall engineering process. This paper discusses techniques that are used by human systems analysts to understand, guide and improve human interaction. Three cooperating principles: neutrality, hypothesizing and circularity, enacted through questioning strategies, are used to understand, validate and intervene in any human interaction situation. An example is given which shows how questioning with the aid of neutrality, hypothesizing and circularity can lessen a confrontational situation and improve human dialogue. A drill is also provided to help systems engineers practice and learn these techniques. If team members can learn these techniques, engineering communications problems will be lessened.
4.1.4 System Engineering in an Integrated Product Team Organization
Authors: Thomas L. Dale
Published: November 2014

This paper presents a discussion of the functions of a system engineering organization in an integrated product team (IPT) setting. IPTs are being adapted widely as a more efficient means for accomplishing large product developments. Recent examples include the US Air Force F‐22 fighter program. Additionally, when management difficulties plagued NASA's Space Station Freedom program, NASA responded by implementing an IPT management structure for the program.

A brief review of classical system engineering functions as described by government and academic texts and a resultant synopsis are followed by a brief review of the IPT organizational schema. Subsequent discussion presents a paradigm for system engineering within an IPT setting, and describes the similarity in function of the analysis and integration teams (AITs) within an IPT versus classical systems engineering functions. A conclusion is supported that by controlling the scope of the system engineering task, the function of AITs is comparable to that of classical system engineering organizations. Finally, system engineering within NASA's International Space Station Alpha (ISSA) program is presented as example of a system engineering application within an IPT setting.
4.3.4 COMMON ARCHITECTURE THROUGH REQUIREMENTS MANAGEMENT
Authors: Lukaszewski Matthew S. , Manduley Flavio M.
Published: November 2014

An increasingly important corporate goal has been the development of a process for product architecture which will allow businesses to provide compatible and complimentary products to customers, while increasing the efficiency of the product development cycle and reducing operational and component costs. This paper addresses a process and an automated mechanism for achievement of these goals.
2.2.4 On the Diversity of Process Metrics Users: Identification of Metrics Types and Other Attributes
Authors: Martin James N.
Published: November 2014

This paper explores the relationship between process metrics users and their diverse needs. Twenty metrics user classes and nine basic metrics types are identified. Other attributes of metrics are defined. These metrics types are correlated to the different user classes with regard to their degree of usefulness to each user class. Other attributes such as data tempo, data level of detail and data type are identified for each user class. Three categories of correlation factors are identified that can be used by the metrics analyst and users: normalization factors, quality correlation factors, and cost estimating relationship factors. The degree of usefulness of each correlation factor for the user classes is also identified.
6.2.2 Re‐Engineering of the Metrics Collection Process
Authors: Martin James N. , Miller William D.
Published: November 2014

This paper describes the re‐engineered process for metrics collection in the Advanced Technology Systems sector of AT&T. The previous process was cumbersome for both the metrics data collector and the metrics analyst. Much of the data collected was unusable. The collectors of metrics were frustrated since they spent many hours hunting for the data and it was often difficult to obtain. Therefore, much of the data the metrics analyst needed to do his job was not available. Hence, our major criteria for re‐engineering the process was to simplify the metrics data forms, to minimize the amount of work to be done by the data collector.

The major advance was to collect existing cost and schedule data directly from the financial management system (FMS) instead of asking the metrics data collector to provide this. To do this, we developed a means to collect data using an “extraction map” to locate the existing cost/schedule data from the FMS. The new metrics data forms are described along with the streamlined collection and analysis process.
2.4.3 A COHERENT ENGINEERING PROCESS FOR COTS ACQUISITION AND INTEGRATION
Authors: Nolte Jerry , TASC David Newbern
Published: November 2014

One of the major problems facing the federal agencies today is how to rapidly acquire COTS‐based systems within the contractual framework of the Defense Federal Acquisition Regulations (DFAR). TASC has developed a preliminary description of a process to solve this problem. We have identified modifications to the standard acquisition process which are needed to meet the contracting and legal requirements embodied in the DFAR while effectively attaining the desired technical benefits from building a system around commercially available software packages. The process emphasizes a small team approach to coordinate technical requirements, program schedule and budget constraints, and the acquisition process.
2.4.4 A Picture's Worth: Use of Models to Facilitate Knowledge Transfer During the System Life Cycle
Authors: Schuster Cecilia H.
Published: November 2014

Increasingly practitioners of Systems Engineering are recognizing the challenges of creating consensus understanding on a program. For years, members of NCOSE have been clamoring for a more robust and unambiguous way of expressing their requirements and subsequent designs. Model‐based systems engineering is a reality whose time has come. This paper points out ways in which these techniques are superior in the realm of knowledge transfer. In light of the symposium theme Systems Engineering in the Global Market Place, these concepts suggest that models are the way to cross not only the boundaries of life‐cycle phases, but also the linguistic boundaries of the global community.
3.5.3 OBJECT‐ORIENTED SYSTEMS ENGINEERING
Authors: Bharathan K. , Poe Georgia L. , Bahill A. Terry
Published: November 2014

Object‐Oriented methodology has developed to the point where it has the potential for being a powerful tool in the arsenal of the systems engineer. This paper suggests that such assimilation will require modifications in the method to make it generalizable outside the software design environment. This paper uses the lessons learned from (i) a text‐book example and (ii) a systems engineering project where the object‐oriented method is being applied to explore the scope and possibility of such assimilation.
6.4.2 FAILURE MANAGEMENT AND THE DESIGN OF COMPLEX SYSTEMS
Authors: Fisher Jack
Published: November 2014

When we undertake to design a complex system, consideration must be given to how the system and its components might fail and how these potential failures may be circumvented or avoided. Current aerospace design practice for the consideration of failure is described and its weaknesses recognized. It is proposed that failure design considerations become a featured element in the systems engineering process and that a centralized approach under the banner of risk management would provide a number of significant advantages.
7.4.1 A NEW LOOK AT THE SYSTEM ENGINEERING PROCESS: A DETAILED ALGORITHM
Authors: Adamsen Paul B.
Published: November 2014

This paper describes a system engineering process or algorithm upon which a database for requirements, design, and decision traceability can be structured. Once in place, this database provides a powerful tool for performing change impact analyses, cycle‐time reduction analyses, cost reduction analyses, anomaly analyses, risk assessment, etc. It also assists in the development of meaningful metrics that give real technical, cost, and schedule performance visibility to program management. This in turn provides a tool for controlling the system development in terms of identifying risk areas and determining where resources should be focused to mitigate them. In short, such a database describing the system provides understanding of the system. A system understood is cost‐manageable. A system understood is schedule‐manageable. A system understood is technical‐performance‐manageable. Risk understood is manageable risk.
Systems Process for Public Policy Application
Authors: Cutler William H.
Published: November 2014

The Systems Process, emphasizing the Functional View, is an effective organizing principle for creation of public policy actions. It has two features that counter the adversarial mindset typical of politics:

All stakeholders are included as members of a collaborative team.

It is a structured, disciplined process that addresses the inherent complexity of the problem.

Complex systems are encountered everywhere in public policy. The Systems Process with its fundamentally collaborative nature is superior, perhaps indispensable, for resolving controversy and organizing an effective response. A 12‐step process framework is described, which is applied throughout the life cycle of an issue as it moves through Initiating, Planning, and Operational stages. Experience showing the benefit of this process is cited.
Systems Engineering and the Architectural Design of Buildings
Authors: Langston Dale Glyn
Published: November 2014

This paper presents a case study of the architectural design of a custom building. In this case study, a church is investing in the conceptual design phase of a new facility. This paper summarizes the activities performed to develop the conceptual drawing of the new building and the deficiencies associated with that approach. A systems engineering approach is proposed in this paper that will lead to comparable drawings at a reduced costs.
What's Wrong With Requirements Management Tools?
Authors: James Laurence
Published: November 2014

This paper examines many of the issues which may make most requirements management tools less than useful within an enterprise.
Object levels and categories in O4S™ (Objects For Systems) for engineering of dependable systems
Authors: Ögren Ingmar
Published: November 2014

The general O4S™ object concept is introduced with objects having offered/required interfaces and internal behavior.

To support efficient system engineering objects are identified on Project, Configuration Item and Ordinary level.

Object categories are introduced to model how objects of categories Operator, Software and Hardware cooperate to complete Missions.

As a formal notation, the design language Odel, based on the programming language Ada95 is introduced. It is also shown how Odel gives a basis to use the traditional techniques of FTA and FMEA to analyze system dependability.
Driving Test and Verification From SLATE
Authors: Sampson Mark E.
Published: November 2014

Test and verification always seem to end up on the critical path as we come down to the finish line on our product launch efforts. These, usually separate, test organizations often have more people working test then worked product design. This paper suggests an “integrated” approach to pulling test into the systems engineering requirements management environment and shows how SLATE can be used to actually drive system test sets and monitor and report on results–after all, test exists to verify and document that the product meets the requirements.
Challenges in Designing Open Systems
Authors: Dargan P. A. , Hermes Michael A.
Published: November 2014

Open systems offer a building block approach to development that follows sound software engineering principles: well‐defined interfaces, information hiding, weak coupling, and layers of abstraction. Open system standards define the basic system building blocks, providing a foundation for reuse, interoperability, and evolution.

But there are new challenges to address with this approach: where do standards belong in an architecture? Which standards are the right ones to use? Are there commercial products that implement the standards? This paper provides some insights based on experiences in developing a standards‐based architecture for migrating a large, complex legacy system to an open system.
How to Properly Specify and Control Essential Project Data
Authors: Chevalier Jean , Marshall Richard M.
Published: November 2014

The relationships between need, function, requirements, and verification define a systems engineering process. The documents containing this information define the product which the project will produce. Drawing up requirements compatible with user needs, the project's mission and the available technologies is a major task for the project team and subcontractors. Similarly, exercising control over changes to the documentation and appraising their consequences is of constant concern to project managers, and is another keystone of the systems engineering approach. This paper presents the result of using the DOORS tool to apply rigorous systems engineering discipline to a trial project at the French Space Agency.
Prophet™ ‐ The Engine for Integrated Risk Management
Authors: Huff Deborah S.
Published: November 2014

Hughes has developed a powerful risk management toolset, named Prophet™, which has proven highly successful in managing several programs, and is now being deployed throughout Hughes. This paper describes Prophet™ features, the processes it supports, and the concepts behind them. Features include user‐friendly input screens, roll‐up risk factors, automated risk reduction charts, expected cost impact analysis, assessment history and rationale tracking, process productivity aides, tailorability features to suit a broad assortment of programs, integration with master planning and scheduling, tracking of technical performance measures, risk metrics for technical trade studies, and strategic technology maturation planning.
Implementing the Systems Engineering Process for Tool Selection
Authors: Christopher Janet
Published: November 2014

The Lockheed Martin Systems Engineering Process is utilized by the Engineering Process Improvement (EPI) Program for selection of CAE tools for automating engineering tasks. Expanding the focus of Systems Engineering to include engineering process and practices provides a framework for defining a systematic approach to selecting and implementing processes and practices, i.e., tool selection and usage. The Systems Engineering approach for selecting EPI tools at Lockheed Martin Corporation is described, including the tasks associated with each step. The steps described follow the elemental tasks of planning, analysis, candidate selection, validation, evaluating alternatives and managing risk, and selecting the solution.
BACK TO BASICS AGAIN – A SCIENTIFIC DEFINITION OF SYSTEMS ENGINEERING
Authors: Mar Brian W.
Published: November 2014

The major confusion with the understanding of systems engineering and improving its scientific basis is the failure to define the system of interest. Given a clear definition of the system of interest, engineered functions of that system can be identified, and applications of systems engineering concepts to those activities can be examined.

A systems framework is suggested to classify basic engineering and systems engineering activities. This framework allows a better definition and search for scientific foundations of systems engineering.
Business Strategy Implementation with Systems Engineering
Authors: Oliver David W.
Published: November 2014

Success in the marketplace requires a business strategy implemented with engineered product or service. The product or service must provide users, operators and owners with what they want and value with more convenience and better price than offered by competitors. Management makes the business strategy and resource allocation decisions. Systems engineering defines the product and services in accord with these decisions.

It is critical that needed information pass across the management/systems engineering interface without ambiguity. This often requires a translation of information into the form understood by and useful to the recipients.

This paper analyzes the basic abstractions used by organizations on both sides of the interface. It establishes the basic abstractions that are common to both business strategy development and systems engineering. This set of abstractions define the information which must be communicated between the business development experts and the systems experts who may be organized together in a single team or assigned to separate organizations. The techniques for engineering systems with models, usually applied to products and services, are applied here to the interface between business strategy and systems engineering
Integrated Modeling for Launch System Architecture Optimization
Authors: Hickman Robert A.
Published: November 2014

In a world of increasing competition and declining government space budgets, the emphasis in new launch system design has shifted from performance optimization to cost reduction. Architects making complex launch system design decisions are handicapped by the unavailability of analytical tools that provide an integrated life cycle cost analysis that quantifies the impact of design decisions. Vehicle performance, operational efficiency, reliability and ground system design all have a major effect on cost. This paper focuses on a research effort to integrate 6 separate models developed at The Aerospace Corporation to provide an integrated launch system assessment capability. The impact on the system architecting process will be discussed as well as the ability to identify and prioritize necessary design enhancements or new technologies.
A Systems Vision for INCOSE
Authors: Evans Richard , Park Sooyong
Published: November 2014

INCOSE has become great by dedicated and inspired leadership. It has also become great because it holds the promise to be a means to address a great worldwide challenge:

systems. The call for INCOSE in addressing that challenge and truly fulfilling that promise is to lift and enlarge our vision to meet our responsibility for systems, not just something called systems engineering, or for systems engineers. Two options toward an elevated systems vision are presented: (1), move directly to a “systems” level and be the International Council on Systems (INCOS), or (2), take a two‐step approach, transitioning initially to an intermediate‐level vision as the International Council on the Engineering of Systems (INCOES).

The intent of this paper is not at all to make a final case for an immediate change in INCOSE, rather it is to initiate further consideration of the issues and ideas offered, with a goal of helping, by citing these perspectives, to assure a great INCOSE [INCOS] now and in the future.
Development and Integration of Engineering Processes at Oerlikon Aerospace
Authors: Laporte Claude Y. , Papiccio Nicola R.
Published: November 2014

In order to reduce cycle time, increase customer satisfaction and lower costs, Oerlikon Aerospace has initiated, in 1992, a project to define and implement software and systems engineering processes. The initiative started by performing a formal assessment of current software engineering practices. An action plan was developed and multi‐functional working groups were tasked to define and facilitate the implementation of software processes. A second initiative was started, in 1995, with the objective of defining and implementing a systems engineering process, and integrating to the systems engineering process the software engineering process already in use.
Systems Engineering and Management of Multinational Cooperative Development Programs
Authors: Roe Charles L.
Published: November 2014

International research and development programs present unique challenges in relation to business mobilization and in how organizations must deal with outside technology, financing, program planning, joint program management, and engineering issues. The systems engineer must address technical issues set against multinational parochial interests, while the program manager holds the industrial team together and works with a sponsor that is often a consortium of nations.
MECHANISMS FOR INTERTEAM INTEGRATION: FINDINGS FROM FIVE CASE STUDIES
Authors: Browning Tyson R.
Published: November 2014

Many product development programs consist of multiple integrated product teams (IPTs) and functional groups. Interteam information dependencies greatly affect program success. Program integration has thus become an issue of increasing interest. This paper summarizes findings from five case studies of integrative mechanisms (IMs) in complex system product development projects at Chrysler, General Electric Aircraft Engines, McDonnell Douglas, Sundstrand, and Texas Instruments. Two types of IMs are investigated in this paper: (1) Systems engineering and interface optimization and (2) Improved information and communication technologies. As the appropriateness of a given IM varies as a function of many parameters—such as program stage, size, complexity, risk, etc.—the goal of this research was not to formulate a universal template for IM application. Rather, it is hoped that the lessons learned by these five programs will help others determine the appropriateness of particular IMs in their situations. Also, the continued development of an IM categorization scheme will hopefully prove useful to those developing an integration “tool kit.”
A Simplified and Evolutionary Hypermediacy Model For Project Management
Authors: Worden Gregory
Published: November 2014

The electronic revolution held the promise of fast and efficient communications, seamlessly integrating different platforms, regardless of a user's location, in an easy to use and inexpensive package. However, for most organizations the electronic workplace has been expensive, inflexible, difficult to learn, and incapable of working with other systems. Yet the rapid expansion of the Internet and its hypermedia interface has given project management a new tool. Hypermedia, multimedia, and associated technologies, collectively termed hypermediacy, provide an efficient, simple, flexible, and powerful method for maintaining and distributing project information. This paper presents a project information system, built on the Internet paradigm of low cost, distributed networks, using existing desktop hardware and software. Starting with a simple implementation, project management can quickly and inexpensively realize information processing requirements without expensive procurements or learning overhead. The base model is then expanded incrementally over time as project needs evolve.
An Improved Set of Products for Measuring Systems Engineering
Authors: Widmann E. R.
Published: November 2014

This paper provides information on the INCOSE Measurement Technical Committee and its three working groups. The charter and goals are presented along with objectives for development and support of measurement products. Significant milestone events for both products and product support services are provided – the only products to receive approval, or interim approval, of the INCOSE Technical Board were developed within the Measurement Technical Committee. A brief description is provided of each of the measurement products developed to date. A synopsis of the past year's activities is provided along with planned future activities. An integrated approach to development of measurement products is being pursued to permit more effective measurement and improvement of systems engineering activities. The products developed by the Measurement Technical Committee are available to become an integral part of the strategic planning activities of both industry and government.
A Preliminary Description of the EIA Systems Engineering Capability Model
Authors: Widmann E. R.
Published: November 2014

Two systems engineering capability models have gained a great deal of attention: the INCOSE SECAM and the EPIC SE‐CMM. This paper provides a preliminary description of the results to date of merging the two models and application methods into a single model and assessment method under the auspices of the Electronic Industries Association (EIA). The EIA Working Group, which is responsible for accomplishing the merger, has representation from the EIA, INCOSE, and EPIC. The INCOSE representation is provided by the INCOSE Measurement Technical Committee. As such, the “merged” products may be regarded as part of the set of measurement products that the INCOSE Measurement Technical Committee is developing, both internally within INCOSE and jointly with external organizations, to measure and improve systems engineering activities. The paper provides a synopsis of the current versions of both models in order to assist in understanding the merging effort and provide a background to the resulting merged model, designated the EIA Systems Engineering Capability Model (SECM).
INCOSE Tools Database Working Group Report
Authors: Case Randy , Findley Beth , McMullen Bill , Sampson Mark
Published: November 2014

The Tools Database Working Group (TDWG) is delivering a third release of the Systems Engineering Tools Database at the 1997 INCOSE Symposium. An update of the Requirements Management Tools, an update of the Systems Architecting Tools and a list (by both vendor and tool name) of general tools (including the requirement and architecting tools) make up this third installment. The information contained within the database comes directly and unedited from the tool suppliers. It is our wish that this information will save INCOSE members (those looking for information and those providing it) time as well as provide a common framework of reference for these important tools for Systems Engineers.
1.1.3 Systems Engineering in the Small
Authors: Sloan Crystal D. , McCumber William H.
Published: November 2014

This paper illustrates how systems engineering is conducted at the lower end of the business, where the customer usually will not pay for the design of a system unless the costs are integrated into the price of the delivered product. Many low‐end customers do not have a clear concept of what they want a practitioner to provide. This paper presents the practitioner's view of engineering in the small, and demonstrates a strategy for finding out what the customer really wants.
5.1.3 Converting Your Systems Engineering Organization To ISO 9001 Compliance
Authors: Kasser Joseph E. , Williams Victoria R.
Published: November 2014

Quality control is evolving from only being present during final inspection, into becoming an integral part of the systems engineering process. This evolution is being helped by the International Organization of Standards (ISO) 9000 series of standards that provides a checklist for documenting processes and assessing their performance. The standards do not apply to systems engineering at this time. They are however taking the place of similar Department of Defense (DoD) standards, so there is an excellent probability that they or an equivalent standard will apply to systems engineering in the future. This paper describes one proposed way to transform an organization toward compliance with the ISO 9001 Standard, and make an organization's systems engineering process more cost effective.
1.2.1 Self‐Directed Teams for Systems Engineering
Authors: Brezinski Lawrence J.
Published: November 2014

A systems engineering functional group within a matrix organization provides technical skills to system development projects. Effective systems engineering requires a balanced emphasis on people, technology, and process activities. This balance can be achieved through the use of self‐directed teams in place of the traditional hierarchical organization. Using defined team tasks, clear interfaces, and a metrics program, self‐directed systems engineering teams were piloted. Results were measured in project performance, team performance, and involvement by systems engineers in developing and improving the technology skills and processes necessary for future company growth.
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

Within 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

Current 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

Product 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

This 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

In 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

This 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

Transitioning 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

Systems 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

There 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

This 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

The 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

A 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

The 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

During 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

This 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

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