bluuebunny/crossref_metadata_2025 huggingface dataset:
Sharing Corporate Experience Through Electronic Repositories
Authors: Tavan Steven W. , Clapp Judith A. , Garvey Paul R. , Sateriale Alan
Published: November 2014

With the increase in scope and complexity of major system developments, project managers and systems engineers need to access timely information to make cost‐effective decisions. To share best practices and lessons‐learned, many companies have decided to capture their corporate memory and disseminate it through electronic repositories. This paper describes four repositories that are helping achieve these goals at The MITRE Corporation.
Trade‐off Analysis in Model Based Systems Engineering
Authors: Oliver David W.
Published: November 2014

This paper considers model based systems engineering which produces executable requirements and specifications. It describes the trade‐off step of the systems engineering technical process. It treats the inputs to the trade‐off step. It defines a behavior for systems engineers to follow in performing trade‐off analysis. That behavior is described as an executable meta‐process rather than as a methodology to make it independent of the plethora of methodologies.

A meta‐process describes the steps to be taken in the process, the ordering of the steps and the inputs and outputs to each step. This is a behavioral picture. It also describes the information handled at each step and the relationships among the pieces of information. This is a static structural picture sometimes called an object model or an information model. The meta‐process defines the possible views of the information that will be handled.

A methodology, in contrast, selects particular orderings of the engineering steps and particular views of information in particular notations for use by an engineering team.
Successful Vendor Collaboration Deployinga Requirements Management Tool
Authors: Rader Jock
Published: November 2014

The paper describes a successful partnership between Hughes Aircraft Company and the tool vendor, QSS, to transition a requirements management tool into operational use within the company. We provide an overview of the Hughes objective to migrate to common processes and tools across a range of engineering disciplines. A discussion of the difficulties in achieving wide spread use of new processes and tools sets the stage for a description of the Hughes approach for adopting a requirements management process supported by the vendor's tool, DOORS. We validate our approach with examples of Hughes accomplishments to date. Based on our experience, we emphasize the importance of a positive relationship with tool vendors. Transition achievements allow us to provide illustrations of customer‐vendor cooperation to achieve mutually desirable goals.
An Analysis of the Model Based Systems Engineering Process
Authors: Oliver David W.
Published: November 2014

Much of systems engineering has been performed by writing requirements and specifications primarily in text. An alternative approach preserves the proven best practices of systems engineering, but adds rigorous computer executable models to capture and record the information which describes the system. The requirements and specifications are executable and transformable. Text descriptions are joined to the models so that the proven best practices are not replaced; they are augmented.

This paper analyzes the systems engineering process using executable models of behavior and executable models of structure. The structure models are compatible with the traditions of mechanical engineering, electrical engineering and modern object‐oriented software.

A major goal of this work is to provide a convenient separation of the concerns of the systems engineer and to use abstraction to make the sub‐processes as simple as possible.
COMMON MODELS FOR CONFIGURATION MANAGEMENT AND AUTHORIZATION MANAGEMENT IN SYSTEMS ENGINEERING ENVIRONMENTS
Authors: Kalathil Biju , Welsh John , Tuck Mary Catherine , Bailey Mark , Zielhke Auti
Published: November 2014

In an integrated product development environment that includes several vendor tools, diverse and incompatible configuration management mechanisms and authorization management mechanisms across tools can lead to inefficiencies in the design process. We describe in this document a common model of configuration management and authorization that may be adopted for an integrated product development environment. We specified a common minimal set of configuration management mechanisms and authoriza‐tion management mechanisms that must be provided by the tools to support the proposed configuration and authorization models. We implemented a pilot program of the configuration management and authorization management models using Intergraph Corporation's Document Manager 2.0 (DM2) software system. This pilot implementation proves the plausability and usability of the model.
ALFS A REQUIREMENTS MANAGEMENT SUCCESS USING DOCUMENT DIRECTOR
Authors: Webb Buddy F
Published: November 2014

The Airborne Low Frequency Sonar System (ALFS), is the next generation of dipping sonar system being developed for the U.S. Navy Helicopters. ALFS is being built by the Naval And Maritime System Engineering Center, which is part of the Hughes Aircraft Company located in Fullerton, CA. This project is in the Engineering Developmental Model (EDM) Phase and will be conducting its Operational Developmental Testing in 1996. The ALFS project is a Military Standard 2167A program requiring requirements tracking throughout the programs life cycle. This paper will focus on how, the Requirements Management task was accomplished and the lessons learned.
ARTICULATED CONFIGURATION MANAGEMENT
Authors: Dyer Gary M.
Published: November 2014

Articulated Configuration Management is a system that provides a backplane for status accounting, source code control, embedded processes, and project management. It does this by automating and linking the processes that previously were manual evolutions.

