bluuebunny/crossref_metadata_2025 huggingface dataset:
6.2.1 THE IMPACT OF SYSTEMS ENGINEERING ON QUALITY AND SCHEDULE *EMPIRICAL EVIDENCE*
Authors: Frantz W. Forrest
Published: November 2014

Most Systems Engineering (SE) organizations have little need to prove their worth. SE disciplines are required to fulfill contractual line items. The worth of SE disciplines was long since proven. But not all companies and organizations are this lucky. In fact, a large company known for its strength in SE may have organizations that don't understand or practice SE disciplines. In these organizations, it can be difficult to “sell” Systems Engineering.

This paper defines Systems Engineering and presents empirical evidence of its worth. Three similar projects were run in parallel. Each had varying degrees of SE disciplines implemented ‐from nearly none to high. The two projects using SE were delivered more than twice as fast. The project using the highest level of SE was delivered nearly three times faster and had the highest quality. While conclusions concerning what caused an outcome in any complex project are subjective, this paper compares the projects in detail so that conclusions can be drawn as to what caused cycle time and quality differences.
2.5.1 A NEW SYSTEMS ENGINEERING TAXONOMY
Authors: Shenhar Aaron J.
Published: November 2014

Although real‐world systems exhibit considerable differences, there is very little distinction in the literature between the system type and the description of its actual system engineering pursuit. We suggest here a new approach to systems engineering. It is based on the premise that the actual process of systems engineering must be adaptive to the real system type. Using this concept, we present a two‐dimensional taxonomy in which systems are classified according to four levels of technological uncertainty, and three levels of system scope. We then describe the differences found in systems engineering styles in various areas, such as system requirements, functional allocation, systems design, system testing, and project organization. Furthermore, we show that adapting the wrong system and management style may cause major difficulties during the process of system creation.
2.5.2 THE NECESSITY OF LOGICAL CONTINUITY
Authors: Grady Jeffrey O.
Published: November 2014

There apparently exists a very strongly held view among many members of NCOSE that requirements analysis is a proper precursor to functional analysis. This view was documented in MIL‐STD‐499B, which failed approval as DoD moved toward commercial standards in manufacturing and management areas, but lives on in draft IEEE P1220 and draft EIA 632.

The author tried for several years prior to publication of his book System Requirements Analysis to arrange the elements of the system engineering process using this sequence, such that there existed a condition of logical continuity, without success. SAMSO and BMO system requirements analysis documents, such as SAMSO STD 77‐6, offered an alternative that encouraged logical continuity and that was the basis for the author's book, System Requirements Analysis.

This paper makes the case for the necessity for logical continuity in the development of systems to satisfy complex needs, identifies a work sequence that complies, and exposes the discontinuity entailed in the approach encouraged by current standards.

The author recognizes that the position expressed in this paper may be separated from the position endorsed in current draft standards only by semantic differences, but attempts to expose such differences have been unsuccessful to date leading to the conclusion that the differences are substantive. Those who hold the view opposed to that expressed in this paper are encouraged to contrast their position and carefully explain how their approach assures logical continuity or declare the lack of any need for it.
3.5.2 SYSTEMS ENGINEERING FLOWDOWN ON THE F‐15 PROGRAM
Authors: Hugge Paul B.
Published: November 2014

Systems Engineering defines a disciplined design and verification process for developing systems. Its iterative and balanced approach results in systems that meet all of their intended needs and satisfy all of their intended customers. McDonnell Douglas Aerospace (MDA) is implementing Systems Engineering across the enterprise, including mature systems such as the F‐15 Weapon System.

The F‐15 Program has taken Systems Engineering and tailored it to support new development activity. The F‐15 Program expects to improve product reliability and maintainability, develop performance upgrades, and improve the producibility of the F‐15 Weapon System by applying a disciplined Systems Engineering process to selected elements of the system.

The F‐15 Program is expanding its Systems Engineering approach as part of its Integrated Product Development organization. This paper describes MDA's Systems Engineering process, the tailored F‐ 15 Program implementation approach, and progress to date.
6.4.3 A Systems Engineering Approach to Optimize Customer Satisfaction on Complex Systems
Authors: Lakey Peter B.
Published: November 2014

At McDonnell Douglas, a creative approach to resolving the issue of flowing down requirements to best meet customer needs has been developed. The approach provides guidance identifying and rank ordering preferred design choices, developing requirements flowdown, and illustrating the sensitivity of performance parameters based on the selection of optimal choices. The methodology determines a Customer Quality Model (CQM) using modified Quality Function Deployment (QFD) assessments[1] in combination with management science techniques for optimization to perform numerical suballocation of system level requirements. The approach provides guidance toward solutions which protect the customer's interests without the need for the customer to dictate design solutions and contractual requirements at these suballocated levels of detail. A computer application of this methodology has been produced by McDonnell Douglas and exists as an EXCEL software tool.
6.5.2 AN ISO 9000 QUALITY SYSTEMS ENHANCES SYSTEMS ENGINEERING
Authors: Wray Richard B.
Published: November 2014

