30079_26b.pdf

and procedurally rational behavior. Among the limits to rationality are the fact that we can formulate,

analyze, and interpret only a restricted amount of information; can devote only a limited amount of

time to decision-making; and can become involved in many more activities than we can effectively

consider and cope with simultaneously. We must therefore necessarily focus attention only on a

portion of the major competing concerns. The direct effect of these is the presence of cognitive bias

in information acquisition and processing and the use of cognitive heuristics for evaluation of

alternatives.

Although in many cases these cognitive heuristics will be flawed, this is not necessarily so. One

of the hoped-for results of the use of systems engineering approaches is the development of effective

and efficient heuristics for enhanced judgment and choice through effective decision support

systems. 3 0

There are many cognitive biases prevalent in most information-acquisition activities. The use of

cognitive heuristics and decision rules is also prevalent and necessary to enable us to cope with the

many demands on our time. One such heuristic is satisfying or searching for a solution that is "good

enough." This may be quite appropriate if the stakes are small. In general, the quality of cognitive

heuristics will be task-dependent, and often the use of heuristics for evaluation will be both reasonable

and appropriate. Rational decision-making requires time, skill, wisdom, and other resources. It must,

therefore, be reserved for the more important decisions. A goal of systems engineering is to enhance

information acquisition, processing, and evaluation so that efficient and effective use of information

is made in a process that is appropriate to the cognitive styles and time constraints of management.

26.5 SYSTEMDESIGN

This section discusses several topics relevant to the design and evaluation of systems. In order to

develop our design methodology, we first discuss the purpose and objectives of systems engineering

and systems design. Development of performance objectives for quality systems is important, since

evaluation of the logical soundness and performance of a system can be determined by measuring

achievement of these objectives with and without the system. A discussion of general objectives for

quality system design is followed by a presentation of a five-phase design methodology for system

design. The section continues with leadership and training requirements for use of the resulting system

and the impact of these requirements upon design considerations. While it is doubtless true that not

every design process should, could, or would precisely follow each component in the detailed phases

outlined here, we feel that this approach to systems design is sufficiently robust and generic that it

can be used as a normative model of the design process and as a guide to the structuring and

implementation of appropriate systems evaluation practices.

26.5.1 The Purposes of Systems Design

Contemporary issues that may result in the need for systems design are invariably complex. They

typically involve a number of competing concerns, contain much uncertainty, and require expertise

from a number of disparate disciplines for resolution. Thus, it is not surprising that intuitive and

affective judgments, often based on incomplete data, form the usual basis used for contemporary

design and associated choice-making. At the other extreme of the cognitive inquiry scale are the

highly analytical, theoretical, and experimental approaches of the mathematical, physical, and engi-

neering sciences. When intuitive judgment is skill-based, it is generally effective and appropriate.

One of the major challenges in system design engineering is to develop processes that are appropriate

for a variety of process users, some of whom may approach the design issue from a skill-based

perspective, some from a rule-based perspective, and some from a knowledge-based perspective.

A central purpose of systems engineering and management is to incorporate appropriate methods

and metrics into a methodology for problem solving, or a systems engineering process or life cycle,

such that, when it is associated with human judgment through systems management, it results in a

high-quality systems design procedure. By high-quality design, we mean one that will, with high

probability, produce a system that is effective and efficient.

A systems design procedure must be specifically related to the operational environment for which

the final system is intended. Control group testing and evaluation may serve many useful purposes

with respect to determination of many aspects of algorithmic and behavioral efficacy of a system.

Ultimate effectiveness involves user acceptability of the resulting system, and evaluation of this

process effectiveness will often involve testing and evaluation in the environment, or at least a closely

simulated model of the environment, in which the system would be potentially deployed.

The potential benefits of systems engineering approaches to design can be interpreted as attributes

or criteria for evaluation of the design approach itself. Achievement of many of these attributes may

often not be experimentally measured except by inference, anecdotal, or testimonial and case study

evidence taken in the operational environment for which the system is designed. Explicit evaluation

of attribute achievement is a very important part of the overall systemic design process. This section