The implementation, and indeed the definition, of Configuration Management varies widely among both Department of Defense and civilian activities. Some possible scenarios are presented in the hope that new technology may provide a better solution and definition for all concerned.

This paper discusses the evolution of Configuration Management systems of the past into new technology that fully automates and articulates the Software Engineering Environment. It is presented and demonstrated in partnership with SQL Software Inc. of Vienna, Virginia

In its purest form, Configuration Management has always been viewed as the process of tracking change. The change vehicle itself goes by many names within the industry. It may be called a bug report, trouble report, change proposal or a multitude of other names. For the purpose of this paper, I will refer to the change vehicle as a change document.

Historically, Configuration Management and its associated change documents have been paper forms or manually updated forms within a database. This traditional Configuration Management very rarely had a meaningful connection to the source code modification it was supposed to track. The advent of state of the art Configuration Management systems now provides us with the capability to join or articulate the change document with the modified code and its outputs.

Configuration Management systems are usually predicated on the development, baseline, and release philosophy of an organization. This philosophy generally is implemented in one or more of the following three scenarios.
SPACE MISSION OPERATIONS CONCEPT
Authors: Squibb Gael F.
Published: November 2014

Developing a Mission Operations Concept for a space mission is a system engineering process. It involves multiple disciplines working together to describe the operational attributes of the flight and ground elements of the mission. This is done in the terms of the operators and the users (recipients of the data from the mission). A space mission operations concept emphasizes the way the mission will be operated and used (operational characteristic). Again, this is done in terms that are understood by the operators of the system and the users (the recipients of the data from the system). The Operational Attributes of a Mission are described by considering nine mission characteristics. These characteristics may be traded for cost and performance attributes of the mission. Developing a Mission Operations Concept is the process through which changes to mission requirements and/or design that will lower the Mission Life Cycle Cost can be identified. The inputs to the Mission Operations Concept include flight, ground and management functions.

Mission Operations Concepts are typically generated for nearly all space missions. It is a requirement in many project plans and RFPs that are generated. However, there is not a definition of what is included in a mission operations concept; of what should be considered when generating this operations concept; what the process is or what the products are. This paper will discuss the process of developing a space mission operations concept; the benefits of starting this system engineering task early; the necessary inputs to the process; and the products which are generated. This paper is based on a chapter in a text book that will be published in March 1996 ‐ prior to the NCSC Conference. In addition this process has just started going through an international review which will result in an ISO Standard for a Space Mission Operations Concept checklist. This checklist will describe the inputs, and outputs required to conform to the ISO standard for a space mission operations concept. The paper will include that latest draft of the international standard checklist, and explain the system engineering processes and benefits of generating an operations concept early in the life‐cycle of the project, during the study phase, and then maintaining the operations concept throughout the life‐cycle of the project.
GENERATING TEST CASES FROM FORMAL SPECIFICATIONS
Authors: Toth Kalman C. , Donat Michael R. , Joyce Jeffrey J.
Published: November 2014

This paper describes the possible process elements and benefits of applying “Formal Methods” to the specification and testing of software requirements. It is argued that the overall effort required to generate test cases can be significantly reduced by applying these methods. Ambiguities and inconsistencies are identified and removed from the specifications through the use of formal methods. This paper provides a sketch of a theoretic foundational for generating test cases from formalized software requirements specifications thereby reducing test development effort and providing developers and testers with a consistent interpretation of requirements. Preliminary work also supports the thesis that test case generation can be automated.
A METHODOLOGY FOR CONSOLIDATING SYSTEMS USING OPEN ARCHITECTURES
Authors: Friedman Gerald M.
Published: November 2014

The migration of multiple legacy systems to a single system having an open architecture is increasingly required as the Government modernizes existing capabilities. This paper presents a methodology, based upon open system standards and commercial off the shelf (COTS) products, for performing such migrations. The methodology addresses requirements, legacy system engineering analyses, architecture synthesis, component selection, migration plan development, cost, schedule, and migration plan implementation. The approach is presented in the context of the Theater Battle Management Core System project.
WHAT IS SYSTEMS ENGINEERING? A CONSENSUS OF SENIOR SYSTEMS ENGINEERS1
Authors: Bahill A. Terry , Dean Frank F.
Published: November 2014

Systems Engineering is an interdisciplinary process that ensures that the customer's needs are satisfied throughout a system's entire life cycle. This process includes

understanding customer needs,

stating the problem,

discovering system requirements,

defining performance & cost figures of merit,

validating requirements,

defining technical performance measures,

prescribing tests,

exploring alternative concepts,

sensitivity analyses,

functional decomposition,

system modeling,

system design,

designing and managing interfaces,

conducting design reviews,

system integration,

total system test,

