Handbook of Systems Engineering and Management

Andrew P. Sage, William B. Rouse

• Publisher: Wiley-Interscience
• Year: 2011
• ISBN:
  9781118210000
• Edition: 2
• Topic: Tecnologia e ingegneria
• Subtopic: Ingegneria elettronica e telecomunicazioni

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.

1

Systems Engineering Life Cycles: Life Cycles for Research, Development, Test, and Evaluation; Acquisition; and Planning and Marketing

F. G. PATTERSON, JR.

1.1 INTRODUCTION

In this chapter we discuss a number of process models, which we also refer to as life cycles. In so doing, we discuss what a life cycle is with respect to our concepts of systems engineering, systems thinking, and the systems approach. As engineers, we ask “What is a life cycle good for?” and “How does it work?” As students, we are constantly looking for fundamental principles and models with which to structure an understanding of our subject (Bruner, 1960). Thus, a study of life-cycle models is an appropriate way to begin an investigation of systems engineering.

Our understanding of life cycles is based on our understanding of systems engineering or the systems engineering approach. Johnson et al. (1967) define a system as “an organized or complex whole; an assemblage or combination of things or parts forming a complex or unitary whole ... more precisely, an array of components designed to accomplish a particular objective according to plan.” An unorganized collection of parts has no purpose. As pointed out as early as in the writings of Aristotle (Ogle, 1941), it is exactly the identification of purpose with the organization of components that defines the approach that we refer to as systems engineering.

Ackoff (1981) uses the term “systems thinking” to describe a means for understanding an entity in terms of its purpose. He formulates the concept of systems thinking as three steps:

1. Identify a containing whole (system), of which the thing to be explained is a part.

2. Explain the behavior or properties of the containing whole.

3. Explain the behavior or properties of the thing to be explained in terms of its role(s) or function(s) within its containing whole.

Strategic planning is purposeful, goal oriented, and goal setting. Systems engineering is the analysis and synthesis of parts, with an eye toward the goal set by strategic planning. Focusing on the problem is analysis, or taking the problem apart to identify and understand the pieces with which to do synthesis.

When we apply Ackoff’s formulation of the systems approach to explain systems engineering life cycles, we first identify the containing whole, and we find that life cycles are attributes of processes, processes are elements of enterprises, and enterprises are actions of organizations. A life cycle is an application of the systems approach for the purpose of understanding and implementing processes. Every process has a life cycle. A process is a collection of one or more actions whose purpose is to accomplish a goal. In a systems engineering organization, this goal contributes to the fulfillment of a strategic plan. If we define a process very generally as a strict partial ordering in time of the strategically important activities of the enterprise, then we can regard a set of processes that includes all such activities of the enterprise in some process as a partitioning of the enterprise. To be interesting, a process should have at least one input and at least one output, and each activity in a process containing more than one activity should either depend on or be dependent on some other activity in the same process.

A process is an element of an enterprise, and an enterprise is itself a process. Every enterprise (process) may be approached as a system (Thome, 1993) and has a life cycle. Using a basic enterprise model due to Sage (1995), a process will be one of three basic types: system acquisition or production; research, development, test, and evaluation (RDT&E); or planning and marketing.

For a number of reasons, many of which relate to the systems engineering organization, it is useful to regard a process as an ordered collection of phases that, when taken together, produce a desired result. We refer to this ordered collection of phases as a process life cycle. Moreover, it is possible and desirable to identify life cycles for each of the three basic classes of processes. Thus, we may speak of a system production or system acquisition life cycle, an RDT&E life cycle, and a planning and marketing life cycle.

An enterprise is a collection of one or more processes undertaken by an organization to achieve a goal. An organization may have one or more enterprises. Every enterprise also has an organization, whose purpose is closely tied to the enterprise. Indeed, from the standpoint of purpose, the enterprise and the organization are identical, since each is an element of the other. Thus, to understand the purpose of the systems engineering life cycle, it is reasonable to consider it part of an organization and to examine it in that role.