No matter what industry you are in, the question “Are you ISO certified?” is becoming more important. As you read the International Organization for Standardization (ISO) 9000 set of standards, however, you will realize they offer much opportunity for interpretation. The primary thrust of ISO 9000 is quality processes in product development and use of quality systems. The issue often boils down to understanding the system requirements of your industry and company for quality, determining what you do, documenting what you do and doing what you have documented. For systems engineering in the National Council on Systems Engineering (NCOSE), the question is particularly relevant due to this focus of ISO 9000 on quality systems and of NCOSE on the quality systems engineering needed to achieve world class status. The key expertise of systems engineering is technical process understanding for product development. Thus there is a clear relationship between systems engineering and ISO 9000 requirements.

This article summarizes some key facets of the ISO 9000 quality system approach and how this affects systems engineering. Then it describes systems engineering, as it is evolving in the NCOSE Systems Engineering Process Working Group (SEPWG), and how it is impacted by ISO 9000. Finally, it draws some conclusions about their relationship and future.
A Systems Engineering Approach for Computer Based Systems Outline and First Results of a Program
Authors: Schweizer Gerhard , Thomé Bernhard , Voss Markus
Published: November 2014

This paper argues for the necessity of an engineering discipline for computer based systems and outlines its beginnings. It is based on results obtained and directions mapped out for such a discipline by the IEEE Technical Committee on Engineering of Computer Based Systems (ECBS).

Computer Based Systems are seen as the technical artifacts of a dedicated engineering discipline. Experience and heuristics of such a discipline need to be grounded in a practical theory. On top of such a theory, a systems engineering approach has to be defined that allows the professional practice of the discipline and the safeguarding of the entire life cycle of all its artifacts. Such a systematization of a discipline inevitably leads to guidelines and to reference standards. Those reference standards reflect the systems engineering approach and regulate the engineering process. The different classes those reference standards fall into are discussed and some consequences are proposed.
Application of a System Architecture Standard to a Federated Information System
Authors: Percivall George S.
Published: November 2014

This paper describes the results of applying a system architecture standard during the development of a federated information system. A description of the system and the application of the standard to describe the architecture of the system are provided. Observations concerning the application of the standard are made, including description of the modifications in applying the standard in a federated environment, as well as, general comments about the necessity of using architectural styles and views.
Balancing Requirements and the Product A Process and Tools Case Study
Authors: Scheurer Robert P. , Kepchar Kenneth J.
Published: November 2014

A vast number of requirements are involved in the development of complex systems. Because the systems themselves contain many subsystems with a large numbers of parts, it is a formidable task to ensure that the final product is a complete and accurate reflection of the requirements contained in the customer specification. However, integrated teams now have new and better tools in their arsenal which can simplify their jobs. The following case study examines an improved process using integrated tools on the McDonnell Douglas F/A‐18E/F program for producing higher quality aircraft while still meeting exacting specifications.
An Architectural Model for System‐Level Design
Authors: Calvez J.P. , Peckol J. K.
Published: November 2014

The increasing complexity in the specification and design of electronic and computer based applications, demands that designers begin to think more and more at higher levels of abstraction. To reduce the gap between the specification level and the physical architecture, we propose to add an intermediate level called the functional architectural level. The proposed model has a well‐formalized, semantics and notation, satisfies most of the required properties for an architectural model and is fully integrated into the MCSE methodology. The generality of the inherent concepts permits the model and method to be used at various levels of abstraction and in a wide range of problem domains.
Optimization and Evaluation of Single‐Staged Transportation Systems Example for the Solution of Highly Complex Technical Problems
Authors: Kesselmann Michael
Published: November 2014

Space transportation vehicles are an example for highly complex technical systems. The optimization of these systems is very difficult due to the high degree of complexity and connectivity between the system elements and between the vehicle and its environment. Single Stage to Orbit (SSTO) vehicles as potential transportation systems for future space activities have not yet been investigated in sufficient depth to get an entirely consistent overview of potential fields of operation.

A systems engineering approach has been considered to systematically examine the influence of system variations on the overall performance and cost of the vehicle. To speak more generally, in the early pre‐design phase of a new system it seems to be reasonable to first elaborate some alternative concepts. In a second step qualitative sensitivity analyses based upon slight variations of certain vehicle components are investigated.

The proposed process has proven to be a very useful and reasonable approach for relatively detailed and reliable evaluation and optimization of complex systems in the pre‐design phase.
Transformation from a Functional to Process‐Centered Systems Engineering Organization
Authors: Walden David D.
Published: November 2014

Driven primarily by a goal of accelerating systems engineering process maturity, Computing Devices International transitioned its Systems Engineering Department from a functional organization to a process‐centered organization. This paper describes the key characteristics of a process‐centered organization and shows the application of this concept to systems engineering.
Program Maturity and Red‐Team Findings
Authors: Kaslow David E.
Published: November 2014

Almost all programs are established with the components needed to be successful. Those components are: a management process consisting of structures, schedules, and reviews; an engineering process; and a development process. However, a program, especially a large program, can discover too late that the design does not close. Then a red‐team is brought in to assess program maturity and to recommend modifications to design, as well as to the management, engineering, and development processes. This paper characterizes typical red‐team findings and provides recommendations for the review process, decision mechanisms, and review checklists that will address the typical red‐team findings.
A Collection of Integrated Product Development Lessons Learned
Authors: Cusick Kerinia
Published: November 2014

As part of the development process for the Integrated Product Development Capability Maturity (IPD‐CMM) model, the model authors interviewed a series of people from a variety of companies, gathering information on what they believed to be the important aspects of Integrated Product Development, and what they had learned in the process. This paper is a summary of the key points gathered from those interviews, as well as a collection of the primary characteristics that we believe distinguish good Integrated Product Development.
Management of the Systems Engineering Discipline
Authors: Bruno Michelle E. , Mar Brian W.
Published: November 2014

For a company to remain competitive in the market place it is important for the company to utilize their systems engineering workforce effectively. To do this, a company must collect information about their workforce and manipulate this information to the companies' benefit. This paper explores the management of the systems engineering discipline across companies that perform systems engineering activities by: (1) summarizing the current literature, (2) reporting the results of an industry survey, and (3) identifying additional areas for research. Literature is limited when discussing the management and monitoring of individual systems engineering capabilities, the survey data provides insight on how companies manage and track their systems engineering workforce.
The Leverage of Leadership
Authors: Ortberg Natalie Jaramillo
Published: November 2014

The Aerospace Industry has been reeling from all the changes it has seen in the last five years. U.S. Defense budgets have been declining since 1990 from approximately $300 billion to under $250 billion in 1995 (Economist, 1995) and the trend has led to the largest downsizing and consolidation the industry has ever seen. International defense and aerospace companies from all political spheres are also affected, because competition is no longer only based on national, regional or political boundaries as in the past. This paper will study the relationship as leadership style leverages the ability of a systems engineering organization to implement change initiatives that are necessary to sustain a Competitive Advantage in the Aerospace Industry. The challenges of consolidating operations within Aerospace companies is used to illustrate the thesis that leadership styles at all levels of the company affects the ability of an organization to change.
ACHIEVING MORE SCIENTIFIC SYSTEMS ENGINEERING PRACTICES: PRC'S EXPERIENCE IN APPLYING THE SE CMM
Authors: Young Ralph R. , Mosier Steve
Published: November 2014

A criticism that could be levied on the systems engineering profession is that while we have been working hard at it for a long time, the improvements in achieving a more scientific approach could be better than they have been. PRC is applying the Systems Engineering Capability Maturity Model (SE‐CMM) to facilitate a more scientific systems engineering (SE) approach. This article reports on the approach used and evaluates our progress to date. It provides insights for other organizations which are believed will facilitate more scientific advances in SE practices elsewhere.
Metrics and Teams: A Winning Combination
Authors: Brown Phillip J.
Published: November 2014

Team performance goals, in combination with process measurements, are essential in getting a group of people to produce extraordinary results. This premise was tested with a group of high school students preparing for the annual Academic Decathlon (AD) competition. Results speak for themselves. Previous team best was a 18th place finish at the state finals. The 1996 AD team finished fourth in Texas. This paper recounts the story of how metrics helped transform a disparate mix of high school students into a high performing team. Lessons learned are reviewed with an eye towards extending them into a business environment.
A Reliable Approach To Systems Engineering Process Maturity
Authors: Brezinski Lawrence J.
Published: November 2014

A reliable approach to achieving each stage of process maturity is needed to provide the foundation for continuing process improvement. When properly selected, systems engineering work products tie together standards, policies, and project activities as the basis for implementing a process improvement program. The overall organizational result is improved process maturity and a solid base for accelerating future process improvements.
A Quantitative Metric of System Development Complexity
Authors: Thomas L. Dale , Mog Robert A.
Published: November 2014

Each day, engineers cope with the challenges of building complex systems –challenges which threaten the project cost, schedule, and technical performance. Complex physical systems abound in nature – can engineers gain any insight on dealing with complexity from nature? Furthermore, how can these insights be applied? The discussion which follows suggests two fundamental lessons offered by nature in dealing with complexity: (1) system complexity is a function of component interaction and (2) complexity is a means which must be employed prudently. Subsequently, a complexity metric for the engineering application of these insights is presented.
Internal Development of Systems Engineers
Authors: Kaufman Mark S.
Published: November 2014

In the mid 1980's our division president was fond of repeating the statement that management often said, “Systems engineers are born and not made”. Apparently they were not being born fast enough to respond to an increasing need for experienced systems engineers available to be assigned to a wide variety of tasks. Also, as our systems engineering work force became more senior they were promoted to higher salary without the experience base necessary to move into the role of lead systems engineer or system architect. To rectify this problem, a program was put in place with the goal of developing senior level systems engineers. This program includes a documented systems engineering methodology, a set of supporting process documents, a personnel development process, training and mentoring.
Graduate Systems Engineering Education at the Air Force Institute of Technology
Authors: Kramer Stuart , Pohl Edward
Published: November 2014

The Air Force Institute of Technology offers a successful, accredited graduate degree in systems engineering. The program is based on the view that systems engineering is a design discipline. Students with undergraduate engineering degrees are given course work covering essential tools and techniques of systems engineering and are required to demonstrate mastery in a group design study. The program philosophy and curriculum are described and a recent design study is summarized. Although created to meet Air Force needs, the program and experience are relevant to others.
1.1.1 Classifying Systems
Authors: Paul Arthur S.
Published: November 2014

In response to concerns within the field of systems engineering about the overuse and possible misuse of the term ‘systems‘, this paper presents an in‐depth analysis of current schemes for classifying systems and proposes a scheme of nine classes that is simple, intuitive, and focuses on man‐made systems. The author's expectation is that individuals who are interested in the field of systems will communicate more effectively by qualifying systems and speaking of specific types of systems instead of speaking of systems in general. This can also be a first step in a process of developing methodologies and tools that are targeted to the different types of systems.
2.1.3 A Systems Approach towards Design for RAMS/LCC Lessons learned from cases within aerospace, chemical process, and automotive industry
Authors: van Baaren Ron J. , Smit K.
Published: November 2014

This paper presents the preliminary results of a Ph.D. project aimed to develop and implement a framework for the incorporation of reliability, availability, maintainability, supportability and life‐cycle cost (RAMS/LCC) aspects in the design and development process of large‐scale, complex technical systems. Within a systems engineering approach this shall lead to faster, more affordable design, production or manufacturing, operation and support of high‐quality systems that satisfy all customer requirements.

Three main activities of research are identified; need analysis, model development and application and validation. This paper centers on the results of several case studies conducted as part of the need analysis phase. These cases, conducted in Europe within three branches of industry (aerospace, chemical process, and automotive industry), identified the need for an integrated systems engineering approach towards design for RAMS/LCC. Additionally these cases provided an overview of current practices, lessons learned and area's of improvement related to design for RAMS/LCC.
3.1.4 A Hierarchical Method for Analyzing Candidate Solutions and Selecting the Best Option
Authors: Stokrp Mark C. , Birns Leonard
Published: November 2014

In this paper the authors describe a case study which used a Systems Engineering Capability Maturity Model (SE‐CMM)‐compliant process for Analyzing Candidate Solutions to evaluate computer system performance modeling tools and recommend one for company‐wide use. As part of the paper, the authors describe the background and objectives of the effort and the details of the technical approach employed. While evaluating competing vendors or commercial‐off‐the‐shelf (COTS) products may be the most common use, trade studies are also useful for analyzing requirements trade‐offs, system or network architecture alternatives, make‐buy decisions, schedule changes, and other decisions faced by engineers and managers.
4.1.1 System Architecture ‐ A View Perspective
Authors: Frank Rodger F.
Published: November 2014

Development and deployment of large software systems are among the riskiest of business ventures. Lack of ability to depict, communicate and evaluate the overall architecture of the system ‐ to describe how the system works ‐ is the central issue to this risk. This paper proposes a solution to the system architecture problem. By considering the needed architecture views and view relationships first, then identifying the models needed to implement the views and relationships between them. The concept of architecture views is developed, an example of a necessary and sufficient architecture view set for a large software‐intensive system is provided and architecture relationships to specification and object design are also described.
5.1.1 Overview of the EIA 632 Standard: Processes for Engineering a System
Authors: Martin James N.
Published: November 2014

The EIA 632 standard has been developed that describes the “processes for engineering a system.” This standard evolved from EIA/IS 632—the interim standard that described a systems engineering process. This paper will describe the structure of the standard, elements of the process, and key concepts such as stakeholder requirements, enabling products, building blocks, and development layers.
5.1.2 Evolution of EIA 632 from an Interim Standard to a Full Standard
Authors: Martin James N.
Published: November 2014

The EIA 632 standard has been developed that describes the “processes for engineering a system.” This standard evolved from EIA/IS 632—the interim standard that describes a systems engineering process. This paper will describe the heritage of this standard, reasons for this particular evolutionary step, and the approach in converting from the interim standard to the full standard.
2.2.2 Sources of Schedule Risk in Complex System Development
Authors: Browning Tyson R.
Published: November 2014

From one perspective, developing complex systems is an exercise in uncertainty reduction and risk management. In this article I first organize the principle sources of risk in product development into five categories: market risk, product performance risk, technology risk, development cost risk, and schedule risk. Second, I synthesize research findings from literature and interviews with experienced product development managers and system engineers at a major aerospace company regarding the sources of uncertainty underlying one of these categories, schedule risk. Relationships between these sources of schedule uncertainty are shown using a causal framework. The goal of this preliminary work is to highlight areas for increased attention in planning and management processes, while providing a systems view of the effects of certain actions.
4.2.2 Untangling the Twists in Requirements Analysis
Authors: Jorgensen Raymond W.
Published: November 2014

This paper is a description of requirement analysis techniques that can be used to effectively describe a complex system, using concepts of abstraction and decomposition to layer the system definition into easily understood subsystem components. By using abstracted layers of the system, documents describing the system are more easily understood by reader's who may be unfamiliar or only somewhat familiar with the system description. Also, appropriate abstraction can help the system designers and developers organize and find critical information more readily than the brute force attack of system definition. After all, the entire purpose of systems engineering techniques is to create information that is readily understood and communicable to developers and users of a system. Effective communication with a diverse community of people is the focus of systems engineering practice.
3.3.2 Formalisation of an order processing soft systems model using Petri nets
Authors: Sagoo Jaspal , Boardman John
Published: November 2014

Soft systems methodologies are known for investigating the problems occurring in the management of organisations using conceptual models. These models are informal and thus they are easily used and understood by a non‐specialist. However, such models cannot be subjected to formal analysis, and problems can occur in verifying their correctness. This paper addresses this issue by combining Petri net theory with the conceptual models of a methodology known as the Boardman Soft Systems Methodology (BSSM). Specifically, a systematic approach is presented that allows the systemigrams of the BSSM to be translated into Petri net models. This translation allows a systemigram to be checked for the integrity of its data, and Petri net theory can be used to analyse the resulting Petri net models. It is the intention that this type of analysis would be used by a target audience to verify and validate the systemigram models. Application of this approach is illustrated by an industrial case study that involves the Order Intake phase of a product's life cycle.
3.3.3 VERDICT: A Distributed Virtual Environment for System Engineering
Authors: Kuchinski Michael J.
Published: November 2014

Abstract1

This paper proposes a framework for the development of a distributed virtual interface (called VERDICT) for a system engineering development environment that (1) focuses on the role of the human in the system being designed, (2) focuses on the cognitive needs of the engineers using the development environment, and (3) facilitates the intended universality of the environment by relying on technologies that allow architecture independence. VERDICT stands for Virtual Environment for Remote Design Integration and Configuration Testing. Its purpose is to provide a distributed virtual interface to a system engineering environment for the design of complex systems. Principal among its goals is the organization of information through the development of a taxonomy of the types of knowledge representations, or cognitive media, used in system design. Related to this goal is the determination of how these cognitive media are best represented by physical media (text, graphics, animation, sound, etc.). Another goal is implementation transparency, through the utilization of enabling technologies such as Java and CORBA.
3.3.4 Practical Experience Applying Formal Methods to Air Traffic Management Software
Authors: Yates Richard , Andrews Jamie , Gray Phil
Published: November 2014

This paper relates experiences with formal methods that are relevant to the systems engineering activities of requirements specification, design documentation, and test case generation. Specifically, this paper reviews the lessons learned from the application of formal methods to selected components of an air traffic management system. This project used experimental tools developed at the University of British Columbia: S, a formal specification tool; HPP, an HTML documentation tool; and TCG, a test case generation tool. The components experimented on are from a recently fielded system written in C++ using unimplemented pre‐ and post‐conditions on components. The purpose of the experiment was to evaluate the usefulness of these formal methods to uncover design or logic errors in the system components and to assist in designing test cases. This experience identified some ambiguities in the original specification, evaluated the feasibility of the experimental tools we used, and identified areas in which the tools could be improved.
4.3.1 The SEDRES Project (Systems Engineering Data Representation And Exchange Standardisation); Producing A Data Exchange Standard Supporting Integrated Systems Engineering
Authors: Johnson JFE
Published: November 2014