describes the following:

1. A methodological framework for the design of systems, such as planning and decision support

systems

2. An evaluation methodology that may be incorporated with or used independently of the design

framework

A number of characteristics of effective systems efforts can be identified. These form the basis for

determining the attributes of systems and systemic design procedures. Some of these attributes will

be more important for a given environment than others. Effective design must typically include an

operational evaluation component that will consider the strong interaction between the system and

the situational issues that led to the systems design requirement. This operational evaluation is needed

in order to determine whether a product system or a service consisting of humans and machines

1. Is logically sound

2. Is matched to the operational and organizational situation and environment extant

3. Supports a variety of cognitive skills, styles, and knowledge of the humans who must use

the system

4. Assists users of the system to develop and use their own cognitive skills, styles, and

knowledge

5. Is sufficiently flexible to allow use and adaptation by users with differing cognitive skills,

styles, and knowledge

6. Encourages more effective solution of unstructured and unfamiliar issues, allowing the ap-

plication of job-specific experiences in a way compatible with various acceptability constraints

7. Promotes effective long-term management

It is certainly possible that the product, or system, that results from a systems engineering effort may

be used as a process or life cycle in some other application. Thus, what we have to say here refers

both to the design of products and to the design of processes.

26.5.2 Operational Environments and Decision Situation Models

In order to develop robust scenarios of planning and design situations in various operational envi-

ronments, and specific instruments for evaluation, we first identify a mathematical and situational

taxonomy of

• Algorithmic constructs used in systemic design

• Performance objectives for quality design

• Operational environments for design

One of the initial goals in systems design engineering is to obtain the conceptual specifications for

a product such that development of the system will be based on customer or client information,

objectives, and existing situations and needs. An aid to the process of design should assist in or

support the evaluation of alternatives relative to some criteria. It is generally necessary that design

information be described in ways that lead to effective structuring of the design problem. Of equal

importance is the need to be aware of the role of the affective in design tasks such as to support

different cognitive styles and needs, which vary from formal knowledge-based to rule-based to skill-

based behavior. 3 1 We desire to design efficient and effective physical systems, problem-solving service

systems, and interfaces between the two. This section is concerned with each of these.

Not all of the performance objectives for quality systems engineering will be, or need be, fully

attained in all design instances, but it is generally true that the quality of a system or of a systems

design process necessarily improves as more and more of these objectives are attained. Measures of

quality of the resulting system, and therefore systems design process quality, may be obtained by

assessing the degree of achievement of these performance criteria by the resulting system, generally

in an operational environment. In this way, an evaluation of the effectiveness of a design decision

support system may be conducted.

A taxonomy based on operational environments is necessary to describe particular situation mod-

els through which design decision support may be achieved. We are able to describe a large number

of situations using elements or features of the three-component taxonomy described earlier. With

these, we are able to evolve test instruments to establish quantitative and qualitative evaluations of a

design support system within an operational environment. The structural and functional properties of

such a system, or of the design process itself, must be described in order that a purposeful evaluation

can be accomplished. This purposeful evaluation of a systemic process is obtained by embedding the

process into specific operational planning, design, or decision situations. Thus, an evaluation effort

also allows iteration and feedback to ultimately improve the overall systems design process. The

evaluation methodology to be described is useful, therefore, as a part or phase of the design process.

Also, it is useful, in and of itself, to evaluate and prioritize a set of systemic aids for planning, design,

and decision support. It is also useful for evaluation of resulting system designs and operational

systems providing a methodological framework both for the design and evaluation of physical systems

and for systems that assist in the planning and design of systems.

26.5.3 The Development of Aids for the Systems Design Process

This section describes five important phases in the development of systems and systemic aids for the

design process. These phases serve as a guide not only for the sound design and development of

systems and systemic aids for design decision support, but for their evaluation and ultimate opera-

tional deployment as well.

• Requirements specification

• Preliminary conceptual design

• Detailed design, testing, and implementation

• Evaluation

• Operational deployment

These five phases are applicable to design in general. Although the five phases will be described as

