home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / risks / 145 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  30.6 KB

  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!CSL.SRI.COM!risks
  2. From: risks@CSL.SRI.COM (RISKS Forum)
  3. Newsgroups: comp.risks
  4. Subject: RISKS DIGEST 14.25
  5. Message-ID: <CMM.0.90.1.726796520.risks@chiron.csl.sri.com>
  6. Date: 11 Jan 93 23:55:20 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Reply-To: risks@csl.sri.com
  9. Distribution: world
  10. Organization: The Internet
  11. Lines: 525
  12. Approved: risks@csl.sri.com
  13.  
  14. RISKS-LIST: RISKS-FORUM Digest  Monday 11 January 1993  Volume 14 : Issue 25
  15.  
  16.         FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS 
  17.    ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
  18.  
  19.   Contents:
  20. Organizational Analysis in Computer Science -- PART TWO (Rob Kling)
  21.   [PART ONE is in RISKS-14.24.]
  22.  
  23.  The RISKS Forum is moderated.  Contributions should be relevant, sound, in 
  24.  good taste, objective, coherent, concise, and nonrepetitious.  Diversity is
  25.  welcome.  CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive 
  26.  "Subject:" line.  Others may be ignored!  Contributions will not be ACKed.  
  27.  The load is too great.  **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS,
  28.  especially .UUCP folks.  REQUESTS please to RISKS-Request@CSL.SRI.COM.     
  29.  
  30.  ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
  31.  Relevant contributions may appear in the RISKS section of regular issues
  32.  of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
  33.  
  34. ----------------------------------------------------------------------
  35.  
  36.    [CONTINUED FROM RISKS-14.24]
  37.  
  38. System Security and Reliability
  39.  
  40. In a simplified engineering model of computing, the reliability of products is
  41. assured through extensive testing in a development lab. The social world of
  42. technology use is not perceived as shaping the reliability of systems, except
  43. through irascible human factors, such as "operator errors." An interesting and
  44. tragic illustration of the limitations of this view can be found in some
  45. recent studies of the causes of death and maiming by an electron accelerator
  46. which was designed to help cure cancer, the Therac-25 (Jacky, 1991, Leveson
  47. and Turner, 1992).
  48.  
  49. The Therac-25 was designed and marketed in the mid 1980s by a Canadian firm
  50. AECL as an advanced medical technology. It featured complete software control
  51. over all major functions (supported by a DEC PDP-11), among other innovations.
  52. Previous machines included electro-mechanical interlocks to raise and lower
  53. radiation shields. Several thousand people were effectively treated with the
  54. Therac-25 each year. However, between 1985 and 1987 there were six known
  55. accidents in which several people died in the US. Other were seriously maimed
  56. or injured.
  57.  
  58. Both studies concur that there were subtle but important flaws in the design
  59. of the Therac-25's software and hardware. AECL's engineers tried to patch the
  60. existing hardware and (finally) software when they learned of some of the
  61. mishaps. But they treated each fix as the final repair.
  62.  
  63. Both studies show how the continuing series of mishaps was exacerbated by
  64. diverse organizational arrangements. Jacky claims that pressures for speedy
  65. work by low-skilled machine operators coupled with an interface design that
  66. did not enhance important error messages was one of many causes of the
  67. accidents. Leveson and Turner differ in downplaying the working conditions of
  68. the Therac-25's operators and emphasize the flawed social system for
  69. communicating the seriousness of problems to Federal regulators and other
  70. hospitals. Both studies observe that it is unlikely for the best of companies
  71. to develop perfect error-free systems without high quality feedback from
  72. users. Their recommendations differ: Jacky emphasizes the licensing of system
  73. developers to improve minimal standards of competence. Leveson and Turner
  74. propose extensive education and training of software engineers and more
  75. effective communication between manufacturers and their customers.
  76.  
  77. However, both studies indicate that an understanding of the safety of computer
  78. systems must go beyond the laboratory and extend into the organizational
  79. settings where it is used. In the case of the Therac-25, it required
  80. understanding a complex web of interorganizational relationships, as well as
  81. the technical design and operation of the equipment. The need for this kind of
  82. organizational understanding is unfortunately slighted in the CS academic
  83. world today. CTF discusses only those aspects of computer system reliability
  84. which are amenable to understanding through laboratory-like studies (Hartmanis
  85. and Lin, 1992:110-111). But cases of safety critical systems, like the
  86. Therac-25, indicate why some Computer Scientists must be willing to undertake
  87. (and teach) organizational analysis.
  88.  
  89.    [From the title of the above section, I presume Rob had not yet gotten
  90.    around to commenting on system security in complementary context to the 
  91.    discussion on human safety.  But it seems that similar conclusions can 
  92.    be drawn.  Apologies for the interjection.  PGN]
  93.  
  94. Worldviews and Surprises about Computerization
  95.  
  96. These few paragraphs barely sketch the highlights of a fertile and significant
  97. body of research about computer systems in use.  Perhaps the most important
  98. simplification for traditional computer scientists is to appreciate how people
  99. and their organizations are situated in a social world and consequently
  100. compute within a social world. People act in relationship to others in various
  101. ways and concerns of belonging, status, resources, and power are often
  102. central. The web of people's relationships extend beyond various formally
  103. defined group and organizational boundaries (Kling and Scacchi, 1982; Kling,
  104. 1992).  People construct their worlds, including the meanings and uses of
  105. information technologies, through their social interactions.
  106.  
  107. This view is, of course, not new to social scientists. On the other hand,
  108. there is no specific body of social theory which can easily be specialized for
  109. "the case of computing," and swiftly produce good theories for Organizational
  110. Informatics as trivial deductions. The best research in Organizational
  111. Informatics draws upon diverse theoretical and methodological approaches
  112. within the social sciences with a strong effort to select those which best
  113. explain diverse aspects of computerization.
  114.  
  115.        ORGANIZATIONAL INFORMATICS WITHIN COMPUTER SCIENCE
  116.  
  117. CTF places dual responsibilities on Computer Scientists. One responsibility is
  118. to produce a significant body of applicable research. The other responsibility
  119. is to educate a significant fraction of CS students to be more effective in
  120. conceiving and implementing systems that will enhance organizational
  121. performance. It may be possible to organize research and instruction so as to
  122. decouple these responsibilities. For example, molecular biologists play only a
  123. small role in training doctors. However, CS departments act like an integrated
  124. Medical school and Biology department. They are the primary academic locations
  125. for training degreed computing specialists, and they conduct a diverse array
  126. of less applicable and more applicable research. In practice, the research
  127. interests of CS faculty shape the range of topics taught in CS departments,
  128. especially the 150 PhD granting departments. CS curricula mirror major areas
  129. of CS research and the topics which CS faculty understand through their own
  130. educations and subsequent research. As a consequence, CS courses are likely to
  131. avoid important CS topics which appear a bit foreign to the instructor.
  132.  
  133. An interesting example of this coupling can be illustrated by CTF, in a brief
  134. description of public-key encryption systems and digital signatures (Hartmanis
  135. and Lin, 1992:27). In the simple example, Bob and Alice can send messages
  136. reliably if each maintains a secret key. Nothing is said about the social
  137. complications of actually keeping keys secret. The practical problems are
  138. similar to those of managing passwords. In real organizations, people lose or
  139. forget their passwords. Also, some passwords can be shared by a group of with
  140. shifting membership, and the "secret key" can readily become semi-public. In
  141. practice, the management of keys is a critical element of system security.
  142. But Computer Scientists are prone to teach courses on cryptography as
  143. exercises in applied mathematics, such as number theory and Galois theory, and
  144. to skirt the vexing practical problems of making encryption a practical
  145. organizational activity.
  146.  
  147. Today, most of the 40,000 people who obtain BS and MS degrees in CS each year
  148. in the U.S. have no opportunities for systematic exposure to reliable
  149. knowledge about the best design strategies, common uses, effective
  150. implementation, and assessments of value of computing in a social world
  151. (Lewis, 1989). Yet a substantial fraction of these students go on to work for
  152. organizations attempting to produce or maintain systems that improve
  153. organizational performance without a good conceptual basis for their work.
  154. Consequently, many of them develop systems that underperform in organizational
  155. terms even when they are technically refined. They also recommend ineffective
  156. implementation procedures and are sometimes even counterproductive.
  157.  
  158. One defensible alternative to my position is that CS departments should not
  159. take on any form of organizational analysis. They should aggressively take a
  160. role akin to Biology departments rather than taking on any instructional or
  161. research roles like Medical schools. To be sincere, this position requires a
  162. high level of restraint by academic Computer Scientists. First and foremost,
  163. they should cease from talking about the uses, value or even problems of
  164. computerized systems that would be used in any organizational setting.
  165. Research proposals would be mute about any conceivable application of research
  166. results. Further, they should make effective efforts to insure that anyone who
  167. employs their graduates should be aware that they may have no special skills
  168. in understanding organizational computing. It would take an aggressive "truth
  169. in advertising" campaign to help make it clear that Computer Scientists have
  170. no effective methods for understanding computerization in the social world.
  171. Further, Computer Scientists would forsake their commitments to subfields like
  172. software engineering which tacitly deals with ways to support teams of systems
  173. developers to work effectively (Curtis, et. al. 1988). Computer Scientists, in
  174. this view, would remove themselves from addressing organizational and human
  175. behavior, in the same way that molecular biologists are removed from
  176. professionally commenting on the practices of cardiologists and obstetricians.
  177. CTF argues that this view would be self-defeating.  But it would be internally
  178. consistent and have a distinctive integrity.
  179.  
  180. In contrast, CS faculty are often reluctant to wholly embrace Organizational
  181. Informatics. But some CS subfields, such as software engineering, depend upon
  182. organizational analysis (Curtis, et. al., 1988). Further, CS faculty do little
  183. to advertise the distinctive limitations in the analytical skills of our
  184. programs' graduates. Part of the dilemma develops because many CS faculty are
  185. ambivalent about systematic studies of human behavior. Applied mathematics and
  186. other modes of inquiry which seem to yield concise, crisp and concrete results
  187. are often the most cherished. As a consequence, those who conduct behaviorally
  188. oriented research in CS departments are often inappropriately marginalized.
  189. Their students and the discipline suffers as a result.
  190.  
  191. Between 1986 and 1989, the total number of BS and MS CS degrees awarded
  192. annually in the US declined from about 50,000 to approximately 40,000. The
  193. number of students majoring in CS rapidly declined at a time when
  194. computerization was becoming widespread in many fields. A significant fraction
  195. of the decline can be attributed to many students finding CS programs insular
  196. and indifferent to many exciting forms of computerization. The decline of
  197. military R&D in the U.S. can amplify these trends or stimulate a more
  198. cosmopolitan view in CS departments. The decline in military R&D is shifting
  199. the job market for new CS graduates towards a markedly more civilian
  200. orientation. This shift, along with the trend towards computing distributed
  201. into diverse work groups, is leading to more job opportunities for people with
  202. CS education who know Organizational Informatics.
  203.  
  204. The situation of CS departments has some parallels with Statistics
  205. departments. Statistics are widely used and taught in many academic
  206. disciplines. But Statistics departments have often maintained a monkish
  207. isolation from "applications." Consequently, the application of statistics
  208. thrives while Statistics departments have few students and modest resources.
  209. Might the status of Statistics indicate a future possibility for an insular
  210. approach to CS?
  211.  
  212. The best Organizational Informatics research in North America is conducted by
  213. faculty in the Information Systems departments in business schools and by
  214. scattered social scientists (cf. Boland and Hirschheim, 1987; Galegher, Kraut
  215. and Egido, 1990; Cotterman and Senn, 1992; Sproull and Kiesler, 1991). But
  216. Computer Scientists cannot effectively delegate the research and teaching of
  217. Organizational Informatics to business Schools or social science departments.
  218.  
  219. Like Computer Scientists, faculty in these other disciplines prefer to focus
  220. on their own self-defined issues.  Computer Scientists are much more likely to
  221. ask questions with attention to fine grained technological nuances that
  222. influence designs. For example, the professional discussions of computer risks
  223. have been best developed through activities sponsored by the ACM's Special
  224. Interest Group on Software (SIGSOFT). They are outside the purview of business
  225. school faculty and, at best, only a few social scientists are interested in
  226. them. Generally, technology plays a minor role in social science theorizing.
  227. And when social scientists study technologies, they see a world of
  228. possibilities: energy technologies, transportation technologies, communication
  229. technologies (including television), medicinal drugs and devices, and so on.
  230. They see little reason to give computer-related information technologies a
  231. privileged role within this cornucopia. As a consequence, the few social
  232. scientists who take a keen interest in studying computerization are
  233. unfortunately placed in marginal positions within their own disciplines. Often
  234. they must link their studies to mainstream concerns as defined by the
  235. tastemakers of their own fields, and the resulting publications appear
  236. irrelevant to Computer Scientists.
  237.  
  238. Further, faculty in these other disciplines are not organized to effectively
  239. teach tens of thousands of CS students, students who are steeped in technology
  240. and usually very naive about organizations, about systems development and use
  241. in organizations. In North America there is no well developed institutional
  242. arrangement for educating students who can effectively take leadership roles
  243. in conceptualizing and developing complex organizational computing projects
  244. (Lewis, 1989).
  245.  
  246. CTF is permeated with interesting claims about the social value of recent and
  247. emerging computer-based technologies. While many of these observations should
  248. rest on an empirically grounded scientific footing, Computer Scientists have
  249. deprived themselves of access to such research. For example, the discussion of
  250. systems risks in the ACM rests on a large and varied collection of examples
  251. and anecdotes. But there is no significant research program to help better
  252. understand the conditions under which organizations are more likely to develop
  253. systems using the best risk-reducing practices. There is an interesting body
  254. of professional lore, but little scholarship to ground it (See Appendix).
  255.  
  256. Computer Scientists have virtually no scholarship to utilize in understanding
  257. when high performance networks, like the National Research and Education
  258. Network, will catalyze social value proportional to their costs. Consequently,
  259. many of the "obvious" claims about the value of various computing technologies
  260. that we Computer Scientists make are more akin to the lore of home remedies
  261. for curing illness. Some are valid, others are unfounded speculation. More
  262. seriously, the theoretical bases for recommending home medical remedies and
  263. new computer technologies can not advance without having sound research
  264. programs.
  265.  
  266.                          WHAT IS NEEDED
  267.  
  268. CTF sets the stage for developing Organizational Informatics as a
  269. strong subfield within Computer Science. CTF bases the expansion
  270. of the discipline on a rich array of applications in which many
  271. of the effective technologies must be conceived in relationship
  272. to plausible uses in order provide attractive social value for
  273. multi-billion dollar public investments.
  274.  
  275. The CS community needs an institutionalized research capability to produce a
  276. reliable body of knowledge about the usability and value of computerized
  277. systems and the conditions under which computer systems improve organizational
  278. performance. In Western Europe there are research projects about
  279. Organizational Informatics in a few Computer Science departments and research
  280. funding through the EEC's Espirit program (Bubenko, 1992; Iivari, 1991; Kyng
  281. and Greenbaum, 1991). These new research and instructional programs in Western
  282. Europe give Organizational Informatics a significantly more effective place in
  283. CS education and research than it now has in North America.
  284.  
  285. The CS community in the U.S. has 30 years of experience in institutionalizing
  286. research programs, especially through the Defense Advanced Research Projects
  287. Agency and the National Science Foundation (NSF). There are many approaches,
  288. including national centers and individual investigator research grants. All
  289. such programs aim to develop and sustain research fields with a combination of
  290. direct research funds, the education of future researchers, and the
  291. development of research infrastructure. They are all multimillion dollar
  292. efforts. Today, NSF devotes about $125K annually to Organizational Informatics
  293. as part of the Information Technology in Organizations program. This start is
  294. far short of the level of funding required to develop this field within CS.
  295.  
  296. The North American CS curricula must also include opportunities for students
  297. to learn the most reliable knowledge about the social dimensions of systems
  298. development and use (Denning, 1992).  These opportunities, formed as courses,
  299. can provide varied levels of sophistication. The most elementary courses
  300. introduce students to some of the key topics in Organizational Informatics and
  301. the limitations of Systems Rationalism as an organizing frame (for example,
  302. Dunlop and Kling, 1991a). More advanced courses focus on specific topics, such
  303. as those I have listed above. They teach about substantive problems and
  304. theoretical approaches for analyzing them. While many of these approaches are
  305. anchored in the sociological theory of organizations, CS students usually
  306. won't grasp the importance of the theories without numerous computing examples
  307. to work with. They also have trouble grasping the character of computing in
  308. organizations without guided opportunities for observing and analyzing
  309. computerization in practice. Consequently, some courses should offer
  310. opportunities for studying issues of computerization in actual organizations.
  311.  
  312. Fortunately, a few CS departments offer some courses in Organizational
  313. Informatics. In addition, some CS faculty who research and teach about human
  314. behavior in areas like Human-Computer Interaction and Software Engineering
  315. can help expand the range of research an instruction. Unfortunately, only a
  316. fraction of the CS departments in the US. have faculty who study and teach
  317. about computing and human behavior.
  318.  
  319. While the study of Organizational Informatics builds upon both the traditional
  320. technological foundations of CS and the social sciences, the social sciences
  321. at most universities will not develop it as an effective foundational topic
  322. for CS. On specific campuses, CS faculty may be able to develop good
  323. instructional programs along with colleagues in social sciences or Schools of
  324. Management.
  325.  
  326. But delegating this inquiry to some other discipline does not provide a
  327. national scale solution for CS. Other disciplines will not do our important
  328. work for us. Mathematics departments may be willing to teach graph theory for
  329. CS students, but the analysis of algorithms would be a much weaker field if it
  330. could only be carried out within Mathematics Departments. For similar reasons,
  331. it is time for academic Computer Science to embrace Organizational Informatics
  332. as a key area of research and instruction.
  333.  
  334.                            REFERENCES
  335.  
  336. Bentley, Richard, Tom Rodden, Peter Sawyer, Ian Sommerville, John
  337.      Hughes, David Randall and Dan Shapiro.  1992.
  338.      "Ethnographically Informed Systems Design for Air Traffic
  339.      Control." Proc. Conference on Computer-Supported Cooperative
  340.      Work, Jon Turner and Robert Kraut (ed.) New York, ACM Press.
  341. Boland, Richard and Rudy Hirschhiem (Ed). 1987.  Critical Issues
  342.      in Information Systems, New York: John-Wiley. 
  343. Bullen, Christine and John Bennett. 1991.  Groupware in Practice:
  344.      An Interpretation of Work Experience" in Dunlop and Kling 1991b.
  345. Bubenko, Janis. 1992. "On the Evolution of Information Systems
  346.      Modeling: A Scandinavian Perspective." in Lyytinen and
  347.      Puuronen, 1992.
  348. Cotterman, William and James Senn (Eds). 1992. Challenges and
  349.      Strategies for Research in Systems Development. New York:
  350.      John Wiley.
  351. Curtis, Bill, Herb Krasner and Niel Iscoe.  1988. "A Field Study
  352.      of the Software Design Process for Large Systems,"
  353.      Communications. of the ACM. 31(11):1268-1287.
  354. Denning, Peter. 1991. "Computing, Applications, and Computational
  355.      Science." Communications of the ACM. (October)
  356.      34(10):129-131.
  357. Denning, Peter. 1992. "Educating a New Engineer" Communications
  358.      of the ACM. (December) 35(12):83-97
  359. Dunlop, Charles  and Rob Kling, 1991a. "Introduction to the
  360.      Economic and Organizational Dimensions of Computerization."
  361.      in Dunlop and Kling, 1991b.
  362. Dunlop, Charles and Rob Kling (Ed). 1991b. Computerization and
  363.      Controversy: Value Conflicts and Social Choices. Boston:
  364.      Academic Press.
  365. Ehn, Pelle. 1991. "The Art and Science of Designing Computer
  366.      Artifacts." in Dunlop and Kling, 1991.
  367. Fish, Robert S., Robert E. Kraut, Robert W. Root, and Ronald E.
  368.      Rice. "Video as a Technology for Informed Communication." 
  369.      Communications of the ACM,36(1)(January 1993):48-61.
  370. Galegher, Jolene, Robert Kraut, and Carmen Egido (Ed.) 1990.
  371.      Intellectual Teamwork: Social and Intellectual Foundations
  372.      of Cooperative Work.  Hillsdale, NJ: Lawrence Erlbaum.
  373. Greif, Irene. ed. 1988. Computer Supported Cooperative Work: A
  374.      Book of Readings. San Mateo, Ca: Morgan Kaufman.
  375. Grudin, Jonathan. 1989. "Why Groupware Applications Fail:
  376.      Problems in Design and Evaluation." Office: Technology and
  377.      People. 4(3):245-264. 
  378. Hartmanis, Juris and Herbert Lin (Eds). 1992. Computing the
  379.      Future: A Broader Agenda for Computer Science and
  380.      Engineering.  Washington, DC. National Academy Press.
  381.      [Briefly summarized in Communications of the ACM,35(11)
  382.      November 1992]  
  383.        [[TO BE DISCUSSED AT ACM CSC in Indianapolis, 16-18 Feb 1992... PGN]]
  384. Hewitt, Carl. 1986. "Offices are Open Systems" ACM Transactions
  385.      on Office Information Systems. 4(3)(July):271-287.
  386. Iivari, J. 1991."A Paradigmatic Analysis of Contemporary Schools
  387.      of IS Development." European J. Information Systems
  388.      1(4)(Dec): 249-272.
  389. Jacky, Jonathan. 1991. "Safety-Critical Computing: Hazards,
  390.      Practices, Standards, and Regulation" in Dunlop and Kling
  391.      1991b.
  392. Jarvinen, Pertti. 1992. "On Research into the Individual and
  393.      Computing Systems," in Lyytinen and Puuronen, 1992.
  394. King, John L. and Kenneth L. Kraemer. 1981. "Cost as a Social
  395.      Impact of Telecommunications and Other Information
  396.      Technologies." In Mitchell Moss (Ed.) Telecommunications and
  397.      Productivity, New York: Addison-Wesley.
  398. Kling, Rob. 1992. "Behind the Terminal: The Critical Role of
  399.      Computing Infrastructure In Effective Information Systems'
  400.      Development and Use." Chapter 10 in Challenges and
  401.      Strategies for Research in Systems Development. edited by
  402.      William Cotterman and James Senn. Pp. 153-201. New York:
  403.      John Wiley.
  404. Kling, Rob  and Charles Dunlop. 1993. "Controversies About
  405.      Computerization and the Character of White Collar Worklife."
  406.      The Information Society. 9(1) (Jan-Feb)
  407. Kling, Rob and Lisa Covi. 1993. Review of Connections by Lee
  408.      Sproull and Sara Kiesler. The Information Society, 9(1)
  409.      (Jan-Feb, 1993).
  410. Kling, Rob, Isaac Scherson, and Jonathan Allen. 1992. "Massively 
  411.      Parallel Computing and Information Capitalism" in A New Era
  412.      of Computing. W. Daniel Hillis and James Bailey  (Ed.)
  413.      Cambridge, Ma: The MIT Press. 
  414. Kling, Rob and Walt Scacchi. 1982. "The Web of Computing: Com-
  415.      puting Technology as Social Organization", Advances in
  416.      Computers. Vol. 21, Academic Press: New York. 
  417. Kraemer, Kenneth .L., Dickhoven, Siegfried, Fallows-Tierney,
  418.      Susan, and King, John L. 1985.  Datawars: The Politics of
  419.      Modeling in Federal Policymaking.  New York:  Columbia
  420.      University Press.
  421. Kyng, Morton and Joan Greenbaum. 1991. Design at Work:
  422.      Cooperative Work of Computer Systems. Hillsdale, NJ.:
  423.      Lawrence Erlbaum.
  424. Ladner, Sharyn and Hope Tillman. 1992. "How Special Librarians
  425.      Really Use the Internet: Summary of Findings and
  426.      Implications for  the Library of the Future" Canadian
  427.      Library Journal, 49(3), 211-216.
  428. Leveson, Nancy G. and Clark S. Turner. 1992. "An Investigation of
  429.      the Therac-25 Accidents".  Technical Report #92-108.
  430.      Department of Information and Computer Science, University
  431.      of California, Irvine.
  432. Lewis, Philip M. 1989. "Information Systems as an Engineering
  433.      Discipline."  Communications of the ACM
  434.      32(9)(Sept):1045-1047.
  435. Lucas, Henry C. 1981. Implementation : the Key to Successful
  436.      Information Systems. New York: Columbia University Press.
  437. Lyytinen, Kalle and Seppo Puuronen (Ed.) 1992. Computing in the
  438.      Past, Present and Future: Issues and approaches in honor of
  439.      the 25th anniversary of the Department of Computer Science
  440.      and Information Systems. Jyvaskyla Finland, Dept. of CS and
  441.      IS, University of Jyvaskyla.
  442. Orlikowski, Wanda. 1992. "Learning from Notes: Organizational
  443.      Issues in Groupware Implementation." Proc. Conference on
  444.      Computer-Supported Cooperative Work, Jon Turner and Robert
  445.      Kraut (Ed.) New York, ACM Press.
  446. Sarmanto, Auvo.  1992. "Can Research and Education in the Field
  447.      of Information Sciences Foresee the Future of Development?"
  448.      in Lyytinen and Puuronen, 1992.
  449. Sproull, Lee and Sara Kiesler. 1991. Connections: New Ways of
  450.      Working in the Networked Organization. Cambridge, Mass.: MIT Press.
  451. Suchman, Lucy. 1983. "Office Procedures as Practical Action: Models
  452.      of Work and System Design."  ACM Transactions on Office
  453.      Information Systems. 1(4)(October):320-328.
  454. Winograd, Terry and Fernando Flores. 1986. Understanding
  455.      Computers and Cognition. Norwood, NJ: Ablex Publishing.
  456.  
  457.  
  458.  
  459.                         ACKNOWLEDGEMENTS
  460.  
  461. This paper builds on ideas which I've developed over the last decade. But they
  462. have been deepened by some recent events, such as the CTF report. They were
  463. also sharpened through a lecture and followon discussion with colleagues at
  464. the University of Toronto, including Ron Baeker, Andy Clement, Kelley
  465. Gottlieb, and Marilyn Mantei.  Rick Weingarten suggested that I write a brief
  466. position paper reflecting those ideas. At key points, Peter Denning and Peter
  467. Neumann provided helpful encouragement and sage advice. I also appreciate the
  468. efforts of numerous other friends and colleagues to help strengthen this paper
  469. through their comments and critical assistance. The paper is immeasurably
  470. stronger because of the prompt questions and suggestions that I received in
  471. response to an evolving manuscript from the following people: Mark Ackerman,
  472. Jonathan P. Allen, Bob Anderson, Lisa Covi, Brad Cox, Gordon Davis, Phillip
  473. Fites, Simson Garfinkel, Les Gasser, Sy Goodman, Beki Grinter, Jonathan
  474. Grudin, Pertti Jarvinen, John King, Heinz Klein, Trond Knudsen, Kenneth
  475. Kraemer, Sharyn Ladner, Nancy Leveson, Lars Matthiesen, Colin Potts, Paul
  476. Resnick, Larry Rosenberg, Tim Standish, John Tillquist, Carson Woo and Bill
  477. Wulf.
  478.  
  479.                        APPENDIX
  480.  
  481.             Published Materials about Computer Risks
  482.  
  483. Unfortunately, there is no single good book or comprehensive review article
  484. about the diverse risks of computerized systems to people and organizations,
  485. and ways to mitigate them. The Internet board, comp.risks, is the richest
  486. archive of diverse episodes and diverse discussions of their causes and cures.
  487. While its moderator, Peter Neumann does a superb job of organizing discussions
  488. of specific topics each year and also creates periodic indices, there is no
  489. simple way to sift through the megabytes of accumulated comp.risks files.
  490.  
  491. Computerization and Controversy edited by Charles Dunlop and Rob Kling (1991)
  492. includes two major sections on "security and reliability" and "privacy and
  493. social control" which identify many key debates and reprint some key articles
  494. and book excerpts which reflect different positions.  Another major source is
  495. a series of articles, "Inside Risks, which Peter Neumann edits for
  496. Communications of the ACM.
  497.  
  498. This is a list of this series of articles, to date:
  499. (All articles are by Peter Neumann unless otherwise indicated.)
  500.  
  501. Jul 90.  1. Some Reflections on a Telephone Switching Problem
  502. Aug 90.  2. Insecurity About Security?
  503. Sep 90.  3. A Few Old Coincidences 
  504. Oct 90.  4. Ghosts, Mysteries, and Risks of Uncertainty 
  505. Nov 90.  5. Risks in computerized elections
  506. Dec 90.  6. Computerized medical devices, Jon Jacky 
  507. Jan 91.  7. The Clock Grows at Midnight
  508. Feb 91.  8. Certifying Programmers and Programs
  509. Mar 91.  9. Putting on Your Best Interface
  510. Apr 91. 10. Interpreting (Mis)information 
  511. May 91. 11. Expecting the Unexpected Mayday! 
  512. Jun 91. 12. The Risks With Risk Analysis, Robert N. Charette 
  513. Jul 91. 13. Computers, Ethics, and Values
  514. Aug 91. 14. Mixed Signals About Social Responsibility, Ronni Rosenberg 
  515. Sep 91. 15. The Not-So-Accidental Holist 
  516. Oct 91. 16. A National Debate on Encryption Exportability, Clark Weissman 
  517. Nov 91. 17. The Human Element 
  518. Dec 91. 18. Collaborative Efforts
  519. Jan 92. 19. What's in a Name?
  520. Feb 92. 20. Political Activity and International Computer Networks, Sy Goodman
  521. Mar 92. 21. Inside ``Risks of `Risks' ''
  522. Apr 92. 22. Privacy Protection, Marc Rotenberg
  523. May 92. 23. System Survivability
  524. Jun 92. 24. Leaps and Bounds (Leap-year and distributed system problems)
  525. Jul 92. 25. Aggravation by Computer: Life, Death, and Taxes,
  526. Aug 92. 26. Fraud by Computer
  527. Sep 92. 27. Accidental Financial Losses
  528. Oct 92. 28. Where to Place Trust
  529. Nov 92. 29. Voting-Machine Risks, Rebecca Mercuri
  530. Dec 92. 30. Avoiding Weak Links
  531. Jan 93. 31. Risks Considered Global(ly)
  532. Feb 93. 32. Is Dependability Attainable?
  533. Mar 93. 33. Risks of Technology
  534.  
  535. ------------------------------
  536.  
  537. End of RISKS-FORUM Digest 14.25
  538. ************************
  539.