Integrated Product Development frequently involves multi‐company and multi‐national teams, using heterogeneous design tool sets. Systems Engineering (SE) must be able to operate in this environment. SEDRES is producing a neutral data exchange standard based on STEP (ISO‐10303), that will embrace product definition aspects crucial to successful SE: product requirements, systems architectures, product functionality, allocation, traceability and configuration management information. The standard will enable SE tools to exchange such information, and should be applicable to many industries.

SEDRES is a three‐year European Commission‐funded ESPRIT project, running 1996–1998, which was initiated by Aerospatiale, Alenia, British Aerospace, DASA and Saab. Also contributing are the Universities of Loughborough, Linkoping, and the Australian Centre for Test & Evaluation.

This paper describes the emerging standard, reports on early exchanges and on the successful vote for an ISO standardisation activity. It explains how the draft standard is being extended in the second project phase, and future intentions.
4.3.2 An Information Model for Integrating Product Development Processes
Authors: Lykins Howard , Rose Susan , Scott Peter C.
Published: November 2014

This paper describes some of the work products used or generated during the development of a software‐intensive system by integrated product teams (IPTs) working on the system elements. An information modeling approach represents the relationships among the information entities involved in the system‐level management, design, verification, integration, and testing activities: the model has been extended to the subsystem, configuration item, and component levels. The purpose of the information model is to provide developers with additional knowledge about the work products composing the information flows defined in a process model. This additional knowledge makes it easier to adopt the process model, tailor it for use on a project, and understand the roles of the IPTs and their members.
5.3.5 Integration of Small Satellite Cost and Design Models for Improved Conceptual Design‐to‐Cost
Authors: Mosher Todd , Barrera Mark , Lao Norman
Published: November 2014

In the late 1980's a new paradigm, the utilization of modern small satellites, arose and opened up a new class of space applications. Since 1991, The Aerospace Corporation has been studying small satellites. Two products of this on‐going study are the Small Satellite Cost Model (SSCM) and the Small Satellite Design Model (SSDM). In an effort to better meet design‐to‐cost goals for conceptual design, The Aerospace Corporation has recently integrated the SSCM and SSDM into a single design‐to‐cost tool for use by a systems engineer either working alone or in cooperation with a design team. Several versions of the integrated tool are being developed with varying levels of fidelity.
1.4.3 Traceability for the Development and Assessment of Safe Avionic Systems
Authors: Pearson Sheena , Riddle Steve , Saeed Amer
Published: November 2014

For complex avionic systems, evidence must be provided to demonstrate that the risk associated with the software is acceptable. It has been proposed that this evidence be obtained by conducting safety assessment in parallel with development. This increases the importance of co‐operation between teams (including development, assessment and safety authority). To facilitate this co‐operation, a traceability method is proposed, based on a set of information structures and procedures for their analysis. An application of the approach to a study based on the Slats & Flaps system for the Airbus 321 is presented.
1.4.4 Use of QFD as an Integrated Product Team Tool to Select Concepts Based Upon Requirements
Authors: Hess Don , Vance Matt , Ball Doug
Published: November 2014

The potential for improved weapon load outs on advanced aircraft was recognized by the Wright Laboratories, Munitions Division as a key enabling technology for dramatic improvements in the system performance and affordability. The dilemma faced by the Laboratory was the plethora of enabling technologies, and design concepts. Their combinations were staggering. Given recent weapon technology investments and varying strongly held professional opinions on the best aircraft integration approach, the way ahead was not obvious. Over 1000 potentially feasible combinations of options were available.

The laboratory was interested in demonstrating feasible technologies to reduce risk and increase the technical readiness of compressed weapons technologies.

The overall goal was to increase the sortie effectiveness of small, F‐16 class fighters by over an order of magnitude using new smaller more accurate munitions currently in development. Resources were available for further development of a limited number of compressed weapons technologies and aircraft carriage technologies. The way we chose to rapidly and accurately identify the high payoff concepts was the use of Quality Function Deployment (QFD) as a formal systems engineering tool in an Integrated Product Team environment. The use of QFD enabled the IPT to select high payoff technologies based upon “system requirements” and a high degree of professional knowledge and experience. The QFD process enabled us to eliminate biases built in from the different organizational views of the team which was made up of government/industry, weapon/aircraft, primes and suppliers and to identify synergistic concepts worthy of additional design and development.
4.4.2 Designing Client‐Server Systems for the Intensive Care Unit: An Application of Performance‐Driven Design
Authors: Zaleski John R. , Binder Ernst , Silliman Keith
Published: November 2014

We present a method of computer system performance analysis. As an example of the method's utility, we apply it to the process of designing and modeling a database management system to aid physicians and staff in the process of monitoring and analyzing patient cardiovascular and respiratory data in a typical hospital intensive care unit (ICU). This example application is based on work in critical care data analysis performed by the first author as part of the Ph.D. dissertation requirement at the University of Pennsylvania. The critical data needs of ICU staff are analyzed and a client‐server based database processing system is presented which is robust enough to sustain the data recording needs of 20 patients within the ICU with sufficient bandwidth to permit concurrent data retrieval on patients.
2.5.4 How Maturity Modeling Saved My Softball Team
Authors: Armstrong James R
Published: November 2014

The general acceptance and success of the Software CMM has led to a proliferation of copycat models. There are reportedly about four dozen in some stage of creation. Systems engineering is now deeply involved in this movement. These models can have great benefit to a systems engineering program. However, there is also risk of overemphasis on the institutionalization of processes rather than the value or effectiveness of the effort. This paper looks at the traps one can fall into and how to avoid them.
3.5.3 A Device to Measure Systems Engineering Process Maturity, Effectiveness and Product Quality
Authors: Topf Philip A. , Bellagamba Laurence
Published: November 2014

This paper describes a device to enable project teams to measure how well they are performing systems engineering with respect to both process maturity and effectiveness and to determine the most important process areas to improve. The development and rationale for the systems assessment device and its application at the Rockwell Collins Avionics & Communications Division is described. Key features used to implement the device and to report project findings are illustrated. Lessons learned from application to 27 projects are reported.
4.5.1 An Application of the Analytic Hierarchy Process to Systems Engineering and Project Management
Authors: Fisher Gerard H.
Published: November 2014

Declining federal budgets and pressures from other companies are causing an increase in the competition for a decreasing number of government contracts. The world is exploding with new applications for desktop workstations, even in the military environment. The information technology field emerged with little discipline in either hardware or software development. Improvement was encouraged through the introduction of government quality initiatives and a 1995 U.S. congressional mandate limiting awards of new government contracts to those companies with a record of good past performance. Poor performance on a single contract can take a company out of competition for up to five years! This adds urgency to improving a company's performance on existing contracts.

To ensure customer satisfaction, high quality products, and a profitable relationship, a company needs to make an early identification of potential problems and take corrective actions before they impact the customer. To this end, the author developed an Analytic Hierarchy Process (AHP) model which identifies project problems early enough to take corrective action. AHP permits multiattribute evaluation of economic data, other numeric factors and subjective factors and yields a single figure of merit.

This project applied the systems engineering process to the development and implementation of this AHP model. The model synthesized the expert knowledge of five experienced systems engineers and project managers to develop the weighting of the various elements of the model. The model was built to use the existing executive information system being used by a moderately‐sized corporation's executive officers and is easily transferable to other organizations. It is a new way to interpret the data. The results, based on nine months of data collection and analysis for 152 projects, indicate that project performance can be predicted based on current data collected.
4.5.3 A Comparison Study in Software Requirements Negotiation
Authors: Egyed Alexander , Boehm Barry
Published: November 2014

In a period of two years, two rather independent experiments were conducted at the University of Southern California. In 1995, 23 three‐person teams negotiated the requirements for a hypothetical library system. Then in 1996, 14 six‐person teams negotiated the requirements for real multimedia related library systems.

A number of hypotheses were created to test how real software projects differ from hypothetical ones. Other hypotheses address differences in uniformity and repeatability.

The results indicate that repeatability in 1996 was even harder to achieve then in 1995 (Egyed‐Boehm, 1996). Nevertheless, this paper presents some surprising commonalties between both years that indicate some areas of uniformity.

In both years, the same overall development process (spiral model) was followed, the same negotiation tools (WinWin System) were used, and the same people were doing the analysis of the findings. Thus, the comparison is less blurred by fundamental differences like terminology, process, etc.
5.5.1 Re‐engineering the Prime Contract Office
Authors: Mawby Dave , Brooks Barry
Published: November 2014

Concurrent engineering (CE) is reasonably well understood in a product design and build environment and can yield significant benefits in terms of shorter lead time, lower costs and reduced rework.

Large complex projects typically use some form of prime contract office (PCO) to manage and coordinate the delivery of a product/project against a set of customer requirements. This PCO environment is characterised by the management of multiple subcontractors through the disciplines of systems engineering (SE) and project management. A traditional SE approach (as typified by the waterfall diagram) tends to imply sequential activities rather than the concurrency associated with design/build activities. So, does the more complex environment of a PCO still offer opportunities for significant improvements from CE?

Evidence suggests that these improvements can be made in the PCO environment. This paper demonstrates how the ‘process’, ‘people’ and 'systems' changes that deliver CE can be applied in the PCO context and outlines a framework for successful PCO operation.
5.6.1 The Aerospace Corporation's Concept Design Center
Authors: Aguilar Joseph A. , Dawdy Andrew B. , Law Glenn W.
Published: November 2014

The Concept Design Center (CDC) developed by The Aerospace Corporation has enhanced support to its customers by providing a process for bringing together the conceptual design capabilities and experts throughout The Aerospace Corporation. The members meet as a group on an as‐needed basis in a computer laboratory to create and evaluate conceptual designs in a synergistic and concurrent manner.

The CDC consists of a number of teams, each of which focuses on a different segment of the mission. This paper will focus on the general characteristics of the CDC and on the Space Segment Team (SST) whose primary function is the conceptual design of the spacecraft.
7.6. Implementing An Acquisition Information Systems Architecture
Authors: Gopalakrishna Srikumar V , Little Patrick
Published: November 2014

Upper level management increasingly find the need to align any development efforts with business needs, organizational mission, goals and strategies. While there is an increased demand for greater value from the acquisition programs at reduced costs, there are limited resources to achieve this goal. Improved program management of IT is key to increasing acquisition program effectiveness and reducing costs. Most organizations today find an immediate need for an enterprise wide architecture framework that describes work processes, information flows, information technology (IT) and standards to meet its mission‐critical acquisition programs.

While many information architecture models such as the Zachman framework “(Zachman 1987, 1992)” for information systems architecture and the three‐schema architecture exist in industry, none have gained sufficient acceptance to be considered a standard.

The Acquisition Information Systems Architecture (AISA) was developed to assist our clients, especially those in the Government, comply with legislative and executive agency guidance and to facilitate a framework that guides towards understanding the present and helps plan a migration strategy to a proposed architecture.
7.8. An Integrated Methodology for Developing Interface Documentation (A Method to Maximize Information Reuse)
Authors: Rhoads Russell P. , Harrison Larry
Published: November 2014

This paper addresses the complexity of updating and maintaining interface documentation in a document driven world. This process integrates all activities both vertically and horizontally in order to produce a low maintenance cost set of consistent documentation. The process uses a peel the onion methodology or cookbook approach to interface development. Start with an interface and what comprises it and work down.

What are the “Peel the Onion” Interface Development process benefits?

Maximizes the reuse of information

Optimizes time spent in interface development

A logical process flow for the development of an interface

Ensures consistency throughout the interface specifications and Interface Control Documents

Integrates behavior with requirements

Full traceability of behavior to requirements

Provides a mechanism for simulation development

Behavioral information becomes integral part of specification.

Using this methodology as the basis of behavioral, simulation and documentation saves time, reduces cost and shortens schedule. The results of this methodology are that significant cost savings can be realized by maximizing information reuse for all interfaces.
7.16. Successful Development of Commercial Infrastructure Projects with Systems Engineering
Authors: Rochecouste Hervé
Published: November 2014

As the International Council On Systems Engineering (INCOSE) internationalises its mission, there is a need to address the advancement of the Systems Engineering practice in all environments where improvement opportunities are achievable. This paper is a bilingual English/French analysis of the application of Systems Engineering disciplines for commercial infrastructure systems development. The analysis addresses areas where Systems Engineering Science can be translated from a military context to assist sister projects on the commercial side of the industry. The paper also encourages INCOSE to consider the external side of its mission, and to find a language that will assist those who need to know, instead of internally preaching to those who already know.

SOMMAIRE

L'apparition du Conseil International de l'Ingénierie des Systèmes (INCOSE) sur la scène internationale permet de promouvoir les avancées de l'Ingénierie des Systèmes dans tous les domaines où une amélioration est souhaitable. Cet exposé est une analyse bilingue Français/Anglais de l'application de l'Ingénierie des Systèmes au développement des systèmes d'infrastructures civiles. L'analyse porte sur les domaines où la Science de l'Ingénierie des Systèmes peut être transposée du contexte militaire vers les projets civils. L'exposé encourage aussi INCOSE à extérioriser sa mission, et à trouver un langage pour aider ceux qui sont encore dans l'inconnu, plutôt que les experts en la matière.