configuration management,

risk management,

reliability analysis,

total quality management,

project management,

and documentation.
OBJECT MODELING AND CONCURRENT REQUIREMENTS ANALYSIS AT THE FRONT END OF SYSTEM DESIGN
Authors: Hopkins Frank W.
Published: November 2014

This paper describes a process that provides needed clarity at the front end of system definition and additionally encourages:

Modularity with its benefits for modification and reuse, and

Requirements compliance and traceability.

The process incorporates structured requirements parsing concurrently with top level system architecture definition.

The process is implemented easily with a toolset including: a requirements editing and management capability, an object modeling capability, a behavior modeling capability, and a repository for the system model data elements. OMTool by (the former) General Electric and RDD‐100 by Ascent Logic are the tools I have principally used for the process. Other toolset combinations may accomplish the same purpose. Many of these were displayed and demonstrated at NCOSE '95.
Strategy, Tactics, and Contingencies ‐ A Brief Tutorial in Planning to Achieve One's Objectives
Authors: Minds Kevin S.
Published: November 2014

Event based planning, empowerment, and risk management methods can be used to support strategic, tactical, and contingency planning. Strategic planning employs event based planning to postulate critical events and choose associated transition criteria. The intent is to choose a set of criteria for each event such that, if the criteria are satisfied, each event will occur as expected. Empowerment supports tactical planning by authorizing others to satisfy strategically chosen transition criteria. This is done by an empowering authority who assigns both transition criteria and decision making boundaries to an individual or group. Contingency plans are determined via risk management methods that identify risk items associated with failing to satisfy transition criteria and creating plans to avert those risks. In this context, all three methods, event based planning, empowerment, and risk management are driven by strategically chosen events and their associated transition criteria.
AN INTEGRATED PRODUCT DEVELOPMENT PROCESS CASE STUDY
Authors: Clouse Aaron J. , Shaw Richard
Published: November 2014

The Defense Systems and Electronics Group of Texas Instruments has developed and is using the Integrated Product Development Process (IPDP™). This paper describes how the process was developed, how it is deployed and the resulting success of the programs it has been used on. This method for creating an integrated product development process may be useful for your organization.
THE INTEGRATED PRODUCT DEVELOPMENT CAPABILITY MATURITY MODEL (CMM) SM
Authors: McIntyre Mac H.
Published: November 2014

Integrated Product Development (IPD) is a systematic approach to product (or service) development that achieves a timely collaboration of necessary disciplines throughout the product lifecycle to better satisfy customer needs. This paper provides the architecture and content description for a Capability Maturity Model for IPD. The formal model is based on industry (service and manufacturing), government, and academic input for IPD and the roles of teams within it. The intent of the session will be to update the current model state and to collect feedback on practitioner‐targeted, short, informational presentations and what else practitioners who help develop and implement processes need/want to know to want to try out this IPD CMM SM.
AN AUTOMATED ANTHROPOMETRIC TOOL FOR HUMAN FACTORS ENGINEERING
Authors: Saffer Valeria , Stanton Brian C.
Published: November 2014

For some time there have been software prototyping tools available to the Human Factors engineer to develop the human‐computer interface (HCI) of a system. Recently, software programs that aid in the prototyping of the hardware have been developed. These programs run on graphical workstations and enable the human factors engineer to build three dimensional models and analyze them, on a number of anthropometric variables, using human form models. This paper describes how such a program is being used to model and analyze the FAA's Display System Replacement (DSR) Air Traffic Control workstations.
A System Approach to the Client Server Distributed Architecture
Authors: Tronstad Yngvar , Earley Robert
Published: November 2014

This paper describes the need for a system engineering approach as a means to migrate the current rigid legacy system to a flexible distributed system architecture that can take advantage of the emergent client server technology. This approach focuses on a re‐alignment of the business processes as opposed to rehosting applications to a new technology. In doing so the enterprise becomes more aligned with the business objectives and the associated business objects. This modeling approach allows businesses to respond to dynamic changes in an increasingly more competitive environment.
ON THE NATURE OF INTEGRATION: AN ESSENTIAL TASK IN THE ENGINEERING OF SYSTEMS
Authors: Martin James N.
Published: November 2014

It has been said that systems engineering is concerned with the integration of system elements. This is certainly true, but there are some critical things left unsaid. What system and what elements are to be integrated?

It turns out that there are several systems of concern in any application of the systems engineering process. First, there is the system that ends up in the hands of the user. This is sometimes called the end product. There is also the system that manufactures the end product. There are also systems for verification (or test), deployment, installation, training, maintenance, administration, and disposal.