if they are to be sequenced in a chronological fashion, sound design practice will generally necessitate

iteration and feedback from a given phase to earlier phases.

Requirements Specification Phase

The requirements specification phase has as its goal the detailed definition of those needs, activities,

and objectives to be fulfilled or achieved by the system or process that is to result from the system

design effort. Furthermore, the effort in this phase should result in a description of preliminary

conceptual design considerations appropriate for the next phase. This must be accomplished in order

to translate operational deployment needs, activities, and objectives into requirements specifications

if, for example, that is the phase of the systems engineering design effort under consideration.

Among the many objectives of the requirements specifications phase of systems engineering are

the following:

1. To define the problem to be solved, or range of problems to be solved, or issue to be resolved

or ameliorated; including identification of needs, constraints, alterables, and stakeholder

groups associated with operational deployment of the system or the systemic process

2. To determine objectives for operational system or the operational aids for planning, design,

and decision support

3. To obtain commitment for prototype design of a system or systemic process aid from user

group and management

4. To search the literature and seek other expert opinions concerning the approach that is most

appropriate for the particular situation extant

5. To determine the estimated frequency and extent of need for the system or the systemic

process

6. To determine the possible need to modify the system or the systemic process to meet

changed requirements

7. To determine the degree and type of accuracy expected from the system or systemic process

8. To estimate expected effectiveness improvement or benefits due to the use of the system or

systemic process

9. To estimate the expected costs of using the system or systemic process, including design

and development costs, operational costs, and maintenance costs

10. To determine typical planning horizons and periods to which the system or systemic process

must be responsive

11. To determine the extent of tolerable operational environment alteration due to use of the

system or systemic process

12. To determine what particular planning, design, or decision process appears best

13. To determine the most appropriate roles for the system or systemic process to perform within

the context of the planning, design, or decision situation and operational environment under

consideration

14. To estimate potential leadership requirements for use of the final system itself

15. To estimate user group training requirements

16. To estimate the qualifications required of the design team

17. To determine preliminary operational evaluation plans and criteria

18. To determine political acceptability and institutional constraints affecting use of an aided

support process, and those of the system itself

19. To document analytical and behavioral specifications to be satisfied by the support process

and the system itself

20. To determine the extent to which the user group can require changes during and after system

development

21. To determine potential requirements for contractor availability after completion of devel-

opment and operational tests for additional needs determined by the user group, perhaps as

a result of the evaluation effort

22. To develop requirements specifications for prototype design of a support process and the

operational system itself

As a result of this phase, to which the four issue requirements identification approaches of Section

26.4.1 are fully applicable, there should exist a clear definition of typical planning, design, and

decision issues, or problems requiring support, and other requirements specifications, so that it is

possible to make a decision whether to undertake preliminary conceptual design. If the result of this

phase indicates that the user-group or client needs can potentially be satisfied in a cost-effective

manner, by a systemic process aid, for example, then documentation should be prepared concerning

detailed specifications for the next phase, preliminary conceptual design, and initial specifications for

the last three phases of effort. A design team is then selected to implement the next phase of the

system life cycle. This discussion emphasizes the inherently coupled nature of these phases of the

system life cycle and illustrates why it is not reasonable to consider the phases as if they are

uncoupled.

Preliminary Conceptual Design Phase

The preliminary conceptual design phase includes specification of the mathematical and behavioral

content and associated algorithms for the system or process that should ultimately result from the

effort, as well as the possible need for computer support to implement these. The primary goal of

this phase is to develop conceptualization of a prototype system or process in response to the re-

quirements specifications developed in the previous phase. Preliminary design according to the re-

quirements specifications should be achieved. Objectives for preliminary conceptual design include

the following:

1. To search the literature and seek other expert opinion concerning the particular approach to

design and implementation that is likely to be most responsive to requirements specifications

2. To determine the specific analytic algorithms to be implemented by the system or process

3. To determine the specific behavioral situation and operational environment in which the sys-

tem or process is to operate

4. To determine the specific leadership requirements for use of the system in the operational

environment extant

5. To determine specific hardware- and software-implementation requirements, including type

