the application of function descriptors to the development of an information system topology

The Application of Function Descriptors to the

Development of an Information System Topology

A type of descriptor, termed a Function Descriptor, is suggested for application to the description and classification of information systems, and for the develop ment of an information system typology. In the exploratory description of 25 systems, a list of 83 Function Descriptors was developed. In a small experiment undertaken, it was Seen that consensual agreement in the for the continuance of the research. application of the Function Descriptors is not simply

achieved. Several suggestions are made for dealing with the difficulties of application, including the classification of information system functions into three types: utilization-level functions, production-level functions, and operation-level functions. The establishment of an Infor- mation System Reference Center is proposed as a basis

E. Burton Swanson Graduate School of Management University of California Los Angeles, CA 90024

0 Introduction

The problem of description and classification is fun- damental to information system design, whether the task involves a large scale document storage and retrieval system, or merely the grouping of parts in an inventory system according to economic reordering criteria.

Interestingly enough, however, very little attention has been given to the problem of describing and classifying information systems themselves. Noting this, as the population of this species continues to explode, it seems reasonable to make some efforts in this direction.

The development of effective methods of information system description and classification will serve several interrelated interests. First, the information systems scientist will be better able to study the phenomena which are his central concern. For example, he or she should find it easier to recognize certain structural similarities and differences between any two systems, given that the relevant characteristics for a comparison have been identified and organized.

Secondly, designers of information systems, in search of those sets of “design features” which best suit their

0 1977 by John h>;y & Sons, Inc.

individual circumstances, should benefit from an organized collection of information system descriptions in which “similar” systems could be identified and referenced. For example, a designer of an on-line data base inquiry system, in search of ideas relative to query- language specification, might be referred to information systems employing query languages in similar situations.

Thirdly, marketers of information system equipment, i.e., hardware and software, would have a vital interest in any set of descriptions in which these resources, or resource requirements, were identified. For example, the producer of a new display terminal might seek to identify the market for the device through an analysis of the resource requirements of various information system types.

Finally, current developments in technology, especially in the area of networking, indicate that users of future information systems will have at their disposal sysrerns of information systems. [Users will be able to access a communication-based system(s) linking various information systems together.] In such situations, either the seeker of information must have the familiarity with individual systems necessary for directing his queries to appropriate sources within a complex, or a “switchboard facility” must be devised to direct the individual on the

Journal of the American Society for Information Science-September 1977 259

basis of its own knowledge of individual systems’ characteristics. It is certain that steps toward the implementa- tion of these “switchboards” will be undertaken, and the effective description and classification of information systems (as sources of information) is clearly a pre- requisite to success in such endeavors.

The work described in this paper was motivated originally by a call from Kunz and Rittel (3) for the development of a typology of information systems, made in recognition of the aforementioned need to clarify the subject of information systems science. The authors included in their call a suggested method for the development of the typology. The method involves (1) the assembly of a set of descriptors of information systems (e.g., Online, Realtime, Centralized Data Base, etc.) and (2) the application of these to the description of actual information systems in such a way that each information system is characterized by the applicability or non-applicability of each descriptor (e.g., a particular information system might be judged to be Online, but nor Realtime, and as nor possessing a Centralized Data Base.) In this manner a descriptor-information system matrix might be developed which would lend itself to theoretical analysis.

The matrix would assume a form in which individual information systems appear as one dimension, and sys tem characteristics (represented by the descriptors) as the other, with binary entries (representing “yes” and “no”) indicating possession or nonpossession of a characteristic by an information system:

Characteristic Descriptors

d l dz d3 ... d , s 1 1 0 1 0 s z 1 1 1 0

Information Systems SJ 0 0 0 1

s ,o 1 0 0

Each matrix entry is equivalent to a basic sentence in predicate logic, and a row of entries is equivalent to a compound sentence constituting a state-description of an information system (9, pp. 226-227).

