Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 18
OTHER METHODS Three additional methods are worth mentioning, though they do not fit neatly into the scheme above. They include the dialog specification procedure, experimental programming, and case studies. The dialog specification method is a global procedure that cuts across the first several steps outlined above. It is a procedure that prescribe. a method for developing an interactive dialog with a system and sets a design standard. The method includes task analysis and flow charting of user activities as well as standard means of communicating the specific design requirements to the programmer. The design standard describes acceptable screen layouts, interactive devices and how they are to be used, acceptable commend language syntax, etc., down to a level of detail compatible with the specificity of the range of applications to which it is intended to apply. For example, if all designs concerned telephone management applications, the specification would deal only with the range of tasks in this domain. These specifications are built from human factors principles as well as accumulated data from user testing. Pew et al. (1979) describe this method more fully. Experimental programming is similarly a more global method for designing systems and interfaces. It is a more flowing, adaptive technique involving users , designers, and progra - rs (sometimes all in the same person). Someone builds a prototype of a new system with same fraction of the functionality and some fraction of the user interface in place. This prototype is then used by a variety of programaer/usere who generate suggestions for new features and suggestions for revisions for exist- ing functions. As many suggestions as possible are incorporated into the prototype' the good features 18

OCR for page 18
19 survive, poor features disappear . Occasionally, when new features are incompatible with the old, a competing prototype is built. Sometimes someone merges the most popular ideas from both. This method is very informal. The only rules for its application are that everyone's opinion get a fair hearing and that anyone in the com~un- ity can implement a change. This method allows for progressively better understand- ing of the application as well as the computation and interface requirements. Its weakness lies in its casual nature and that it relies on the opinion of users, most of whom are programmers; its strength lies in its explora- tory, evolutionary, democratic nature. One well-known product that benefited from experimental programming is the EMACS text editor (Staliman, 1980), which pioneered such concepts as user-customization, on-line documenta- tion, and a particular command style. In addition, Teitelman (1972) used experimental programing to develop the concept called DWIM (~Do What I Mean.) , which included a set of facilities that automatically corrected predictable errors. A third global technique goes under the rubric of case stud i es . Case studies involve observation and analysis of a singe user, group, or project. The information collected may range from informal, subjective impressions to detailed quantitative data. Because case studies involve no comparison or control group, they are not very useful in infer r ing causality. As a result they are not appropriate for building a data base of basic research results from which to construct theories and principles. They can, however, be extremely useful for gaining insights when one is first investigating an area of interest and for providing concrete demonstrations of the use of new methods and tools. An example of a case study in which new insights were gained about a domain involved the use of the Ada system. The purpose of the study was to understand the problems that are likely to arise when the system is first intro- duced into an organization (Bailey et al., 1982) . A second case study involved a demonstration of new methods for designing system to be embedded in special purpose hardware, such as airplanes and tanks (Britton et al., 1981). The documentation and related products produced by this case study provide examples that others may use in trying to apply the methods to their own software projects. Brook. (1975) documents the use of a case study in a large computer programming project. And, the

OCR for page 18
20 case study by Baker (1972) was extremely influential in leading the structured programming revolution. Others include Gould and Boies (1978, 1983, 1984), and Heninger {1980) . 1