There are also all the non‐product related elements such as process, methods, tools, and environment. Also, how about technology and people? Hence, there are many “elements” that need to be integrated. This paper describes the things that need to be integrated and some of the means by which full integration can be ensured.
ON THE RELATIONSHIP BETWEEN ENABLING ELEMENTS & ENABLING PRODUCTS FOR A SYSTEM
Authors: Martin James N.
Published: November 2014

Critical requirements for a system are often missed because the full life cycle of a system is not well understood or the enabling products for the system are not well defined. Enabling products are those products that provide the means for getting end items into use, and for properly retiring thoseend items from use.

This paper describes a system life cycle, defines enabling product types, and gives examples of enabling products for a system. The utility of developing a full definition of the system life cycle and its enabling products is described. A mapping between enabling product types and the system life cycle is described. Full consideration of the system life cycle and its enabling products will ensure greater coverage of the requirements needed for the engineering of systems.
GRAPHICAL DESCRIPTION LANGUAGE:™ A SOLUTION FOR THE SYSTEM‐SOFTWARE INTERFACE PROBLEM
Authors: LaBudde Edward V.
Published: November 2014

A growing gap exists between the systems engineer and the software engineer. A major source of this gap is the failure of both engineering groups to adequately address certain system, function, and performance requirements during the decomposition process. This is especially true for logic, sequencing, and timeline requirements (LaBudde 1995).

One reason for this gap is that the old reliable system engineering tools like functional flow designs diagrams and N2 charts fail to capture all the requirements. In addition, the new software techniques like object‐oriented design also fail to capture all the requirements including sequencing, timeline, and performance. Another reason for this gap is the proliferation of software requirements and design methodologies. These have created a “Tower of Babble” of notations (Alford 1992). The confusion created by different notations can have serious consequences to system behavior and performance (Shaw 1995).

We define the requirements for a general purpose system engineering requirements and design capture method and tool. Furthermore, a proposed solution to this problem which will meet the specified requirements is presented. We have developed a robust Graphical Description Language™ (GDL™) which ensures that all the requirements can be described and related using graphical representations. This method is simple to execute and easy to understand by all team members. The method works equally well on describing requirements for mechanical, electrical, optical, and software implementations.

The approach provides a single, common method of communications for all engineers on the program and solves the system‐software interface problem.
INTEGRATING SYSTEMS ENGINEERING AND PROGRAM MANAGEMENT
Authors: Lilburn Bert
Published: November 2014

How do you integrate the work the Systems Engineer performs with the work the Program Manager performs? This was the problem facing the developer of a project management training course. The objective of the training course was to instruct employees on how to manage project work, how to implement a systems engineering process and culture, and how the company complies with project management and systems engineering requirements. The customer's criteria for a program management system and the company's requirements for systems engineering were the course requirements. A functional analysis of the process of managing contract work was performed. From this, a common set of functions were identified from which the specific tasks the Systems Engineer performs were integrated with those of the Program Manager.
BENEFITS OF STRUCTURED REQUIREMENTS METHODS FOR MARKET‐BASED ENTERPRISES
Authors: Novorita Robert J. , Grube Gary
Published: November 2014

The Land Mobile Products Sector of Motorola is currently transforming its commercial core business processes. Systems engineering has been recognize as a key solution for balancing the system developer, user, customer, and internal business manager perspectives. A cost effective balance between these various perspectives is of vital importance for commercial enterprise success dealing with complex internal and external environments. The first component of systems engineering capability adopted by Motorola Land Mobile Products Sector has been the functional area of requirements capture, analysis, and management. Improvement in the requirements functional area within Motorola Land Mobile Products Sector has lead to an improvement in delivered systems quality and a reduction in systems development cycle time. This paper describes the relationship between driving requirements, systems development cycle time, and systems quality from a commercial systems engineering perspective with some supporting data results.
AUTOMATING THE SPEC MANAGEMENT PROCESS
Authors: Kepchar Kenneth J
Published: November 2014

The management of requirements, especially in military programs, has always been a complex undertaking. During the course of a contract, considerable effort is expended managing the requirement as the design matures. Clarifications and interpretations to the original requirements become inevitable. The fine tuning of the requirement set continues up to, and even after, a weapon system is delivered. Recent software advances offer a number of tools capable of assisting the Systems Engineer to manage the complexity involved. This paper presents a case study of the integration of a commercial off‐the‐shelf (COTS) tool set with RDD‐100® to perform specification management and delivery on the F/A‐18E/F Super Hornet military aircraft program at McDonnell Douglas.
AUTOMATING CONFIGURATION PROCESSES: A STEP TOWARD MASS CUSTOMIZATION
Authors: Shreve Susan
Published: November 2014

For companies to maintain a competitive advantage in a changing global market they must continuously improve to operate profitably and strive for customer satisfaction. Customer satisfaction means delivering the right product, customized to exact specifications, delivered when it is needed with excellent support services available. Today's manufacturing processes are moving from mass production to mass customization to support individual customer needs. In addition to the production process complexity, the systems themselves are becoming increasingly more complex. A key enabler to manage this complexity is to capture and organize user requirements and map them to a configurator to produce accurate Bills of Material. This paper describes aspects of implementing automated configuration processes using a semiconductor equipment manufacturer for examples of business issues.
EVOLUTION OF THE TECHNICAL REQUIREMENTS BASELINE WITH DESIGN PHASES OF A PROGRAM OR PROJECT
Authors: Rindskopf M. Sam
Published: November 2014

The U. S. Department of Energy Civilian Radioactive Waste Management System has unique requirements that drove tailoring of the technical baseline development process. Because of different schedules for start up of various elements of the system, the technical baseline was developed from top to bottom very early in the program. Many interfaces existed and early development of technical requirements aided identification of these interface requirements. This technical baseline development process provides a method for managing the ever‐increasing level of detail required for the technical baseline as it evolves. Successful management of the technical baseline, with the evolution of the design, requires a disciplined process to identify requirements at the appropriate level of detail for the phase of design. A key for success is implementing a change process that is responsive to the program needs.
OBJECTS, ACTORS AND ROLES: AN IDENTITY TRIAD FOR REQUIREMENTS
Authors: Rhodes Robert R.
Published: November 2014

The author proposes a technique for identifying all needed requirements for a system component. The technique is applied at the earliest stage of a system project, when the system developer and the customer must work together to define operations concepts and capabilities for the conceived system. This also is the time when system engineering seems more like an art than a discipline, and guidance is rarely to be had.

The technique employs “actors”, “roles”, and “objects” to identify all the functional capabilities required for a system component in the context of a larger system in which the component resides. The technique can be used very early on, even when an information model has not been fully formulated, and the system boundaries are not yet clear. The technique can be further used at all levels of requirement analysis and architecture design, because it is based on external “interest” in the functional capabilities of the component.
CLOSING THE GAP BETWEEN REQUIREMENTS DEFINITION AND PRODUCT DEVELOPMENT: A CASE STUDY
Authors: Iwach Alexander E. , Sims Steven J.
Published: November 2014

A critical factor in efficient product development is defining the system requirements in a product development team environment. This paper describes the implementation of a strategy for defining meaningful system and subsystem requirements within a predominantly hardware‐oriented engineering culture. The resulting requirements documentation became the baseline for subsequent design and development efforts, thereby linking the requirements definition to product development. Critical ingredients in building this link include: (a) defining engineering guidelines to establish an initial conceptual framework; (b) fostering an environment conducive for integrated product development teams to perform requirements analysis effectively through requirements elicitation; and (c) providing leadership in resolving technical difficulties to accelerate the resolution of complex requirement issues through consensus building. Examples of the process of solving requirements issues are provided.
REQUIREMENTS FOR DISTRIBUTED WORK SUPPORT SYSTEMS
Authors: Byers James C. , Kaplan Bruce L. , Gilbert B. Gay , Reece Wendy J.
Published: November 2014

The purpose of this paper is to present the results of research which developed a general model of Distributed Work Support Systems (DWSS)–computer based tools that enable geographically dispersed groups and teams to communicate, coordinate, and otherwise work together on complex problems. The model developed was intended to be one that could be used 1) to evaluate currently available DWSS, as well as 2) to point the way towards development of better DWSS. The development of a general model involved investigation of three principal areas. The three areas were: Organizational Study, Human Capabilities Study, and Available Technology Assessment. The general model was put together by integrating information from these three studies. The model is composed of a series of requirements for a DWSS tool. The requirements are often broad in nature because this is a general model for a DWSS. Under development are a set of prototype tool requirement to aid groups in performing systems oriented work. This paper presents an overview and examples of the requirements identified thus far.
MULTI‐TEAM INTEGRATION: INTERDEPENDENCE AND INTEGRATIVE MECHANISMS
Authors: Browning Tyson R.
Published: November 2014

The drive towards Integrated Product Development (IPD) includes an impetus to organize around Integrated Product Teams (IPTs). The use of IPTs has brought with it many issues, including those at the IPT interfaces. Program integration (cross‐functional, upstream/downstream, customer and supplier) can exist at several levels, within IPTs and between IPTs. This paper focuses on the realm of IPT interdependence, and categorizes several Integrative Mechanisms (IMs) to facilitate interteam integration. IMs are strategies and tools for effectively coordinating actions across IPTs within a program. This paper is based on studies in the aerospace industry, but the implications extend to any large, complex development program.
Application of Statistical Processes on a Set Theory Model for Anomaly Handling in System Requirements Analysis
Authors: Sanchez James A.
Published: November 2014

In 1995 Ronald Carson developed a mathematical model for system requirements analysis (SRA) utilizing set theory to explicitly treat unwanted or unexpected conditions that may be experienced by the system being analyzed. He showed that the SRA model can be used to derive completeness criteria. He claimed that the highest utility of the model would be found in the area of software requirements because of the focus on system states.

A simple example using a Power Distribution Unit (PDU) was made in order to clarify the salient points. This simple example had only three states and six transitions, which were identified as nine antecedents (conditions which precede). Eight requirements were generated for the PDU.

In this paper, the author assumes that the requirements for this simple example are stochastic, rather than deterministic, in nature. The arguments in support of this assumption are compelling. One is that many processes which are defined by a set of requirements are themselves stochastic in nature. Another is that a near deterministic model can be developed from a stochastic model in many applications. One can also argue that a stochastic process is more robust and better suited to a set of requirements subject to change due to ambiguities in syntax or lexicon or in how a system is thought to behave.

The entire set of requirements constitutes the probabilistic universe of the system. Each requirement has a probability associated with it that the requirement is satisfied. Furthermore, the requirements may have dependencies.

The methodology is developed from simple Bayesian relationships that have been used in a number of computer automated tools. What may seem different is that the probability is a characteristic of the antecedent rather than the requirement itself.

This model, though not desirable for all classes of requirements, may fit a number of situations where the outcome of the requirement is not certain.

In conclusion, the SRA model utilizing elementary set theory is expanded from a deterministic system to a stochastic system. The method is rigorous, and can account for 1) ambiguities in language, 2) unforeseen conditions, 3) undefined initial conditions, and 4) probability density function of primitives. It can also make the system defined by a set of requirements more robust.
TEAMS ARE NOT INTEGRATED PRODUCT DEVELOPMENT
Authors: Armstrong James R.
Published: November 2014

…Necessarily. In the current race to embrace IPD (or IPPD) as the panacea of the nineties, teams have been identified as the pro forma solution. The assumption is that by establishing multi‐discipline teams, the objectives of IPD will be automatically achieved. However, evidence conflicts with this assumption. In reality, focusing on teams can distract management from the real goals of IPD. By understanding the objectives of IPD and the effects of teams, the relationship of the two can be understood. Then, effective implementation can occur.
THE CREATION OF SYSTEMS AND SOFTWARE STANDARDS BY AN EVOLUTIONARY PROCESS
Authors: Brook Peter , Arnold Stuart , Barnes Derek , Stevens Richard
Published: November 2014

Improving the efficiency of the development of software and systems is essential to all modern companies. For one UK organisation, this has led to a concerted effort in developing and applying standards, training, pilot projects, promotional activities, and setting up centres of expertise. The results for both software and systems have been almost totally positive. A relatively small investment has made systems and software developments more professional, and this approach is being extended across the whole organization.

A continuous process improvement approach has been adopted, with the initial effort focused on achieving ISO 9001 certification for software. The second iteration has used experience gained to enhance the original standards. The goals for Phase 2 were to cover large systems, to improve metrics, and to cover feasibility work. The systems process was itself used to define a coherent architecture for the standards, along with the training and organisational implementation. The wider professional community has been involved in the standards process, including the DERA's customers and associates, industry, as well as members of the UK INCOSE Chapter. This paper records the experience in evolving the standards.
USE OF PROCESS MODELS TO ESTIMATE A PROJECT'S DEVELOPMENT COSTS
Authors: Langston Dale G.
Published: November 2014

Current cost models were developed based on the assumption that complexity of the product was the dominant predictor of cost. This paper describes a cost model developed around process capability that eliminates the dependency on complexity. This paper describes the development of the model, results from execution of the model, and future work to be undertaken to extend to model.
IMPLEMENTING RECALL: A CASE‐BASED REASONING SYSTEM FOR THE ACCESS AND REUSE OF LESSONS LEARNED
Authors: Sary Charisse , Mackey William
Published: November 2014

This paper discusses the activities of an ongoing project to develop and field the Reusable Experience with Case‐Based Reasoning for Automating Lessons Learned (RECALL) system. RECALL captures and reuses lessons learned at the National Aeronautics and Space Administration (NASA) Goddard Space Flight Center's Mission Operations and Data Systems Directorate (MO&DSD). Primarily, systems and software engineering lessons learned are captured. Lessons learned describe positive experiences and successes that need to be reinforced, as well as problems faced and ways to avoid them in the future. We believe that lessons learned would be reused more often if others confronted with similar problems could locate them quickly and easily.

Therefore, the case‐based reasoning (CBR) approach is being tried as an alternative to more conventional or other intelligent software methods. A proof‐of‐concept prototype was developed and demonstrated to evaluate the applicability of CBR to this problem. This paper describes subsequent work, which includes making RECALL operational and fielding the system on the World Wide Web to facilitate user access. Because the system will be available to a diverse set of users, a process for incorporating lessons into the database has been defined. This paper describes the process and the actual execution of this process during RECALL implementation.
MEASUREMENT TOOLS FOR RAPID DEVELOPMENT
Authors: Goldense Bradford L.
Published: November 2014

The state of measurement of product development in the 1990s is still largely historical and reactive, but at least measurements are now being made. Measurement is central to improvement. For the past twenty‐five years there has been relatively little improvement in product development productivity. Now the first emergence of predictive and/or proactive metrics are changing fundamental thinking towards the use of measurements to drive product development change, not just to record results. This trend in product development is analogous to the evolution of measurement during the 1980s in the manufacturing‐based functions. Also analogous, is that the product development focus is on measuring processes and not just the resultant product. Comprehensive approaches require metrics for ten to fifteen separable but interrelated business and/or technical processes that comprise product development. Case studies from medical, process control, instrument, and semiconductor companies illustrate measurement approaches and applications of specific metric tools and techniques. Product development metrics will evolve over time to a now unforseen science once a great number of companies cut their cycle time in half. Metrics and measurement tools deployed today will ultimately be considered rudimentary two decades from now.
SOFTWARE QUALITY METRICS FOR LARGE SCALE SYSTEMS DEVELOPMENT
Authors: Toth Kalman C. , John Robert , Stewart Ronald
Published: November 2014

Metrics are widely viewed as critical to the execution of large scale software development and systems integration projects. To attain high levels of maturity as defined by the Software Engineering Institute's Capability Maturity Model [Humphrey 1989], it is clear that in addition to effective project management and change controls, metrics processes need to be integrated into the activities of development projects and institutionalized within the business itself. This paper outlines how Hughes Aircraft of Canada Limited, Systems Division (HCSD) has established divisional and program‐specific metrics processes support the production of high quality, maintainable systems. The metrics activities for the Canadian Automated Air Traffic System (CAATS) are used to illustrate many of the ground‐breaking accomplishments achieved at HCSD
IMPLEMENTING A SUCCESSFUL METRICS PROGRAM
Authors: Ramchandani Chander , Buford Carolyn
Published: November 2014

In today's highly competitive business environment, with its tight budgets and pressure for continuous improvement and reengineering, qualitative improvements are no longer adequate for an organization to be competitive in the marketplace. Improvements need to be measurable, which requires the availability of quantified baselines and metrics to support the quantification. This paper describes a framework for collection and utilization of metrics within an organization involved in the engineering, development, and deployment of complex systems; the types of metrics that are needed to measure the effectiveness of an organization's processes; and a proposed framework for their utilization at the tactical and strategic levels, including their roles in process improvement and reengineering. This paper also discusses commonly encountered pitfalls and guidelines for implementing a successful metrics program.
ROCKWELL COLLINS AIR TRANSPORT METRICS
Authors: Philpott Ian W.
Published: November 2014

To continue as a world class avionics company, Collins Air Transport Division is adding engineering metrics to well‐planned Systems, Hardware and Software Processes. We ask much of our engineers, requesting them to follow new and unfamiliar processes, while measuring their work. The paper reviews the objectives of the metrics program and how we are carrying out those objectives. The paper also reviews our staff's concerns introduced by the metrics program.
Supplier Selection Using Capability Maturity Model
Authors: Reichner Albert
Published: November 2014

The Systems Engineering Capability Maturity Model (SE‐CMM) is designed to help organizations improve their practice of systems engineering through self assessment. Although version 1.0 of the SE‐CMM is not intended to be used for supplier selection, the characteristics of a systems engineering organization that indicate mature processes in a self assessment are similarly desirable in assessment for purposes of supplier selection. The existing appraisal method, on the other hand, needs modification for application to supplier selection. The author was a member of a team that used the SE‐CMM with a modified appraisal method to assess the systems engineering capability of four companies for the purpose of supplier selection. As the assessment progressed, the appraisal method was tuned to account for differences between supplier selection and self assessment. In the end the appraisal team successfully accomplished their goal of advising the customer as to the relative and absolute systems engineering capabilities of each candidate supplier.
A Second Systems Engineering Process Assessment at the Westinghouse Hanford Company
Authors: Widmann E. R. , Brenchley D. L. , Andrews B. A. , Worl J.
Published: November 2014

In September 1995, a second systems engineering process assessment (SEPA) was conducted at the Westinghouse Hanford Company (WHC) using the INCOSE Systems Engineering Capability Assessment Model (SECAM) and supporting documents. This SEPA, like the first at WHC in February 1995, was facilitated by the INCOSE CAWG, which developed the INCOSE SECAM and supporting documents (assessment method). The Capability Assessment Working Group (CAWG) is one of four working groups that comprise the Measurement Technical Committee of the Technical Board of the International Council on Systems Engineering (INCOSE).