The matrix would be progressively enlarged and re- fined as additional descriptors and information systems were incorporated. This is termed by Kunz and Rittel a form of “iterative dimensional analysis” (3, p. 54).

In the fall of 1972, a small project to study the development of a typology in this fashion was undertaken at the Studiengruppe fur Systemforschung, Heidelberg, The author was the sole investigator on the project, which spanned a period of almost two years.

The scope of the project was soon narrowed to a study of the applicability of a particular type of

descriptor, the “Function Descriptor,’’ to information system description and classification.

0 The Function Descriptor

In considering the proposed descriptor/information system matrix, an initial problem was identified: specification of criteria for an “admissable descriptor .” In principle, it is possible to admit all manner of descriptors, e.g., Cost More than $100 or Programmed in FORTRAN. But some would surely be of more importance than others.

The question was, what types of descriptors would be the most interesting, the most useful, or the easiest to apply? It was soon seen that many aspects of information system description (e.g., specifying the equipment utilized, identifying the organization employing the system) were relatively straightforward, and while important, were nevertheless not central to the problem of a typology development.

Attention was eventually centered on the problem of describing the “functions performed” by information systems.

A type of descriptor termed a “Function Descriptor” (or “F-Descriptor”) was defined which seemed to lend itself to wide-ranging information system application.

The format for the F-Descriptor was defined as a verb in gerund form,in conjunction with a noun prefur. The noun is the object of the action implied by the verb. Examples: Hypothesis-Testing ; Game-Playing ; Problem- Solving. The choice of this format was based in part on the frequency with which such terms are actually en- countered in the information system literature.

A set of F-Descriptors which seemed to be “good candidates” for application was formulated, each descriptor was given a definition, and the description of information systems documented in the literature began. One of the first systems described was “Telefile,” an online banking system described in Sackman (7). From a set of 30 or so descriptors, the following were judged to apply:

Customer-Servicing Fact-Retrieving Exception-Detecting Performance-Measuring Procedure-Administering Record-Keeping State-Monitoring Status-Reporting

It was argued that Telefile is Customer-Servicing in that it is designed to facilitate normal banking transactions

260 Journal of the American Society for Information Science-September 1977

(account deposits and withdrawals) with the bank’s depositors. Further, that the system is Procedure- Administering in that it is based upon the bank’s pro- cedures for handling routine transactions, and that it is Record-Keeping with respect to these transactions. Telefile was said to be State-Monitoring in that the current state of each customer account is monitored on a realtime basis, and Fact-Retrieving and Status-Report- ing in that a bank teller inquiries into the status of these accounts in the course of completing transactions with the customers. In addition, bank management can also receive online reports summarizing the day’s activity (e.g., in terms of total flow of funds), and hence the system was said to be Performance-Measuring. Lastly, it was argued that Telefile is an Exception-Detecting system inasmuch as a status report on a depositor’s account may reveal conditions (e.g., insufficient funds) which would preclude a particular transaction.

This gives some idea of the judgmental processes involved in applying the F-Descriptors. Noteworthy in these initial descriptions was the absence of descriptors which were highly particular and would serve to clearly distinguish each system from another. Descriptors were sought which had a high degree of generality and could thus identify structural similarities between systems which might, on the surface, appear to be quite different. Thus, for example, Telefile might well have been characterized as Bank-Telling, but was not. This early stratagem, later dropped, made the description task difficult, although it served perhaps to “sharpen” one’s thinking about information systems.

As additional information systems were described, changes to the set of descriptors and their definitions were suggested and the “iterative dimensional analysis” proceded more or less as envisioned by Kunz and Rittel.

0 A Small Experiment”

At the same time the set of Function Descriptors was being compiled, the Studiengruppe was an active participant in the design of an environmental planning information system (termed “UMPLIS ,” for Umweltplanungs- informationssystem) on behalf of the German Federal Ministry of the Interior.?

UMPLIS presented a particularly interesting challenge to a would-be describer. A total of eleven subsystems were identified as making up the system, and the scope of the system’s attention ranged over the entire information domain of environmental problems. As the design

*What is summarized here is discussed in detail in Swanson (11). tThe design proposed is documented in Kunz and Rittel (4).

of the system was elaborated in the summer of 1973, the question of just what the system was supposed to be arose more than once among its codesigners. (This may seem like a question that ought to be resolved at the outset of a system design. In practice, however, the question is rarely laid permanently to rest. Members of a design team seldom possess wholly consistent images of the system.)

While it is beyond the scope of this paper to provide the reader with an extensive description of UMPLIS, a brief introduction should facilitate an understanding of the material to follow. Briefly, UMPLIS is an information retrieval and reference providing system directed toward providing West German citizens and their elected and appointed representatives with information needed for the political resolution of problems in environmental protection and management. A set of nine subsystems specialize in various aspects of information pertinent to environmental problem solving:

2

3

4

5

6

7

8

9

10

Subsystem

environment-related data banks and information services environmental experts

critical environmental variables and their measurement and control environment-related organizational programs and projects environmental models for forecasting and decision making environmental law environmental standards plans for the management of environmental crises and catastrophes environmental impact of products and production processes

Subsystem 1 is defined to serve the “switchboard funo tion” of referring environmental questions to the s u b system(s) among Subsystems 2-9 best equipped to provide assistance. Further, it manages the formulation and addressing of significant environmental issues demanding in-depth study. Finally, a Subsystem 0 is defined to serve the function of managing the continued development of UMPLIS.*

It was decided to conduct a form of experiment. To the list of Function Descriptors assembled in describing

*More detailed description of UMPLIS may be found in Kunz and Rittel (4.5) and Reuter (6).

Journal of the American Society for Information Science-September 1977 26 1

other information systems were added several new descriptors which seemed (to me) applicable to UMPLIS in particular. The idea was then to distribute the list of descriptors and their definitions to the different individuals engaged in designing UMPLIS. Each individual would be asked to evaluate the applicability of each of the descriptors to each of the UMPLIS subsystems. I t was hoped that the following might thereby be accom- plished :

(i) an informal test of the Function Descriptors as a means for describing information systems;

(ii) an evaluation of the descriptor application method as a potential design tool by which an individual may obtain insights into his concep tion of a system;

(iii) an evaluation of the descriptor application method as a means for enabling members of a design team to compare and resolve their vary- ing conceptions of the system.

The experiment was undertaken in August 1973, with the distribution of the necessary description material to a total of 16 individuals who had involved themselves with UMPLIS. Included was a questionnaire form in which the respondents were to indicate the applicability or non-applicability of each of 50 Descrip- tors to each subsystem of UMPLIS. (A total of 550 yes- or-no decisions were thus involved in the 1 1 X S k h o i c e matrix arranged.) Eleven of the distributed questionnaires were returned in a form and within the time constraints permitting analysis.

Inasmuch as I was a participant in the design of UMPLIS, I included myself among the questionnaire respondents, and my own classification decisions thus became part of the experimental data.

An initial step in summarizing the returned data was the computation of a “consensus” judgment in the application of the descriptors to the UMPLIS subsystems.

Each individual questionnaire respondent had been limited to a choice between “yes” or “no” in deciding whether a particular descriptor ought to be associated with a given UMPLIS subsystem. Any number of rules might therefore have been applied to the computation of a consensus judgment, including, for example, “majority rules,” or “2/3 of votes needed to decide.”

It was decided to compute the consensus judgment on the basis of “significant statistical agreement.” The eleven individual judgments as to the application of a descriptor to a subsystem were treated as a series of Bernoulli trials, where pi was the “probability” that a respondent i would judge bbapply” rather than “not apply.” The null hypothesis that pi = 0.5 was formulated, a hypothesis that the descriptor could equally be said

to apply or not apply. The selection of a consensus “yes” or “no” was then made dependent upon the rejection of the null hypothesis. If the hypothesis could not be rejected, the consensus judgment was taken to be undecided. More formally, given the sample of size 1 1 , for each decision:

consensus “yes”: z1 individual “yes’s’’ 2 9 ‘‘n~’’: 2 individual “no’s’’ 2 9

“?”: otherwise

a formulation by which the consensus “yes” or “no” is “significant” at the 0.066 level.

The procedure for computing the consensus judgment may be given the following interpretation: “if the vote is not more decisive than might reasonably have been expected should it have been conducted by tossing a fair coin a successive number of times, then the matter shall be considered undecided.”

The results of the consensus classification are included as Appendix I1 to the paper.

Of the 550 consensus choices computed, 250 (45.5%) were “decisive” (a “yes” or a “no”). In a full 300 cases (54.5%) it was not possible to reject the null hypothesis at the 0.066 level. Further, it proved much easier for the group to conclude that a descriptor did nor apply (227 cases) than to conclude that it did apply (23 cases). The ambiguity evident at the group level was reflected in the individual comments solicited in the questionnaires; overall, the choices proved to be difficult and frustrating for the respondents.

Expecially interesting was a comparison (Table 1) of the classification decisions of the descriptor originator (myself) with the consensus decisions of the group (myself excluded).

Table 1 . Comparison of Classification Decisions.

Consensus Decisions

Originator Decisions “yes” “no” Totals ‘‘7,’

“yes” 15 48 14 I1

Totals 3 1 218 235 550 “no” 22 230 221 413

x’ = 37.1, significant at 0.001 level

[Note: In order to make the comparison, the original consensus classifications were recomputed so as to be independent of those of the originator. Redefining:

consensus “yes”: 2 individual “yes’s” 2 8 ‘ C n 0 ) * . . 2 individual “no’s” 2 8

6 U p . . . otherwise


where the originator’s classifications are not included in the scoring. A consensus “yes” or “no” is significant here at the 0.109 level, a slight relaxation from the original 0.066 level. The result of the recomputation was the resolution of 22 “?” classifications, 14 to “yes,” and 8 to ‘‘no.” Only 4 descriptors were involved in the new “no” classifications, however.]

Note that of the descriptor applications “proposed” by the originator (a total of 77), only a fraction of these (15, or 19.5%) were “accepted.” Furthermore, almost as many (14, or 18.2%) were “rejected.” Obviously, the application of Function Descriptors is not so straightforward a task that it can be left entirely to a single individual. At a minimum, some sort of validation activity is required.

(The decisions of originator and consensus were, for- tunately, not entirely unrelated. The null hypothesis that there was no difference between the originator “yes” and “no” decisions insofar as the consensus judgments attached to them was rejected at the 0.001 level. Thus, a basis for agreement may be said to exist.)

Overall, UMPLIS was rather poorly described by the consensus descriptors applied, in the sense that effective discriminations between subsystems were not made. Four of the eleven subsystems were characterized only by the term Information-Retrieving, for example. And only in the case of two descriptors applied (Project- Managing and Message-Routing), was the consensus able to reject application of the descriptors to all other subsystems.

Several factors served to complicate the descriptor applications, and may explain in part the experimental results. First, the applications were made to the subsystems of UMPLIS, not to UMPLIS as a whole, and not to independent systems. The problem of subsystem in- teractions tended to confuse the descriptor applications as a consequence.

A second factor, mentioned earlier, was the incom- plete nature of the UMPLIS design. An operational UMPLIS might have been more easily described perhaps.

Finally, a very basic difficulty in applying the descriptors to UMPLIS was the problem of distinguishing between functions to be supported by the subsystem, and functions to be carried out by a subsystem engaged in this support. Informal remarks entered by the questionnaire respondents were typically addressed to this problem (11). (The questionnaire called for an application of a descriptor to a subsystem if it “should be understood” to be a subsystem of that type, thus opening the way to the differing interpretations.)

Functions of systems may be said to be of two different types, extrinsic and intrinsic (1, p. 26). A system has an extrinsic function when the function is not one of its own, but one it has by virtue of its existence

as an alternative means to some end. On the other hand, when a function of a system can be attributed to it on the basis of its behavior alone, the function may be said to be intrinsic. The distinction may be easily illustrated. If we describe UMPLIS as an Environment-Protecting system, we might mean one of two things: either that its users may employ its information as a means to protect the environment (an extrinsic interpretation); or that the system actively seeks to protect the environment (intrinsic interpretation).

The distinction in interpretation is a crucial one, for it indicates in part the commitment of the system toward the ends for which it is designed. (An “activist” view of UMPLIS is that it is intrinsically Environment- Protecting. A “passivist” view is that it is only extrinsi-

Thus one important result of the experiment was the realization that some redefinition of the Function De- scriptor, or some restatement of the criteria for its application, was necessary to avoid the confusing of extrinsic with intrinsic functions. An approach in this direction will be described in the conclusion which follows.

One further observation on the experimental results is also worth making. It was noted that the number of descriptor applications made by a questionnaire respondent was related to his “closeness” to the system. This is shown by an anlysis of the rank ordering of the individual descriptor application frequencies (Table 2). The KruskalTWallis test statistic as computed indicates that the null hypothesis that the two samples are drawn from identical populations may be rejected at the 0.01 significance level, with 1 degree of freedom. It may thus be concluded that project leaders and full-time coworkers tend to attribute more functions to the system than part-time coworkers. Or: “the closer you are to an information system, the more you see in it.” This result corresponds to a conclusion drawn from an earlier research effort, to the effect that “managers who involve themselves with the MIS will appreciate the system, and that managers who are uninvolved will be unappreciative”

Table 2. Rank Ordering of Descriptor Application Frequencies.

cally so.)

(13).

Project leaders and full-time coworkers Part-time coworkers

Applications Rank Applications Rank

355 2 I1 8 356 1 5 1 1 1 131 I 76 9 142 5 62 10 202 4 253 3 132 6

H = 7.00


0 Conclusion

Following the completion and analysis of the small experiment just described, the process of developing the list of Function Descriptors by means of their application to other information systems was continued. At the conclusion of the exploratory work undertaken, the list of Function Descriptors totaled 83 descriptors (included as Appendix I), and 25 information systems had been described. (A comparison of the final list of descriptors with those used in the UMPLIS experiment illustrates the dynamics of the process: ten of the 50 descriptors used in the experiment do not appear among the final 83).

On the basis of the work which has been described, several conclusions may be drawn.

First, the Function Descriptor does show promise as a means for describing and classifying information systems. In spite of difficulties such as those reflected by the experiment, it still seems worthwhile to continue the exploration of its application.

One of the principal problems to be overcome was in- dicated in the above discussion of the experiment: the confusing of extrinsic and intrinsic functions in infoxma- tion system description. More generally, it must be recognized that the functions of information systems make up a “means/ends” hierarchy, with certain functions incorporated primarily to serve others.

The “means/ends” organization of information system functions may be recognized by a classification and ordering of the functions according to three types: (i) utilization-level functions;(ii) production-level functions; and (iii) operation-level functions.

Utilization-level functiom refer to those functions which constitute “utilization” of an information system, in the sense that the clients’ interests are served through the use of the system. In the case of UMPLIS, for example, utilization-level functions might include:

Environment-Protecting S tandar d-Se t t ing Emergency-Responding C ontingency-Planning Technology-Assessing Research-Directing Legisla t ion-Preparing

among others. It is in the nature of utilization-level functions that, through their reflection of the user and his needs, they describe the “purposes” to be served by an information system. (Note that even within this class of functions, a meansends relationship may exist. For example, Environment-Protecting might be said to be the “higher order” function of UMPLIS, with the other functions existing primarily to serve it.)

Production-level functions describe the goodsproduo

ing or service-producing activities of an information system with respect to its users. Once produced, such goods or services have potential “utility,” in the sense that through their application, the users’ interests are intended to be served. In the case of UMPLIS, to continue the example, production-level functions might include :

Issue-Addressing Quest ion-Answering Fact-Finding Opinion-Soliciting Re ferral-Providing Source-Locating

among others. Production-level functions tend to describe the “output” of an information system, prior to the utilization to be subsequently made. In this regard, production-level functions may be thought of as subordinate to utilization-level functions, which they exist to serve. (For example, in UMPLIS, Issue-Addressing exists to support Environment-Protecting, Standard-Setting, etc.)

Operation-level functions refer to those inform a tion system functions which are components of the productive process taken as an operational whole. Again, in the case of UMPLIS, such functions might include:

Message-Routing Computer-Operating Record-Keeping Subject-Indexing

among others. Typically, such operation-level functions are “internal” to the information system, in the sense that they are of no direct interest to the user; rather, their employment is a matter of technical efficiency in carrying out the production-level functions of the system. Hence, these functions may be considered subordinate to the production-level functions, in the same way that production-level functions are subordinate to utilization-level functions. A rank order to the three classification categories is thus established.

It may be that a distinction among information system functions according to the classification scheme just outlined will facilitate F-Descriptor application. How- ever, further experimental work will be necessary to test this proposition.

A second problem with the Function Descriptors and their application lies with the matrix method by which each descriptor is judged to “apply” or “not apply” to each information system described, generating an m X n binary matrix for m descriptors and n systems. The method is plagued by what might be termed “the problem of persistent ambiguity.” The “simple” yesor-no decisions made turn out not to be simple at all in most cases, as was seen in the results of the experiment. Whether an F-Descriptor applies to a system is not at


all obvious to an observer, but rather depends on “how he looks at it.” A conscientious observer will shift the perspective of his position now and then, the better to “see” a system, and the consequences of such changes can necessitate a reworking of his past observations as well. The result is that the rate at which additional system descriptions can be absorbed into the matrix tends to slow down, as the matrix increases in size. Further, an inordinate amount of time tends to be spent on the “borderline decisions,” not necessarily to the ultimate advantage of the description process as a whole.

For these reasons, perhaps the matrix method should be altered so that the “persistent ambiguity” is more easily absorbed. One obvious alternative would be to incorporate the “?” in addition to “yes” and “no” as legitimate individual responses to the application decisions.

More preferable might be a change in the directions for application, from the current rule, which may be interpreted as

For each information system, indicate, for each descriptor, whether it “applies” or “does not apply.”

For each information system, select a set of descriptors which adequately characterize the functions of the system.

Under the alternative a descriptor may not be applied to a system, not because it “does not apply,” but rather because it is “not necessary” to an “adequate descrip tion.” The guess is that this might prove to be an easier rule with which to work in practice, although this idea too remains to be tested. (Note, however, that the interpretation of the data in the matrix is made more diffi-

to the alternative

cult by the revised rule, inasmuch as the descriptor application decisions would no longer be made “indepen- den tly .”)

The present work on Function Descriptors represents only a beginning step in the development of an information system typology. In addition other forms of descriptors should be explored. Likely subjects for description include (1) system instrumentation (processing hardware and software, storage media, communica- tions facilities, etc.); (2) system data bases (collections of files and their “content,” organization, extent, frequency of update, etc.); (3) system users (e.g., organizational roles served); and (4) system management (perhaps in terms of management techniques employed, e.g., “project organization,” “chief programmer team,” “structured programming,” etc.). The list is intended only to be suggestive.

Finally, it has been proposed that future work in these directions be based on the establishment of an “Information System Reference Center,” in which docu- mentation on particular real-world information systems would be gathered and anlayzed, and systematic descriptions made (e.g., through the application of F-Descrip tors) (12). The purpose of such a Center would be two- fold: (i) to provide reference services to individuals seek- ing information about particular information systems, or particular types of information systems; (ii) to develop a formal description methodology on the basis of the use of the Center.

The Information System Reference Center would be intended to provide a realistic focus to the development of the description methodology and information system typology. In the absence of such a working environment, in which descriptions could be evaluated as to usefulness, the outcome of the typology research would likely be merely “academic.”

Appendix I: Function Descriptor List

1. Activity-Scheduling 2. Artcreating 3. Behavior-Simulating 4. Benefit-Granting 5. Billcollecting 6. Business-Accounting 7. CaseHandling 8. Census-Taking 9. Community-Organizing

10. Computer-Operating 11. Condition-Diagnosing 12. Construction-Engineer-

13. Content-Analysing 14. Contingency-Planning 15. Cost-Estimating 16. Customer-Servicing 17. Data-Transmitting

ing

18. Decision-Programming 19. Design-Assisting 20. Document-Classifying 21. Emergency-Responding 22. Environment-Protect-

23. Exception-Detecting 24. Experiment-Conduct-

25. Fact-Finding 26. Future-Forecasting 27. Gameplaying 28. Hypothesis-Testing 29. Identity-Establishing 30. Information-Dissemina-

31. Intelligence-Gathering 32. Inventory-Maintaining

ing

ing

ting

33. Issue-Addressing 34. Item-Labeling 35. Job-Processing 36. Knowledge-Producing 37. Labor-Claiming 38. Land-Using 39. Language-Translating 40. Law-Enforcing 41. Legislation-Preparing 42. Literaturesearching 43. Logistics-Coordinating 44. Message-Routing 45. Model-Building 46. Opinion-Soliciting 47. Order-Issuing 48. Patient-Caring 49. Pattern-Recognizing 50. Performance-Measuring

5 1. Personnel-Employing 52. Perspective-Represent-

53. Place-Reserving 54. Policy-Formulating 55. Population-Sampling 56. Problem-Solving 5 7. Procedure- Administer-

58. Process-ControUing 59. Product-Marketing 60. Program-Budgeting 61. Project-Managing 62. Publication-Abstracting 63. Quality-Inspecting 64. Question- Answering 65. Record-Keeping 66. Referral-Providing

ing

ing

67. Region-Developing 68. Research-Directing 69. Resource-Allocating 70. Source-Locating 71. Species-Describing 72. Standard-Setting 73. Statistic-Computing 74. Status-Monitoring 75. Student-Instructing 76. Subject-Indexing 77. Technology-Assessing 78. Text-Editing 79. Theorem-Proving 80. Time-sharing 8 1 . Traffic-Regulating 82. Transaction-Initiating 83. Trend-Projecting


Appendix 11: Consensus Description of UMPLIS

UMPLIS Subsystem

1. 2. 3. 4. 5. 6. I. 8. 9. 10. 11. 12. 13. 14. 15. 16. 11. 18. 19. 20. 21. 22. 23. 24. 25. 26. 21. 28. 29. 30. 31. 32. 33. 34. 35. 36. 31. 38. 39. 40. 41. 42. 43. 44. 45. 46. 41. 48. 49. 50.

Descriptor

Activit y-Programming Art-Creating Behavior-Simulating Classification-Ordering Conditiorr Diagnosing Conten t-Analyzing Contingency-Planning Customer-Servicing Design- Assisting Documen t-Referencing Environment-Exploring Exception-Detecting Experimen t-Conducting Fact-Researching Future-Forecasting Game-Playing Hypothesis-Testing Iden tity-Establishing Informa tion-Retrieving In telligenceGathering Inventory-Taking Issue- Addressing Knowledge-Producing Language-Translating Law-Making Logistics-Coordinating Message-Rou ting Model-Building Opinion-Soliciting Pat tern-Recognizing Performance-Measuring Personnel-Organizing Perspective-Representing Policy-Formulating Problem-Solving Procedure- Administering ProcessCon trolling Project-Managing Question- Answering Record-Keeping Resource- Allocating Species-Describing Standard-Setting Status-Monitoring Student-Instructing Technology- Assessing Terminology-Developing Theorem-Proving Transaction-Initiating Trend-Projecting

0

0

0

0

0 0

0 0

0

0

1

0

0

0

1

0

1

0

0

1

1

0

1 0

0

0 1 1

0 0

0

0

2

0 0

0

0

0 0 0

0 0 0

1

0 0 0 0 0

0 0 0 0 0 0

0 0

0

0

0

0

0

3

0 0

0

0

0 0 0

0 0 0

1

0 0 0 0 0

0 0

0 0 0

0 0 1

0

0

0

0

0

4

0

0

1 0

0 0

1

0 0

0 0 0

0 0 0

0

0

0 1

0

0

KEY: “1” indicates “applies”; “0” indicates “does not apply”; blank indicates undecided.

5

0 0

0

0

0

0

0 0 0

1

0 0 0 0 0 0 0 0 0 0 0

0 0

0

0

0

0

0

6

0 1

0

1

0

0 0 0

0

0

0

0 0

0 0 0

1

7

0 0

0

0

1 0 0 0 0 0 0 0

1 0

0 0 0 0 0 0 0 0

0

0 0

0 0 0

0

0

0

8

0 0

0

0

0

0 0 0

1 0

0

0 0 0 0 0 0 0 0

0

0 0

0

0

0

0

9

0

1

0

0

0

1 0

0

0 0 0 0 0

0

0

0

0

0

0

10

0

0

0

0 0

1

0 0 0 0 0 0

0 0 0

0 0

0

0

0


References

1. Ackoff, R.L.; Emery, F.E. 1972. On Purposeful Systems. London: Tavistock Publications; 1972.

2. Blalock, H.M. 1960. Social Stutistics. New York: McGraw Hill; 1960.

3. Kunz, W.; Rittel, H. 1972. Die lnformotionswissenschoften. Munchen Wein: R. Oldenbourg Verlag; 1972.

4. Kunz, W.; Rittel, H. 1972. “UMPLIS: Gutachten und Vorschlage fur die Auslegung und Einrichtung eines Planunginformationssytem fur die Umweltpolitik, erstellt fuy das Bundesministerium des Innern; August 1972.

5. Kunz, W.; Rittel, H. 1973. “Projekt UMPLIS.” Umweit. 1973 (3); 43-47 VDI-Verlag Gmbh, Dusseldorf.

6. Reuter, W. 1974. “UMPLIS-An Example o f a Planning Information System.” DMG-DRS lournui. 1974; 8(2): 74- 82.

7. Sackman, H. 1967. Computers, Systems Science, and

EvoivingSociety. New York, John Wiley & Sons; 1967. 8. Sokal, R.R.; Sneath, P.H.A. 1963. Principles of Numericoi

Taxonomy. San Francisco: W.H. Freeman; 1963. 9. Stamper, R. 1973. lnformatlon In Business and Administra-

tive Systems. New York: John Wiley & Sons; 1973. 10. Swanson, E.B. 1973. “Report o f Work in Progress on a

Typology of Information Systems.” Arbeitspapier. Heidel- berg: Studiengruppe fur Systemforschung; February 1973.

11. Swanson, E.B. 1974. “An Experiment in Describing an In- formation System by Means of Function Descriptors.” Arbeitspapier. Heidelberg: Studiengruppe fur Systemfors- chung; March 1974.

12. Swanson, E.B. 1974. “A Follow-up Report on a Typology o f Information Systems.’’ Arbeitspapier. Heidelberg: Studiengruppe fur Systemforschung; August 1974.

13. Swanson, E.B. 1974. “Management Information Systems: Appreciation and Involvement.” Monugement Science. 1974; 21 (2): 178-1 88.


the application of function descriptors to the development of an information system topology

Documents