Life cycles are both descriptive and prescriptive. In our study of systems engineering life cycles, it is important to abstract and examine life-cycle models not only for their simplicity for describing processes, but also for their prescriptive applicability to the organization of an enterprise. Bass and Stogdill (1990), in a major work on leadership, attribute to Deming the idea that managers need to know whether the organizational system in which they are involved is stable and predictable. A well-defined systems engineering life-cycle model that is imposed on the system from the beginning can give the maturity derived from lessons learned in using the time-tested model, thus adding an important element of stability to the organizational structure. Bass and Stogdill (1990) also cite the need for strong leadership in an organization’s early, formative period.¹ This can be related to the idea of the relatively strong need for a predefined systems engineering life cycle in early, immature stages of the organization, where “strong need” equates to strong leadership requirements. Leadership and structure can help an organization to avoid many problems, by eliminating several sources of conflict. For example, Bradford et al. (1980) enumerate three of the most common group problems, each of which may be reduced by strong leadership and well-defined structure:

1. Conflict or fight

2. Apathy and nonparticipation

3. Inadequate decision making

Burns (1978) associates both power and leadership with purpose:

Leadership over human beings is exercised when persons with certain motives and purposes mobilize, in competition or conflict with others, institutional, political, psychological, and other resources so as to arouse, engage, and satisfy the motives of followers. This is done in order to realize goals mutually held by both leaders and followers.

Stogdill (1966), describing the classic view of the relationship of purpose to organizational structure, writes: “One of the most stable and enduring characteristics of organization, purpose serves as a criterion or anchorage in terms of which a structure of positions is differentiated and a program of operations is designed.” Stogdill models the organization as an interbehavioral system in three dimensions:² interpersonnel, structure, and operations, shown in Figure 1.1.

The operations dimension, the third dimension of Stogdill’s model, is concerned with processes, including business processes that both describe and determine the enterprise activities of the organization. In introducing this third axis, Stogdill notes that the operations side of the model will determine to a large degree the structural and interpersonnel aspects of his model. Thus, it may be argued that operations should lead, rather than follow, the elaboration of the other dimensions. We may introduce the systems approach that views a process as a synthesis of organizational elements to achieve a purpose. By introducing processes, as represented by their life-cycle models, we can purposefully influence the formation of the organization in all of its dimensions.

Stogdill points out that classic organizational theory is concerned mostly with the subdivision of work and with the differentiation of responsibility and authority. It constitutes an empirical and logical analysis of these aspects of organizations that has proved to be highly effective as a template or set of principles for structuring new organizations. With adequate domain knowledge, including knowledge of the nature, technology, size, and complexity of the tasks to be achieved, it is possible to create positions and to specify their structure, function, and status interrelationships; design communication channels; and chart the flow of operations (processes) necessary to perform the tasks. Training of existing personnel or hiring of new personnel to fill the positions is accomplished as a next step.

Figure 1.1 An organizational model by Stogdill.

Life cycles are tools of management that allow the organization of enterprise activities around a purpose. When an organization undertakes an enterprise, members need to structure themselves according to their goals. Organizations establish themselves around processes according to some partition of the enterprise.³ Their strategic plan is much enhanced by introducing a life-cycle model with proven success for the domain. An ad hoc organization will occur—this is the message of Stogdill—if not templated, especially if the organization is involved in an enterprise with which it is unfamiliar. Introducing the template saves much time and helps to assure success. Galbraith and Nathanson (1978) carry on the tradition of Chandler (1962) with their claim that “effective financial performance is obtained by the achievement of congruence between strategy, structure, processes, rewards, and people.” Thus, in terms of Stogdill’s model, the development of the operations side of the model can be enhanced by injecting a life cycle (or set of process life cycles) with proven effect in every aspect of the organization.

Now that we have identified the systems engineering organization as the whole that embodies corporate purpose and have identified many of the dynamic forces within the organization, we can continue our application of systems thinking by focusing on overall behavior. Life cycles model organizational behavior. Behavior is characterized by products, which may be organized into phases for manageability. Each phase is usually characterized by one or more major products emerging from the organization during that phase. In Figure 1.2, three classic views of the system life cycle are depicted. At the lowest level of management, each phase of the life cycle terminates with completion of one or more major products, shown as blackened rectangles. Many intermediate products may be identified that are important to product-level management, not because they are marketable products, but because they represent components of the finished product, or checkpoints, that are associated with progress and productivity, sometimes referred to as earned value. The intermediate products are also shown as visible to the lowest level of management. This level of the organization is responsible for ensuring the quality of the product through product inspection, measurement of partial products at checkpointed intervals, and other means that require all product details to be visible.

