Handbook of Systems Engineering and Management

By Andrew P. Sage and William B. Rouse

The trusted handbook—now in a new edition

This newly revised handbook presents a multifaceted view of systems engineering from process and systems management perspectives. It begins with a comprehensive introduction to the subject and provides a brief overview of the thirty-four chapters that follow. This introductory chapter is intended to serve as a "field guide" that indicates why, when, and how to use the material that follows in the handbook.

Topical coverage includes: systems engineering life cycles and management; risk management; discovering system requirements; configuration management; cost management; total quality management; reliability, maintainability, and availability; concurrent engineering; standards in systems engineering; system architectures; systems design; systems integration; systematic measurements; human supervisory control; managing organizational and individual decision-making; systems reengineering; project planning; human systems integration; information technology and knowledge management; and more.

The handbook is written and edited for systems engineers in industry and government, and to serve as a university reference handbook in systems engineering and management courses. By focusing on systems engineering processes and systems management, the editors have produced a long-lasting handbook that will make a difference in the design of systems of all types that are large in scale and/or scope.

• Language: English
• Publisher: Wiley-Interscience
• Release date: Sep 20, 2011
• ISBN: 9781118210000

Book preview

An Introduction to Systems Engineering and Systems Management

ANDREW P. SAGE and WILLIAM B. ROUSE

This introduction provides a perspective on all of systems engineering and, within that, systems management. This is a major challenge for a single chapter, but our overall purpose is to introduce and provide a summary perspective of the 34 much more detailed chapters that follow in this handbook. Appreciation for the overall process of systems engineering leads naturally to a discussion of the important role for systems management, and the applications of this to realistic contemporary issues of diverse types. Following our introductory comments, we briefly describe the organization of the handbook and then provide some concluding comments. Much of our initial discussion is based on Sage (1992, 1995).

Here, as throughout this handbook, we are concerned with the engineering of systems, or systems engineering. We are also and especially concerned with strategic level systems engineering, or systems management. In this introduction, we begin our effort by first discussing the need for systems engineering, and then providing several definitions of systems engineering. We next present a structure describing the systems engineering process. The result of this is a life-cycle model for systems engineering processes. This model is used to motivate discussion of the functional levels, or considerations, involved in systems engineering efforts:

Systems engineering methods and tools, or technologies

Systems methodology, or process, as a set of phased activities that support efforts to engineer a system (or products and/or services)

Systems management

Figure 1 illustrates the natural hierarchical relationship among these levels. There are many discussions throughout this handbook on systems engineering methods and tools, or technologies. Our primary focus, however, is on systems engineering and management processes, and the technical direction of these efforts. These are intended to result in appropriate products or services, or systems that fulfill client needs. It is a bit cumbersome to continually refer to both products and services, and so we will generally use the term product to refer to a physical product as well as a service. Often we will simply use the term system. The products that are engineered result from an appropriate set of systems engineering methods and tools, or technologies, and an appropriate product line or process effort. These are guided by efforts at systems management as suggested in Figure 1, and as we will discuss often in this handbook.

Figure 1 Conceptual illustration of the three levels of systems engineering.

c00_figure001

SYSTEMS ENGINEERING

Systems engineering is a management technology. Technology is the organization, application, and delivery of scientific and other forms of knowledge for the betterment of a client group. This is a functional definition of technology as a fundamentally human activity. A technology inherently involves a purposeful human extension of one or more natural processes. For example, the stored program digital computer is a technology in that it enhances the ability of a human to perform computations and, in more advanced forms, to process information.

Management involves the interaction of the organization with the environment. A purpose of management is to enable organizations to better cope with their environments so as to achieve purposeful goals and objectives. Consequently, a management technology involves the interaction of technology, organizations that are collections of humans concerned with both the evolvement and use of technologies, and the environment. Figure 2 illustrates these conceptual interactions.

Information is the glue that enables the interactions shown in this figure. Information is a very important quantity that is assumed to be available to the management technology that is systems engineering. This strongly couples notions of systems engineering with those of technical direction or systems management of technological development, rather than exclusively with one or more of the methods of systems engineering, important as they may be for the ultimate success of a systems engineering effort. It suggests the following definition: Systems engineering is the management technology that controls a total system life-cycle process, which involves and which results in the definition, development, and deployment of a system that is of high quality, trustworthy, and cost effective in meeting user needs.

Figure 2 Systems engineering as a management technology.

c00_figure002

This process-oriented notion of systems engineering and systems management is emphasized here.

Figure 3 illustrates our view that systems engineering knowledge comprises the following:

Knowledge principles, which generally represent formal problem-solving approaches to knowledge, generally employed in new situations and/or unstructured environments

Knowledge practices, which represent the accumulated wisdom and experiences that have led to the development of standard operating policies for well-structured problems

Knowledge perspectives, which represent the view that is held relative to future directions and realities in the technological area under consideration

Clearly, one form of knowledge leads to another. Knowledge perspectives may create the incentive for research that leads to the discovery of new knowledge principles. As knowledge principles emerge and are refined, they generally become embedded in the form of knowledge practices. Knowledge practices are generally the major influences of the systems that can be acquired or fielded. These knowledge types interact together as suggested in Figure 3, which illustrates how these knowledge types support one another. In a nonexclusive way, they each support one of the principal life cycles associated with systems engineering. Figure 3 also illustrates a number of feedback loops that are associated with learning to enable continual improvement in performance over time. This supports our view, and a major premise of this handbook, that it is a serious mistake to consider these life cycles in isolation from one another.

Figure 3 Systems engineering knowledge types.

c00_figure003

The use of the term knowledge is very purposeful here. It has long been regarded as essential in systems engineering and management to distinguish between data and information. Information is generally defined as data that are of value for decision making. For information to be successfully used in decision making, it is necessary to associate context and environment with it. The resulting information, as enhanced by context and environment, results in knowledge. Appropriate information management and knowledge management are each necessary for high-quality systems engineering and management.

It is on the basis of the appropriate use of the three knowledge types depicted in Figure 3 that we are able to accomplish the technological system planning and development, and the management system planning and development, that lead to a new product or service. All three types of knowledge are needed. The environment associated with this knowledge needs to be managed, and this is generally what is intended by use of the term knowledge management. Also, the learning that resultsfrom these efforts is very much needed, on both an individual and an organizational basis.

There are three different primary systems engineering life cycles for technology growth and change:

System planning and marketing

Research, development, test, and evaluation (RDT&E)

System acquisition and production

Each of these life cycles is generally needed, and each primarily involves the use of one of the three types of knowledge. We discuss these life cycles briefly here and illustrate how and why they make major but nonexclusive use of knowledge principles, practices, and perspectives. There are a number of needed interactions across these life cycles for one particular realization of a system acquisition life cycle. It is important that efforts across these three major systems engineering life cycles be integrated. There are many illustrations of dramatically successful efforts in RDT&E, but where the overall results represent failure because of lack of consideration of planning or of the ultimate manufacturing needs of a product while it is in RDT&E. There is a major role for systems engineering and management in each of these three life cycles.

It is important when studying any area, new or not, to define it. We have provided one definition of systems engineering thus far. It is primarily a structural definition. The following is a related definition in terms of purpose:

Systems engineering is management technology to assist and support policy making, planning, decision making, and association resource allocation or action deployment.

Systems engineers accomplish this by quantitative and qualitative formulation, analysis, and interpretation of the impacts of action alternatives upon the needs perspectives, the institutional perspectives, and the value perspectives of their clients or customers. Each of these three steps is generally needed in solving systems engineering problems.

Issue formulation is an effort to identify the needs to be fulfilled and the requirements associated with these in terms of objectives to be satisfied, constraints and alterables that affect issue resolution, and generation of potential alternate courses of action.

Issue analysis enables us to determine the impacts of the identified alternative courses of action, including possible refinement of these alternatives.

Issue interpretation enables us to rank the alternatives in terms of need satisfaction and to select one for implementation or additional study.

This particular listing of three systems engineering steps and their descriptions is rather formal. Often, issues are resolved in this way. The steps of formulation, analysis, and interpretation may also be accomplished on an as-if basis by application of a variety of often useful heuristic approaches. These may well be quite appropriate in situations where the problem solver is experientially familiar with the task at hand, and the environment into which the task is embedded, such as to enable development of an appropriate context for issue resolution. This requires information. It also requires knowledge, such as information embedded into experience-based context and environment, and this may lead to very productive heuristic approaches to use of this knowledge.

We can apply these systems engineering steps to a variety of situations that should enable us to develop an appreciation for systems engineering design and problem solving. Generally, there is iteration among the steps, and they follow more or less in the sequence illustrated in Figure 4.

The keywords in this purposeful definition are formulation, analysis, and interpretation. In fact, all of systems engineering can be thought of as consisting of formulation, analysis, and interpretation efforts, together with the systems management and technical direction efforts necessary to bring this about. We may exercise these in a formal sense, or in an as-if or experientially based intuitive sense. These are the stepwise or microlevel components that make up a part of the structural framework for systems methodology.

Figure 4 Conceptual illustration of formulation, analysis, and interpretation as the primary systems engineering steps.

c00_figure004

Figure 5 Conceptual illustration of the three primary systems engineering life-cycle phases.

c00_figure005

In our first definition of systems engineering, we indicated that systems engineers are concerned with the appropriate definition, development, and deployment of the engineered system(s). These aspects compose a set of phases for a systems engineering life cycle, as illustrated in Figure 5. There are many ways to characterize the life-cycle phases of systems engineering processes, and a considerable number of them are described in Chapter 1. Each of these life-cycle models, and those that are outgrowths of them, comprise these three phases in one way or another. For pragmatic reasons, a typical life cycle will generally contain more than three phases, as we shall soon indicate.

IMPORTANCE OF TECHNICAL DIRECTION AND SYSTEMS MANAGEMENT

In order to resolve large-scale and complex problems, or to manage large systems of humans and machines, we must be able to deal with important contemporary issues that involve and require the following:

Many considerations and interrelations

Many different and perhaps controversial value judgments

Knowledge from several disciplines

Knowledge at the levels of principles, practices, and perspectives

Considerations involving planning or definition, development, and deployment

Considerations that cut across the three different life cycles associated with systems planning and marketing, RDT&E, and system acquisition or production

Risks and uncertainties involving future events that are difficult to predict

Fragmented decision-making structures

Human and organizational need and value perspectives, as well as technology perspectives

Resolution of issues at the level of institutions and values as well as the level of symptoms

The professional practice of systems engineering must use a variety of formulation, analysis, and interpretation aids for evolvement of technological systems and management systems. Clients and system developers alike need this support to enable them to cope with multifarious large-scale issues. This support must avoid several potential pitfalls. These include the following 12 deadly systems engineering transgressions:

1. There is an overreliance on a specific analytical method or tool, or a specific technology, that is advocated by a particular group.

2. There is a consideration of perceived problems and issues only at the level of symptoms, and the development and deployment of solutions that only address symptoms.

3. There is a failure to develop and apply appropriate methodologies for issue resolution that will allow (a) identification of major pertinent issue formulation elements; (b) a fully robust analysis of the variety of impacts on stakeholders and the associated interactions among steps of the problem solution procedure; and (c) an interpretation of these impacts in terms of institutional and value considerations.

4. There is a failure to involve the client, to the extent necessary, in the development of problem resolution alternatives and systemic aids to problem resolution.

5. There is a failure to consider the effects of cognitive biases that result from poor information processing heuristics.

6. There is a failure to identify a sufficiently robust set of options or alternative courses of action.

7. There is a failure to make and properly utilize reactive, interactive, and proactive measurements to guide the systems engineering efforts.

8. There is a failure to identify risks associated with the costs and benefits, or effectiveness, of the system to be acquired, produced, or otherwise fielded.

9. There is a failure to properly relate the system that is designed and implemented with the cognitive style and behavioral constraints that impact the users of the system, and an associate failure of not properly designing the system for effective user interaction.

10. There is a failure to consider the implications of strategies adopted in one of the three life cycles (RDT&E, acquisition and production, and planning and marketing) on the other two life cycles.

11. There is a failure to address quality and sustainability issues in a comprehensive manner throughout all phases of the life cycle, especially in terms of reliability, availability, and maintainability.

12. There is a failure to properly integrate a new system together with heritage or legacy systems that already exist and that the new system should support.

All of these may be, and generally are, associated with systems management failures. There needs to be a focus on quality management to avoid these failures and, as has been noted, quality management refers as much or more to the quality of management as it does to the management of quality.

The need for systematic measurement is a very real one for the appropriate practice of systems management. The use of such terms as reactive measurements, interactive measurements, and proactive measurements may seem unusual. We may, however, approach measurements, and management in general, from at least four perspectives.

Inactive. Denotes an organization that does not use metrics or that does not measure at all except perhaps in an intuitive and qualitative manner.

Reactive. Denotes an organization that will perform an outcomes assessment and, after it has detected a problem, or failure, will diagnose the cause of the problem and often will get rid of the symptoms that produce the problem.

Interactive. Denotes an organization that will measure an evolving product as it moves through various phases of the life-cycle process in order to (a) detect problems as soon as they occur; (b) diagnose their causes; and (c) correct the difficulty through recycling, feedback, and retrofit to and through that portion of the life-cycle process in which the problem occurred.

Proactive. Denotes measurements that are designed to predict the potential for errors and synthesis of an appropriate life-cycle process that is sufficiently mature such that the potential for errors is minimized.

Actually, we can also refer to the systems management style of an organization as inactive, reactive, interactive, and/or proactive. All of these perspectives on measurement purpose, and on systems management, are needed. Inactive and reactive measurements are associated with organizations that have a low level of process maturity, a term we will soon define. As one moves to higher and higher levels of process maturity, the lower level forms of measurement purpose become less and less used. In part, this is so because a high level of process maturity results in such appropriate metrics for systems management that final product errors, which can be detected through a reactive measurement approach, tend to occur very infrequently. While reactive measurement approaches are used, they are not at all the dominant focus of measurement. In a very highly mature organization, they might be needed on the rarest of occasions.

In general, we may also approach systems management issues from an inactive, reactive, interactive, or proactive perspective.

Inactive. Denotes an organization that does not worry about issues and that does not take efforts to resolve them. It is a very hopeful perspective, but generally one that will lead to issues becoming serious problems.

Reactive. Denotes an organization that will examine a potential issue only after it has developed into a real problem. It will perform an outcomes assessment and, after it has detected a problem, or failure, will diagnose the cause of the problem and often will get rid of the symptoms that produce the problem.

Interactive. Denotes an organization that will attempt to examine issues while they are in the process of evolution so as to detect problems at the earliest possible time. Issues that may cause difficulties will not only be detected, but efforts at diagnosis and correction will be implemented as soon as they have been detected. This will detect problems as soon as they occur, diagnose their causes, and correct any difficulty through recycling, feedback, and retrofit to and through that portion of the life-cycle process in which the problem occurred. Thus, the term interactive is indeed very appropriate.

Proactive. Denotes an organization that predicts the potential for debilitating issues and that will synthesize an appropriate life-cycle process that is sufficiently mature such that the potential for issues developing is as small as possible.

It should be noted that there is much focus on process in the two more appropriate—interactive and proactive—of these perspectives on organizational effort.

Thus, management of systems engineering processes, which we call systems management, is very necessary for success. There are many examples of systems engineering failures at the level of systems management. Often, one result of these failures is that the purpose, function, and structure of a new system are not identified sufficiently before the system is defined, developed, and deployed. These failures generally cause costly mistakes that could truly have been avoided. Invariably this occurs because either the formulation, the analysis, or the interpretation efforts (or all of them perhaps) are deficient. A major objective of systems engineering, at the strategic level of systems management, is to take proactive measures to avoid these difficulties.

Now that we have introduced some of the flavor of systems engineering, let us turn to some definitions of the professional area of effort we call systems engineering. There are many of these. As we will see, it is possible to define a term from any of several perspectives, or to combine these perspectives. In a great many cases, misunderstandings occur because terms have not been clearly defined.

ADDITIONAL DEFINITIONS OF SYSTEMS ENGINEERING

Concerns associated with the definition, development, and deployment of systems, including product systems and service systems, such that they can be used efficiently and effectively, have always been addressed to some extent. Often, this has been on an implicit and trial-and-error basis. When tool designers or product developers were also tool or product users, which was more often than not the case for the simple tools, machines, and products of the past, the resulting designs were often good initially, or soon evolved into good designs through this trial-and-error effort. When the scale or scope of products and services is large, then it is generally not possible for the engineers of systems to also be the users of systems, and a more formal approach is needed.

The phased efforts of definition, development, and deployment represent the macrolevel structure of a systems engineering framework, as shown in Figure 5. They each need to be employed for each of the three life cycles illustrated in Figure 3. And within each life-cycle phase, there are a number of steps, as illustrated in Figure 6. Thus, we see that our relatively simple description of systems engineering is becoming more and more complex. Figure 7 illustrates how these three steps, three phases, and three life cycles make up a more complete methodological, or structural, or process-oriented view of systems engineering. Even in this relatively simple methodological framework, which is simultaneously incomplete but relatively complex, we have a total of 27 cells of activity. In a much more realistic view of the steps and phases, as would need to be the case in actual systems development, we might well have seven phases and seven steps of effort. This yields a total of 147 cells of activity (i.e., 7 × 7 × 3).

Figure 6 One representation of three systems engineering steps within each of three life-cycle phases.

c00_figure006

Figure 7 Three systems engineering life cycles and phases and steps within each life cycle.

c00_figure007

In the early days, when the designers of a product were also the ultimate end users, things were even simpler than this 27-cell model. Definition, development, and deployment could often be accomplished on a simple trial-and-error basis. When physical tools, machines, and systems become so complex that it is no longer possible to design them by a single individual who might even also be the intended user of the tool, and a design team is necessary, then a host of new problems emerge. This is very much the condition today. To cope with this, a vast number of tools and methods associated with systems engineering have emerged. Through use of these, it has been possible to develop processes for systems engineering that allow us to decompose the engineering of a large system into smaller subsystem engineering issues, engineer the subsystems, and then build the complete system as an integrated collection of these subsystems. This emphasizes the importance, of both the processes used for systems engineering and the systems integration efforts that are needed to assure the complete functioning of the resulting system.

Even so, problems remain. There are many instances of failures due to approaches of this sort, generally because they are incomplete. Just simply connecting together individual subsystems often does not result in a system that performs acceptably, either from a technological efficiency perspective or from an effectiveness perspective. This has led to the realization that systems integration engineering and systems management throughout an entire system life cycle will be necessary. Thus, contemporary efforts in systems engineering contain a focus on the following:

Tools and methods, and technologies for the engineering of systems

Systems methodology for the life-cycle process of definition, development, and deployment that enables appropriate use of these tools, methods, and technologies

Systems management approaches that enable the proper embedding of systems engineering product and process evolution approaches within organizations and environments

In this way, systems engineering and management provide very necessary support to the role of conventional and classic engineering endeavors associated with application of physical and material science principles to accomplish the detailed design and implentation of products in various specialty areas for the betterment of humankind.

Figure 1 illustrated this conceptual relationship among the three levels of systems engineering and also showed each as a necessary facet that the various members of a systems engineering team must apply to define, develop, and deploy an evolving system. Each of these three levels—systems engineering methods and tools, systems engineering processes, and systems management—is necessarily associated with appropriate environments in order to assure an appropriate systems engineering process, including the very necessary client interaction during system definition, development, and deployment. The use of appropriate systems methods and tools as well as systems methodology and systems management constructs enables the engineering of systems for more efficient and effective human interaction.

System management and integration issues are of major importance in determining the effectiveness, efficiency, and overall functionality of system designs. To achieve a high measure of functionality, it must be possible for a system, meaning a product or a service, to be efficiently and effectively produced, used, maintained, retrofitted, and modified throughout all phases of a life cycle. This life cycle begins with conceptualization and identification, then proceeds through specification of system requirements and architectures to the ultimate system installation, operational implementation, or deployment, evaluation, and maintenance throughout a productive lifetime. It is important to note that a system, product, or service that is produced by one organization may well be used as a process, or to support a process, by another organization.

Many studies indicate that there are difficulties associated with the production of functional, reliable, and trustworthy systems of large scale and scope:

It is very difficult to identify the user requirements for a large system.

Large systems are expensive.

System capability is often less than promised and expected.

System deliveries are often quite late.

Large-system cost overruns often occur.

Large-system maintenance is complex and error prone.

Large-system documentation is inappropriate and inadequate.

Large systems are often cumbersome to use and system design for human interaction is generally lacking.

Individual new subsystems often cannot be integrated with legacy or heritage systems.

Large systems often cannot be transitioned to a new environment or modified to meet the evolving needs of clients.

Unanticipated risks and hazards often materialize.

There may be no provision for risk management or crisis management associated with the use of a system.

Large systems often suffer in terms of their reliability, availability, and maintainability.

Large-system performance is often of low quality.

Large systems often do not perform according to specifications.

It is difficult to identify suitable performance metrics for a large system that enable determination of system cost and effectiveness.

There is often poor communication among program management, designers, and customers or program sponsors.

System specifications often do not adequately capture user needs and requirements.

Large systems may not be sustainable over time.

Large systems may be rejected by users as not appropriate to their needs.

These potential difficulties, when they are allowed to develop, can create many problems that are difficult to resolve. Among these are inconsistent, incomplete, and otherwise imperfect system requirements or specifications; system requirements that do not provide for change as user needs evolve over time; and poorly defined management structures for product design and delivery. These lead to delivered products that are difficult to use, that do not solve the intended problem or resolve the stated issue, that operate in an unreliable fashion, that are not maintainable or sustainable, and that, as a result, are not used. Sometimes these failures are so great that operational products and systems are never even fully developed, much less operationally deployed, before plans for the product or system are abruptly canceled.

These same studies generally show that the major problems associated with the production of trustworthy systems often have much more to do with the organization and management of complexity than with direct technological concerns that affect individual subsystems and specific physical science areas. Often the major concern should be more associated with the definition, development, and use of an appropriate process, or product line, for production of a product than it is with actual product implementation itself. Direct attention to the product or service without appropriate attention to the process leads to the fielding of a low-quality and expensive product or service.

A functional definition of systems engineering is also of interest and we provide a simple one here:

Systems engineering is the art and science of creating a product or service, based on phased efforts that involve definition, design, development, production, and maintenance activities. The resulting product or service is functional, reliable, of high quality, and trustworthy and has been developed within cost and time constraints.

There are, of course, other definitions. Two closely related and appropriate definitions are provided by two military standards, MIL-STD-499A and MIL-STD-499B:

Systems engineering is the application of scientific and engineering efforts to

Transform an operational need into a description of system performance parameters and a system configuration through the use of an iterative process of definition, synthesis, analysis, design, test, and evaluation;

Integrate related technical parameters and ensure compatibility of all physical, functional, and program interfaces in a manner that optimizes the total system definition and design;

Integrate reliability, maintainability, safety, survivability, human engineering, and other factors into the total engineering effort to meet cost, schedule, supportability, and technical performance objectives.

Systems engineering is an interdisciplinary, multidisciplinary, and transdisciplinary approach to evolve and verify an integrated and life-cycle-balanced set of system product and process solutions that satisfy the customer’s needs. Systems engineering

Encompasses the scientific and engineering efforts related to the development, manufacturing, verification, deployment, operations, support, and disposal of system products and processes;

Develops needed user training equipment, procedures, and data;

Establishes and maintains configuration management of the system;

Develops work breakdown structures and statements of work, and provides information for management decision making.

These two definitions attempt to combine structural, functional, and purposeful views of systems engineering. While they are not inappropriate, they tend to be more descriptions of the development phase of a systems acquisition life cycle than they are definitions that embrace all three of these phases. Nor do they closely relate to the RDT&E and planning and marketing life cycle. They also tend to assume that the systems engineer is not necessarily, perhaps not at all, the engineer or builder of systems, but more or less their architect only. These definitions carry over to the current versions of these standards as well. We feel there is a need to also stress the integrative role needed across humans, organizations, technologies, and their environments that is essential for effective systems engineering and management. We attempt to stress this knowledge integration role in the 34 chapters to follow in this handbook.

It is generally accepted that we may define things according to either structure, function, or purpose. Often, definitions are incomplete if they do not address structure, function, and purpose. Our discussion of systems engineering, in this introduction and throughout the 34 chapters of this handbook, include structural, purposeful, and functional definitions of systems engineering. These aspects are based on the three definitions we have provided earlier. Table 1 presents these three definitions. Each of these definitions is important and all three are generally needed, as we have noted. In our three-level hierarchy of systems engineering there is generally a nonmutually exclusive correspondence between function and tools, structure and methodology, and purpose and management, as we note in Figure 8.

This figure, unlike Figure 1, illustrates the reality that there is no truly sharp distinction between these three levels of systems engineering. Structural, functional, and purposeful definitions and discussions will necessarily overlap, as these terms are not mutually exclusive. Generally, purpose relates to systems management, structure relates to process, and function relates to product, but the relationships are not at all mutually exclusive. It is of much interest to also note in Figure 8 that a specific process, or product line, results from the interaction of systems management and systems methodology. The product is the result of the use of a number of methods and tools, and systems methodology as it eventuates from use of life-cycle process. Formally, the product itself results from the acquisition process, but a specific acquisition process needs necessarily to be shaped by RDT&E and planning and marketing considerations.

TABLE 1. Definitions of Systems Engineering

Figure 8 Relationships among purpose and systems management, structure and systems methodology, and function and methods, and their product and process results.

c00_figure008

Thus, it is quite correct to view an abstraction of this figure, as shown in Figure 9, in which appropriate systems management results in a process, or product line, and the result of using a systems engineering process is the production of a product. Not explicitly shown here are the interactions across all three levels with the environment. Also not shown in this figure is the fact that there are three life cycles associated with the general systems engineering process: planning and marketing, RDT&E, and acquisition (or manufacturing or production). This does not suggest that the same individuals are associated with all three of these life cycles, nor are they even necessarily associated with all efforts across all phases within a given life cycle. At a sufficiently high level of systems management, there is doubtlessly this overall responsibility. However, and as in the systems engineering military standards just cited, many of the efforts of a given systems engineering team may be associated with the development phase of systems acquisition. Learning over time, such as to enable continuous improvement in quality and effectiveness across all three levels, is, however, necessary and shown in this illustration.

Figure 9 Another view of the hierarchical levels of systems engineering.

c00_figure009

Figure 10 Methods, tools, and technologies for systems engineering products.

c00_figure010

We have illustrated three hierarchical levels for systems engineering in Figure 1 and again in Figure 8. We now expand on this to indicate some of the ingredients at each of these levels. The functional definition, or lowest level, of systems engineering says that we will be concerned with the various tools and techniques and methods, and technologies, that enable us to engineer systems that comprise products or services. Often, these will be systems analysis and operations research tools that enable the formal analysis of systems. They can also include specific product-oriented methods, tools, and technologies, such as illustrated in Figure 10. These could include a variety of computer science and programming tools or methods. They could include modern manufacturing technologies. Strictly speaking, it is more appropriate to refer to these as product-level methods. Then we could also refer to the methods associated with systems methodology, or process methods, and systems management methods. When the term method(s) is used alone and without a modifier, we will generally be referring to product-level methods. The specific nature of the most useful methods and tools will naturally depend greatly on the particular life cycle that is being considered and the particular product, service, or system that is ultimately to be acquired.

The functional definition of systems engineering also says that we will be concerned with a combination of these tools. In systems engineering, we obtain this combination as the result of using systems methodology to engineer an appropriate process. For our purposes, a methodology is an open set of procedures for problem solving or issue resolution. This brings about such important notions as appropriate development life cycles, operational quality assurance issues, and configuration management procedures, which are very important and are discussed in more detail in the various chapters of this handbook. Each of these reflects the structural, architectural, or methodological perspective on systems engineering in the sense that the result of functional or process-oriented efforts is the evolution of the structure or architecture of the system being engineered. Figure 11 illustrates some of the process-based methods associated with systems methodology. How to best bring these about will vary from product to product and across each of the three life cycles leading to that product or service system. We will have more to say about these in later chapters.

Figure 11 Methods, tools, and technologies for systems engineering process supports.

c00_figure011

Finally, the functional definition of systems engineering says that we will accomplish this in a useful and appropriate setting. Systems management provides this useful setting, for evolution of an appropriate process for a specific systems engineering effort. We will use the term systems management to refer to the cognitive strategy and organizational tasks necessary to produce a useful process from the variety of methodologies that are available. There are many drivers of systems management strategy, including organizational culture, the internal strengths and weaknesses of the organization, and the external threats and opportunities that it faces. The result of systems management is an appropriate combination of the methods and tools of systems engineering, including their use in a methodological setting, together with appropriate leadership in managing system process and product development, to ultimately field a system that can be used to resolve issues. There are many interesting issues associated with systems management. Figure 12 illustrates some of the many process-related concerns associated with systems management.

We should note that some of these elements, such as economic analysis and assessment, may appear to be at all levels. At the level of the product or systems methods, we use functional economic analysis. This might be associated with cost control of the evolving product. At the level of systems methodology, we would use structural economic analysis, such as is associated with a work breakdown structure (WBS). Structured economic analysis would have to do with life-cycle cost and effectiveness determination. Finally, at the level of systems management, we use a number of strategic cost management approaches that deal with strategic positioning in terms of process costs and effectiveness trade-offs. These will enable selection of an appropriate development process, including as a special case the decision not to enter a particular market. Thus, economic systems analysis is needed at each of the three systems engineering hierarchical levels. A different form of economic systems analysis and assessment, however, is needed at each of these levels. We need to be concerned with these three levels (management, methodology, method) or the somewhat equivalent levels of systems management, process, and product, across the three life cycles of systems planning and marketing, RDT&E, and system acquisition or production. The particular life cycle in question, as well as the phase of development, will strongly influence the actual approaches that are appropriate for use at each of these levels.

Figure 12 Systems management and associated supports.

c00_figure012

The structural definition of systems engineering tells us that we are concerned with a framework for problem resolution that, from a formal perspective at least, consists of three fundamental steps:

Issue formulation

Issue analysis

Issue interpretation

These are each conducted at each of the life-cycle phases that have been chosen for definition, development, and deployment. Regardless of the way in which the systems engineering life-cycle process is characterized, and regardless of the type of product or system or service that is being designed, all characterizations of systems engineering life cycles will necessarily involve the following:

Formulation of the Problem. The situation or issue at hand is assessed, needs and objectives of a client group are identified, and potentially acceptable alternatives, or options, are identified or generated.

Analysis of the Alternatives. The impacts of the generated options are identified, assessed, and evaluated.

Interpretation and Selection. The options or alternative courses of action are compared by means of an evaluation of the impacts of the alternatives and how these are valued by the client group. The needs and objectives of the client group are necessarily used as a basis for evaluation. The most acceptable alternative is selected for implementation or further study in a subsequent phase of systems engineering effort.

We note these three steps again, because of their great importance in systems engineering. Our model of the steps of the fine structure of the systems process, shown in Figure 4, is based on this conceptualization. As we also indicate later, these three steps can be disaggregated into a number of others.

Each of these steps of systems engineering is accomplished for each of the life-cycle phases. Chapter 24 discusses a number of approaches for issue formulation. Chapters 25, 26, and 27 are generally concerned with issue analysis. Chapters 28 and 29 are concerned with issue interpretation, including decision assessment and planning for action. As we have noted, there are generally three different and major systems engineering life cycles needed to engineer a system. Thus, we may imagine a three-dimensional model of systems engineering that is composed of steps associated with each phase of a life cycle, the phases in the life cycle, and the life cycles that make up the coarse structure of systems engineering. Figure 7 illustrated this across three distinct but interrelated life cycles, for the three steps, and three phases that we have described here. This is one of many possible morphological frameworks for systems engineering.

The words morphology and methodology may be unfamiliar. The word morphology is adapted from biology and means a study of form or structure. It is an important concept and a needed one in both biology and systems engineering. As noted earlier, a methodology is an open set of procedures for problem solving. Consequently, a methodology involves a set of methods, a set of activities, and a set of relations between the methods and the activities. To use a methodology we must have an appropriate set of methods. Generally, these include a variety of qualitative and quantitative approaches from a number of disciplines that are appropriate for the specific product, service, or system to be acquired. Associated with a methodology is a structured framework into which particular methods are associated for resolution of a specific issue. The specific structural framework used for engineering a system is the process or life cycle used to evolve the product under consideration. The RDT&E, acquisition or manufacturing, and planning life cycles are the major ones that result from systems management efforts.

Without question, this is a formal rational model of the way in which these three systems engineering steps—formulation, analysis, and interpretation—are accomplished. Even within this formal framework, there is the need for much iteration from one step back to an earlier step when it is discovered that improvements in the results of an earlier step are needed in order to obtain a quality result at a later step, or phase, of the systems engineering effort. Also, this description does not emphasize the key role of information and knowledge and the determination of requirements for information and knowledge.

Even when these realities are associated with an identified and appropriate morphological framework, they still represent an incomplete view of the way in which people do, could, or should accomplish planning, design, development, or other problemsolving activities. The most that can be argued is that this framework is correct in an as-if manner. One result of a systems management effort is the identification of an appropriate process, or life cycle, to be used to engineer a system. Also involved in systems management are the determination of how best to use this process to engineer a system.

We can also add a third dimension, made up of the three life cycles associated with the systems engineering process, to our framework, as illustrated in Figure 7 and as further illustrated conceptually in Figure 13. The use of this process is intended to result in the engineering of an appropriate system. The choice of a process is affected by systems management concerns. Thus, systems management can be regarded as a driver of the process. The product or service system, process, and systems management are supported by a number of methods, tools, technologies, and measurements, as represented by Figure 14. This representation of systems engineering and management shows systems management as exercising strategic management controls over the three evolving systems engineering processes. The instantiation of these processes results in the systems engineering product. In systems planning and marketing, the product of planning and marketing is a determination of whether RDT&E and/or acquisition of a product or system should be undertaken and in what amounts and configurations. It is for this reason that we portray varying sized pie slices for definition, development, and deployment efforts associated with each of these phases in Figure 13.

Figure 13 Generic representation of the three basic systems engineering life cycles.

c00_figure013

Figure 15 represents an expansion of the planning and marketing effort and illustrates how the efforts in RDT&E and acquisition must necessarily be based on results from planning and marketing if the overall set of processes is to be effective.

In many cases, the proper application of one or more technologies is necessary to ameliorate an existing problem or fulfill an existing need. Technology is a world need, but it must be human- and organization-centered technology. This requires systems engineering and management efforts that result in definition, development, and deployment of a system. However, successful application of technology and successful application of systems engineering to major problem areas must consider each of the three levels at which solution may be sought:

Symptoms

Institutions

Values

Figure 14 A model of systems engineering and management.

c00_figure014

Figure 15 Illustration of interactions across three basic systems engineering life cycles.

c00_figure015

Or we may well be confronted by a technological solution looking for a problem. This is especially the case when we approach problems only at the level of symptoms: unemployment, bad housing, inadequate healthcare delivery, pollution, hunger, and unsustainable economic development in general. A technological fix is found that addresses symptoms only and the resulting solution creates the illusion that the outpouring of huge quantities of moneys to resolve symptoms will actually resolve the fundamental underlying problem. Chapters 17 through 21 concentrate particularly on the need for organizational and human-focused solutions to problems, as contrasted with technological fix solutions.

Attacking problems at the level of institutions would allow the design of new institutions and organizations to make full and effective use of new technologies. This is generally a major improvement on what results when we consider only problem abatement at the level of removal of symptoms. With respect to measurements and management, symptomatic approaches are generally reactive in nature. Measurement and management approaches at the level of institutions are generally interactive and process related.

Also of vital importance is the need to deal with problems at the level of values. Systems engineers and systems managers who are serious about resolving major problems must appreciate the significance of human values and be able to identify basic issues in terms of conflicting values. Furthermore, value elements and systems, as well as institutions and purely technological components, must be utilized in determining useful problem solutions. All of this again illustrates the major need for incorporation of systems management approaches into the development of process and product evolvement efforts. Proactive management and proactive measurements are necessarily value oriented in that they must necessarily be anticipatory. Approaches based on proactivity are generally associated with double loop learning, a concept described in Chapters 13 and 30.

Some necessary ingredients, which must exist in order to engineer large systems, solve large and complex problems, resolve complicated issues, or manage large systems, are associated with the following needs:

We need a way to deal successfully with issues involving many considerations and interrelations, including changes over time.

We need a way to deal successfully with issues in which there are far-reaching and controversial value judgments.

We need a way to deal successfully with issues, the solutions to which require knowledge principles, practices, and perspectives from several disciplines.

We need a way to deal successfully with issues in which future events are difficult to predict.

We need a way to deal successfully with issues in which the environments, external and internal, are difficult to predict.

We need a way to deal successfully with issues in which structural and human institutional and organizational elements are given full consideration.

We need to deal with integrated knowledge management across the diversity of stakeholders and perspectives that are associated with major issues of large scale and scope.

We need to engineer systems that are sustainable.

We believe that systems engineering, through empowered systems management, possesses the necessary characteristics to fulfill these needs. Thus, systems engineering is potentially capable of exposing not only technological perspectives associated with large-scale systems but also needs and value perspectives. Furthermore, it can relate these to knowledge principles, practices, and perspectives such that the result of its application is successful planning and marketing, RDT&E, and acquisition or production of high-quality, trustworthy systems.

Systems engineering efforts are very concerned with technical direction and management of systems definition, development, and deployment. As we have noted, we call this effort systems management. By adopting the management technology of systems engineering and applying it, we become very concerned with making sure that correct systems are designed, and not just that system products are correct according to some potentially ill-conceived notions of what the system should do. Appropriate metrics to enable efficient and effective error prevention and detection at the level of systems management, and at the process and product level, will enhance the production of systems engineering products that are correct in the broadest possible meaning of this term. To ensure that correct systems are produced requires that considerable emphasis be placed on the front end of each of the systems engineering life cycles.

In particular, there needs to be considerable emphasis on the accurate definition of a system, including identification of what it should do and how people should interact with it, before the system is developed and deployed. In turn, this requires emphasis on conformance to system requirements specifications, and the development of standards to ensure compatibility and integratibility of system products. Such areas as documentation and communication are important in all of this. Thus, we see the need for the technical direction and management technology efforts that compose systems engineering, and the strong role for process-related and systems-management-related concerns in this.

LIFE-CYCLE METHODOLOGIES, OR PROCESSES, FOR SYSTEMS ENGINEERING

As we have noted, systems engineering is the creative process through which products, services, or systems that are intended to be responsive to client needs and requirements are conceptualized or specified or defined, and ultimately developed and deployed. There are at least 15 primary assertions implied by this not uncommon definition of systems engineering, and they apply especially to the development of knowledge-intensive systems and software-intensive systems, as well as to more conventional hardware and physical systems.

Systems planning and marketing is the first strategic level effort in systems engineering. It results in the determination of whether or not a given organization should undertake the engineering of a given product or service. It also results in at least a preliminary determination of the amount of effort to be devoted to RDT&E and the amount devoted to actual system acquisition or production.

Creation of an appropriate process or product line for RDT&E and one for acquisition is one result of systems planning and marketing. The initial systems planning and marketing efforts determine the extent to which RDT&E is a need; they also determine the acquisition process characteristics that are most appropriate.

An appropriate planning process leads to efficient and effective RDT&E, and to the actual system acquisition that follows appropriate RDT&E.

The first phase of any systems engineering life-cycle effort results in the identification or definition of specifications for the product or service that is to result from the process.

Systems architecting is a very important endeavor that leads to the conceptual structure of the system to be engineered.

Systems engineering is a creative and process-based effort.

Systems engineering activities are conceptual in nature at the initial phases of effort, for any of the three generic life cycles, and become operational in later phases.

A successful systems engineering product or service must be of high quality and responsive to client needs and requirements.

A successful systems engineering product or service generally results only from use of a successful systems engineering process (or set of processes).

Generally, an appropriate systems engineering acquisition or RDT&E process is the result of successful systems management and appropriate planning and marketing.

Appropriate systems engineering efforts need necessarily be associated with systematic measurements to ensure high-quality information and knowledge as a basis for decision making across the three generic systems engineering life cycles.

Appropriate systems engineering efforts are necessarily attuned to organizational and environmental realities as they affect the client organization or enterprise, the systems engineering organization, and the product implementation organization(s).

Systems engineering is inherently associated with knowledge integration and knowledge management across transdisciplinary boundaries.

Systems engineering efforts must lead to sustainable products and services if they are to have lasting value.

Systems engineering efforts are of necessity interactive. However, they transcend interactivity to include proactivity.

Good systems engineering practice requires that the systems engineer be responsive to each of these 15 ingredients for quality effort. Clearly, not all members of a systems engineering team are responsible for, and participate in, each and every systems engineering activity. Nevertheless, the activities across each of the phases and each of the life cycles must be integrated if the systems engineering effort is to be of high quality.

It is of value to expand on the simple three-phase and three-step model we have used to characterize a framework for systems engineering. Figure 16 illustrates a typical sequence of phases, seven in this case, that would generally be appropriate for a system acquisition and procurement life cycle. Figure 17 illustrates a possible manufacturing life cycle. The particular words associated with the phases in Figures 16 and 17 are not the most appropriate for a systems planning and marketing life cycle or an RDT&E life cycle. However, they could easily be modified to indicate identification of societal needs for a product, and the evolution of a product marketing strategy, such that they are, indeed, appropriate for systems planning and marketing. They also could be modified to more appropriately represent an RDT&E effort.

Figure 16 One of several possible life-cycle models for acquisition in systems engineering.

c00_figure016

Figure 17 A possible life cycle for manufacturing and related efforts.

c00_figure017

In Figure 16, we have identified a phased system engineering life cycle that consists of seven phases:

Requirements and specifications identification

Preliminary conceptual design and system-level functional architecting

Logical design and physical architecture specification

Detailed design of the physical architecture and associated production and testing

Operational implementation of the resulting product or service system in the field

Evaluation and modification

Operational deployment

Figure 18 The steps, phases, and activity levels in systems engineering.

c00_figure018

These life-cycle phases are sequenced in the iterative manner as shown in Figure 16. There are many descriptions of systems engineering life cycles and associated methodologies and frameworks for systems engineering, and we outline only one of them here. Chapter 1 expands a great deal on these ideas.

In general, a simple conceptual model of the overall process, for a single life cycle, may be structured as in Figure 18, which illustrates an effort to accommodate the three steps we have described and the seven phases illustrated here. Systems methodology and the systems engineering process are described in the middle box in this figure, and the representation used for this is a two-dimensional morphological box. In this particular framework, there are 21 activity cells. There should be one or more methods, tools, or technologies associated with each of these activity cells. Choice of an appropriate mix of methods is an important challenge in systems engineering. One of these morphological box frameworks needs to be associated with each of the three life cycles that are associated with an overall systems engineering effort, and this would lead to 63 specific activity cells (21 activity cells for each of the three life cycles). And this is a simplified model of the process!

If we were to restate the steps of the fine structure as seven rather than three, we would obtain a morphological box comprising 49 elements for each life cycle. Figure 19 illustrates a not untypical 49-element morphological box. This is obtained by expanding our three systems engineering steps to a total of seven. These seven steps, but not the seven phases that we associate with them, are essentially those identified by Arthur Hall in his pioneering efforts in systems engineering of 30 years ago. They may be described as follows.

Issue Formulation

Problem definition involves isolating, quantifying, and clarifying the needs that create the issue at hand, and describing that set of environmental factors that constrain alterables for the system to be developed. In addition to identifying needs, we need to identify constraints, those facets that cannot be changed, and alterables, those facets that can be changed.

Value system design involves selection of the set of objectives or goals that guide the search for alternatives. Very importantly, value system design enables determination of the multidimensional attributes or decision criteria for selecting the most appropriate system. These are also known as objectives measures and represent, or may be transformed into, needed metrics for the evaluation of alternative courses of action in terms of their impact on the value system.

Systems synthesis involves searching for, or hypothesizing, a set of alternative courses of action or options. Each alternative must be described in sufficient detail to permit analysis of the impacts of implementation, and subsequent evaluation and interpretation with respect to the objectives. We also need to associate appropriate metrics with each identified alternative, and these may be called alternatives measures.

Figure 19 The phases and steps in one 49-element, two-dimensional systems engineering framework.

c00_figure019

Analysis

Systems analysis involves determining specific impacts or consequences that were specified as relevant by the value system. These impacts may relate to such important concerns as product quality, market, reliability, cost, and effectiveness or benefits. Modeling and simulation approaches are often used in systems analysis.

Refinement of the alternatives refers to adjusting, sometimes by optimizing the system parameters for each alternative in order to meet system