This paper presents detailed information about the SEPA with emphasis on: (1) background events leading up to the SEPA; (2) planning undertaken to ensure the success of the SEPA, including tailoring of the INCOSE SECAM and supporting documents; (3) conduct of the SEPA; (4) post‐SEPA activities, including observations on the ability to mature using the INCOSE SECAM as a vector for growth; and (5) observations from the SEPA, including lessons learned and recommendations for improvement and subsequent impact on the INCOSE SECAM and supporting documents. The SEPA is noteworthy since it is the first time that a complex model developed for measuring systems engineering capability was applied twice to the same organization. This offers the potential of beginning the validation of the model.
A Synopsis of Metrics and Observations from Systems Engineering Process Assessments Conducted Using the INCOSE SECAM
Authors: Andrews B. A. , Widmann E.R.
Published: November 2014

The INCOSE Systems Engineering Capability Assessment Model (SECAM) was developed by the Capability Assessment Working Group (CAWG) to assess systems engineering capability. Eleven systems engineering process assessments (SEPAs) have been conducted using the SECAM and the proto‐models from which it was developed. Three more SEPAs are planned for the near future. This paper characterizes and contrasts the assessment techniques and metrics from each SEPA. Insights from these SEPAs are also summarized to assist potential users of the INCOSE SECAM understand how to prepare for the assessment process.
CONTROLLING THE CHAOS: AN INTEGRATED APPROACH TO MANAGING A SYSTEM DEVELOPMENT PROGRAM
Authors: Adamsen Paul B.
Published: November 2014

Why so much chaos so quickly on many development programs? Typically during the proposal phase the Management Volume is generated in isolation from the Technical Volume and vise versa. After the program is awarded this discontinuity becomes a major fissure embedded in the foundation upon which the program is built. Often chaos in varying degrees results. Symptoms of this condition include: difficulty in measuring progress which impairs visibility afforded to management; key requirements are not communicated to all impacted areas; and critical issues do not get surfaced to management in a timely fashion. Thus the chaos level of the system rises which, in turn, causes the technical, cost, and schedule risk to increase since risk increases proportionately with the chaos level of the system. This paper suggests two ways of minimizing program chaos: first, to implement semi‐autonomous Integrated Product Teams (IPT) and organize them according to the logic of the System Development Process (SDP) (see Adamsen, 1995); second, to integrate the responsibilities of management and technical development under each IPT, fitting each to function semi‐autonomously. The IPT then becomes the mechanism for integrating not only the technical activities, but also the management activities. This environment fosters an atmosphere of camaraderie which facilitates communication across all disciplines of activity. In addition, the development of meaningful metrics tracked with honest inputs occurs since naturally adversarial relationships have been alleviated. Open and honest communication to management is encouraged since all are on the same team and win or lose together, and management of the configuration is facilitated because all the stakeholders are involved in the development. With this approach, the typical discontinuity between the management team and the technical development team, and the ensuing chaos, can be effectively mitigated.
REQUIREMENTS CONSISTENCY ‐A BASIS FOR DESIGN QUALITY‐
Authors: Van Dewerker F. Scott , Booth Stuart T.
Published: November 2014

Large design projects have a significant challenge to maintain consistent quality specifications throughout the development life cycle. The cost of maintaining such specifications and ensuring their consistency is high, and if not performed adequately can pose a significant risk to the program by inducing errors into the design. This paper presents methods for automation in concert with a process that will effectively reduce the inconsistencies in specifications.
Observations on the Measurement of Systems Engineering Capability
Authors: Widmann E. R. , Dragavon E. J. , Schuster J. J. , Richman G. , Bradley D. W.
Published: November 2014

In the past few years, several models have been developed to measure systems engineering process maturity. Two of these models have gained a great deal of attention: the INCOSE SECAM and the EPIC (formerly Industrial Collaboration) SE‐CMM. This paper describes the conduct of a dual systems engineering process assessment that applied both of these well known models to the same organization using the EPIC SE‐CMM Appraisal Method, rather than the shorter duration INCOSE SECAM Assessment Method. The assessment was conducted at Hughes Aircraft Company (HAC), Electro‐Optical Systems (EOS). The assessment is noteworthy since it is the first time both models have been applied concurrently. This paper provides a synopsis of both models along with a description of the dual assessment. Issues observed from the assessment regarding the models and the Appraisal Method are described; their resolution is important for the conduct of future assessments. Impacts upon the two models and application methods are discussed based upon the experiences gained from the dual assessment.