Figure 1.2 Management views of life-cycle products by life-cycle phases.

Middle management typically has much less responsibility, visibility, and cognizance relative to intermediate products than product-level management. In general, the focus of middle management is on process rather than product. This is depicted in Figure 1.2 by reducing the number of intermediate products shown to middle management to those deemed to be important for assessing process quality, and through this product quality, shown as rectangles shaded in gray. Thus, middle management is concerned with integrating product-level resources into a high-quality process. At the upper management level, the concern is with integrating process to achieve an organizational goal, a strategic purpose. Thus, upper management requires even less visibility into intermediate products, perhaps none at all. Instead, the focus is on the coordination and integration of production and acquisition, RDT&E, and planning and marketing life cycles.

1.2 CLASSIFICATION OF ORGANIZATIONAL PROCESSES

Drucker (1974) references several traditional methods of classifying and grouping activities in organizations. From a systems engineering point of view, most are analytic, in that they tend to direct attention inward to the skills required to accomplish tasks by grouping like skills together. An outward-looking, synthetic approach, that Drucker clearly finds to be more useful, results from grouping activities by their type of contribution to the organization. He defines four major groups:

1. Result-producing activities

2. Support activities

3. Hygiene and housekeeping activities

4. Top-management activity

Of Drucker’s four categories, only result-producing activities have nontrivial life cycles. The other three types are ongoing, organic elements of the organization, whose activities are necessary, but whose efficacy cannot be measured by their contribution to corporate revenue.

Drucker identifies three subclassifications of result-producing activities:

(a) Those that directly generate revenue

(b) Those that do not directly generate revenue but are still fundamentally related to the results of the enterprise

(c) Information activities that feed the corporate appetite for innovation

Each one of Drucker’s categories corresponds to a basic systems engineering process type identified by Sage (1992a), each with a life cycle that we will examine in detail. Respectively, we will discuss the following:

• The planning and marketing life cycle
• The acquisition or production life cycle
• The RDT&E life cycle

With respect to each life-cycle type, it is necessary to recognize, analyze, and synthesize a response to the market, which may be external or internal to the organization.

For example, one high-level representation due to Sage (1992a) of a generic systems engineering life cycle is a three-phase model: definition, development, and deployment (DDD). Each phase can be further described using recognize, analyze, and synthesize (RAS) to categorize activities contained in the phase. Activities and products can be organized in a matrix representation as suggested by Figure 1.3.

The DDD model is itself a prime example of RAS. System definition is essentially a recognition (R) activity during which requirements are recognized; development is an analysis (A) activity in which requirements, and alternatives for their realization, are considered, analyzed, and developed; and deployment is a synthesis (S) step, in that the results of the development phase are purposefully integrated into an operational system. RAS is recursive in that each phase can be considered to be a stand-alone process, with inputs and outputs. Each phase may then be further analyzed using RAS. For example, the definition phase of a generic acquisition process recognizes stakeholder and environmental needs and other constraints using such tools as requirements elicitation and classification. The analysis subphase analyzes and, as necessary, prototypes requirements to develop a requirements list. The synthesis subphase transforms the finished product of the analysis subphase into a specification. We can recursively apply RAS to “requirements elicitation and classification,” since it is a process with an input that needs to be recognized and an output that must be synthesized based on an analysis step. The DDD model can also be referred to as formulate, analyze, and interpret (FAI) (Sage, 1992a). DDD, FAI, and RAS are congruent to one another.

Figure 1.3 Abstract matrix representation of a generic process.

Figure 1.4 Narrowing the universe of possible products.

The three basic systems engineering life cycles of Sage can be seen as three filters through which a product concept must pass to be deployed successfully by an organization (Fig. 1.4). Each successive filter subsets the universe of possibilities based on both internal and external factors.

In the RDT&E cycle, the feasibility of ideas is measured by the standards of existing technology, constrained only by the goals of the organization. These goals are normally more liberating than limiting, since the organization that is focused on a goal will in general be better endowed, in terms of its technology and its organization, and thus better positioned than competitors to create successful products. From the standpoint of the acquisition or production life cycle, the view is inward toward the capabilities of the organization. ...