of computer programming language and input devices

6. To determine specific information-input requirements for the system or process

7. To determine the specific type of output and interpretation of the output to be obtained from

the system or process that will result from the design procedure

8. To reevaluate objectives obtained in the previous phase, to provide documentation of minor

changes, and to conduct an extensive re-examination of the effort if major changes are de-

tected that could result in major modification and iteration through requirements specification

or even termination of effort

9. To develop a preliminary conceptual design of a prototype aid that is responsive to the

requirements specification

The expected product of this phase is a set of detailed design and testing specifications that, if

followed, should result in a usable prototype system or process. User-group confidence that an ulti-

mately useful product should result from detailed design should be above some threshold, or the

entire design effort should be redone. Another product of this phase is a refined set of specifications

for the evaluation and operational deployment phases.

If the result of this phase is successful, the detailed design, testing, and implementation phase is

begun. This phase is based on the products of the preliminary conceptual design phase, which should

result in a common understanding among all interested parties about the planning and decision

support design effort concerning the following:

1. Who the user group or responsive stakeholder is

2. The structure of the operational environment in which plans, designs, and decisions are made

3. What constitutes a plan, a design, or a decision

4. How plans, designs, and decisions are made without the process or system and how they will

be made with it

5. What implementation, political acceptability, and institutional constraints affect the use of the

system or process

6. What specific analysis algorithms will be used in the system or process and how these al-

gorithms will be interconnected to form the methodological construction of the system or

process

Detailed Design, Testing, and Implementation Phase

In the third phase of design, a system or process that is presumably useful in the operational envi-

ronment is produced. Among the objectives to be attained in this phase are the following:

1. To obtain and design appropriate physical facilities (physical hardware, computer hardware,

output device, room, etc.)

2. To prepare computer software

3. To document computer software

4. To prepare a user's guide to the system and the process in which the system is embedded

5. To prepare a leader's guide for the system and the associated process

6. To conduct control group or operational (simulated operational) tests of the system and make

minor changes in the aid as a result of the tests

7. To complete detailed design and associated testing of a prototype system based on the results

of the previous phase

8. To implement the prototype system in the operational environment as a process

The products of this phase are detailed guides to use of the system as well as, of course, the prototype

system itself. It is very important that the user's guide and the leader's guide address, at levels

appropriate for the parties interested in the effort, the way in which the performance objectives

identified in Section 26.5.3 are satisfied. The description of system usage and leadership topics should

be addressed in terms of the analytic and behavioral constructs of the system and the resulting process,

as well as in terms of operational environment situation concerns. These concerns include

1. Frequency of occurrence of need for the system or process

2. Time available from recognition of need for a plan, design, or decision to identification of

an appropriate plan, design, or decision

3. Time available from determination of an appropriate plan, design, or decision to implemen-

tation of the plan, design, or decision

4. Value of time

5. Possible interactions with the plans, designs, or decisions of others

6. Information base characteristics

7. Organizational structure

8. Top management support for the resulting system or process

It is especially important that the portion of this phase that concerns implementation of the prototype

system specifically address important questions concerning cognitive style and organizational differ-

ences among parties at interest and institutions associated with the design effort. Stakeholder under-

standing of environmental changes and side effects that will result from use of the system is critical

for ultimate success. This need must be addressed. Evaluation specification and operational deploy-

ment specifications will be further refined as a result of this phase.

Evaluation Phase

Evaluation of the system in accordance with evaluation criteria, determined in the requirements

specification phase and modified in the subsequent two design phases, is accomplished in the fourth

phase of systems development. This evaluation should always be assisted to the extent possible by

all parties at interest to the systems design effort and the resultant systemic process. The evaluation

effort must be adapted to other phases of the design effort so that it becomes an integral functional

part of the overall design process. As noted, evaluation may well be an effort distinct from design

that is used to determine usefulness or appropriateness for specified purposes of one or more previ-

ously designed systems. Among the objectives of system or process evaluation are the following:

1. To identify a methodology for evaluation

2. To identify criteria on which the success of the system or process may be judged

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: