i
April 17, 1967
BOOK PROPOSAL
Tentative Title: HUMAN FACTORS IN COMPUTER SYSTEM DESIGN |
Author: Lee A. Friedman |
System Development Corporation |
Santa Monica, California |
Table of Contents
|
page |
1. Defining The Man/Computer Interface Design Problem |
1 |
1.1 The Information Gap |
1 |
1.2 The Information Gap In Man/Computer Interface Design |
1 |
1.3 The Information Gap In Current Man/Machine Design |
2 |
2. Why This Book Is Needed |
5 |
3. Purposes of This Book |
6 |
4. Sources of Information |
7 |
5. Audience For the Book |
8 |
6. Present Statue and Schedule |
9 |
7. Author's Background |
10 |
8. Annotated Outline of Chapters |
14 |
1
April 17, 1967
1. Defining The Man/Computer Interface Design Problem
1.1 The Information Gap
A phenomenal number of computerbased information systems have been designed
and installed during the past two decades. All of these ubiquitous systems
use man in some capacity as master or servomechanism, as manager or operator,
but not always in a manner that benefits man, the computer or the system.
Concern for man was not omitted by system designers, although it does
seem man was taken for granted in many situations. The fault for any of
man's interface problems did not lie exclusively with the system designer.
More to the point, it seems that information (standards and criteria) may
not have been available to designers on the range and limits of man's abilities
and job functions as could be applied to computer systems; information
that would have helped to improve the utilization of man and of the computer
programs and equipment with which he had to interface.
The consequences of this situation, of course, led to the misuse of
man and the computer, the mixallocation of jobs, to the detriment of efficient
system operations. This information gap resulted in conditions that placed
greater constraints on, and required more of, man than on the computer
programs and equipment.
1.2 The Information Gap In Man/Computer Interface Design
System design technology has been notably concerned with the correct
blending of machine-with-machine with operational requirements with man,
who usually ends up just hanging on. This latter condition is probably
based on designers' intuition, culled from inspirational literature, that
that adaptable animal man can easily (or should easily) adjust to the demands
of the machine to which he is assigned. Man becomes the distressed partner
a fault in the system, when he cannot adjust to a constraining and demanding
machine whose method of operation might contradict the problemsolving procedures
to which he is accustomed.
Absent from system design technology, then, is information (standards
and criteria) that will help to mitigate man/computer incompatibilities,
and that will prescribe to designers ways to better apportion system operation
tasks between man and computer. The following statements describe the three
major man/computer information gaps that have engendered design faults
(and the basic subject matter for the proposed book).
1. Computer system designers (and human factors engineers, too) lack
structured technical information on how a computer's information processing
function the computer program, augments man's own information processing,
decisionmaking, problemsolving faculties. The computer program's
2
purpose is to extend and complement man's mental (data transformation)
faculties. As such, program design must be scrutinized and evaluated in
terms of man's mental limitations and capabilities. The computer program
designers, for example, should ask the generic questions: "What are
man's mental processes?" "Which part of man's mental processes
and activities should be apportioned to computer programs because of man's
limitations or because the computer can do a better job?"
2. Computer system designers also lack sufficient information that prescribes
how and when specific computer components and peripheral gear (typewriters,
card readers, tapes, core) can best be used to supplement man's information
processing activities. Equipment utilization and allocation, too, must
be scrutinized in terms of man's information processing and transfer function
limitations and capabilities. Thus, the designer should ask himself such
questions as, "How and when should man and/or the typewriter be used
for information transmission? How and when should the card reader and/or
typewriter be used to facilitate man's (input) dialogue? How and when should
man and/or computer core be used for sorting data?"
3. Finally, computer system designers lack information on how and when
to design computer system operational requirements (input, output, sorting,
merging, etc.) according to system functions (manage, control, operate,
maintain, use). Insufficient standards and criteria can cause the allocations
of data processing jobs or tasks to positions (whithin a functional area)
that are not within the scope of their responsibilities or training experiences.
The levels of job performance and data requirements for a computer system
manager, for example, are distinctly different from that of a scientist-user
or a computer operator.
As a result of these information inadequacies (but primarily the first
one) many computer systems place untold constraints on man's abilities,
thereby causing man often to err, and consequently, systems often to fail.
To the designer, some troublesome interfaces may seem on the surface to
be trivial. But it is fact, not hypothesis, that the cumulation of these
so-called trivia actually hinders and degrades the accomplishment of even
simple jobs.
Each system component-programs, equipment and man- has its known functions,
limits and capacities. The data on man must be considered in conjunction
with computer capabilities to hopefully achieve a more effective system.
Human performance is the least reliable in computer systems operations,
and until system designers learn how and when to use man in conjunction
with the computer, the problem will persist.
1.3. The Information Gap In Current Man/Machine Design
The paucity of information on man/computer interface requirement and
criteria within the general field of man/machine system design poses a
peculiar
3
April 17, 1967
problem, viz., the design criteria and standards that should be derived
from man/computer interface requirements are absent. Consequently, there
are design criteria,standards and specifications that cannot be considered
during system planning and advanced system design.
Much of the available man/machine literature that bears some relationship
to the problem of man/computer task allocation or apportionment deals exclusively
with the criteria for man's information requirements and display formats.
There are few studies dealing with pertinent man/computer decision allocation,
the use of natural languages, and how man's information processing capabilities
should be fully or semiautomatically accomplished.This still leaves a large
chasm to be covered.
There is no literature or data that tackles the practical job of prescribing
what criteria to use to allocate man/computer program tasks at the design
implementation level. The pertinent literature on man/machine design that
currently exists only provides gross design axioms concerned with machines
other than computers. Any suppositions about computers have merely been
generalized from these constructions.
For example, it is stated in human engineering literature that: man
is good at detection, sensing, perception,judgment, induction, long term
memory; machines are good at speed, power,simultaneous operations, computations,
repetition. Most of these constructions become moot points when applied
to man/computer task allocations and they are ineffectual when used as
guides for programming a computer to augment man's mental faculties.They
easily direct attention away from the theme of allocating portions of tasks
woman and to the computer.
The impression given is that man is good at one thing and the machine
isn't. Presumably, this is not what is intended. But the impression is
given, for example, that man is good at sensing and detection within the
scope of his capabilities and that the machine surely cannot compete with
this.
Man can sense an approaching ship at sea, but so can a radar antenna.
The antenna and man can calculate speed and direction, but the antenna
(its computer) can do it faster and more accurately. The task elements
here are: to sense/detect, calculate, decide,act (report). The problem
is to apportion the task elements according tothe capabilities of each
and according to the environment. Both man and the antenna can perform
a sensing and reporting task, but what part of the sensing task should
man be apportioned? (Man can look for a ship and then point the antenna.)
Human factors engineersfor their part, by following the man/machine
literature have the task of assisting in the design of those components
of the machine that man will see, touch and sense "knob and dial"
design some
4
April 17, 1967
call it. Their expertise lies in this area - making the marriage more
palatable by "fixing up" the machine's components and facade
so that man and machine are more psychophysiologically compatible; so that
man will make fewer errors when reading a dial or manipulating a manual
control.
What happens when this type of design and its related criteria are applied
to the design of a man/computer system? It seems that when system designers,
in conjunction with human factors engineers, concern themselves with man/computer
interfaces they direct their attention to the equipment that man will see
and touch, or which requires man's services. This, of course, means the
design of consoles, CRT displays, the switches man will handle and the
registers he will see. The interior of that calculating "black box"
is of little concern.
Similar information gaps exist for the computer program designer and
design implementer, viz., the lack of information on computer system user/operator
limitations, capabilities and design criteria. Computer program design
books and manuals usually stipulate people functions in such gross generalities
as, "Simplify operator actions where decision-making is required,"
that they become meaningless as design guidelines. Hence, the implementation
of human interface design will be left solely up to the programmer. Programming
manuals sorely lack explications of man/computer interface requirements,
tradeoffs and capabilities.
By no means is what the programmer decides unusable, although in this
writer's experience there have been several such programs designed and
delivered (and eventually some were ignored by the customer). Rather, what
the programmer does produce frequently spawns operating difficulties for
the user. Some customers get used to clumsy operating requirements, and
then system reliability is correlatively reduced.
The proposed book is therefore needed by various computer system designers
to cover the man/computer information gap, and to provide additional design
criteria.
5
April 17, 1967
2. Why Thie Book Is Needed
It is indeed unfortunate that in these past two decades no book on man/computer
task allocation or apportionment as the one being proposed hasbeen produced.
To cover this hiatus in computer system design philosophy a book is required
that will express methods for improving task allocation or apportionment
between man andcomputers, based on a disclosure of man's mental and psychologicall
imitatione vis-a-vis the computer and its programs, and that will
serve as practical counsel for the integration of man into the computer
system.
Such a book should supply case histories to illustrate concrete examples
ofthese actions. In addition, such a book should supply methods for testing
the computer system to insure the optimization of human reliability. Finally,
such a book should provide guidelines for information flow and communciation
among the various system designers and the customer. The proposed book
will provide much of this material.
6
April 17, 1967
3. Purposes Of The Book
The following statements summarize the mayor purposes of the book:
1. To supply necessary and sufficient information to computer system
designers on the vital functions, capabilities and limitations of man as
they should be applied to computer system design, to optimize human and
system reliability;
2. To indicate effective methods and salient criteria for allocating
or apportioning information processing, decision-making, problem-solving
task elements between man and computer components; and to provide criteria
that can be used to effectively determine levels of automation, standardization,
system control and tradeoffs;
3. To illustrate, via the case history method, how ineffective computer
system and computer program designs have degraded system operations and
impaired human performance; to describe the consequences of such design;
4. To provide guidelines on required system design interfaces (communication,
information) among system planners, designers, computer programmers, human
factors engineers and the customer;
5. To provide rules and guidelines for testing computer systems to insure
the optimization of human reliability and reduce human errors; and,
6. To provide general standards and conventions that can be used for
man/computer task allocation/apportionment according to stipulated system
functions (such as management, professional,operator).
7
April 17, 1967
4. Source of Information
The information base for this book will be derived from several sources.
1. From the practical (design and production) experiences of knowledgeable
computer program designers and human factors engineers.
2. From verbal and written reports made by users and operators of information
systems (e.g., error rate and human performance reports).
3. From pertinent research on man/computer program interfaces conducted
by various organizations: SDC, Mitre, RAND, and Army Personnel Research
Office.
4. Other research reports on material tangential to man/computer interface
will be reviewed for pertinency. This usually includes other research in
engineering psychology and experimental psychology.
5. From data collected by this writer during the past five years pertaining
to computer system design.
Human performance standards will be based on generalizations made from
psychological research that can be applied to man in information systems.
Justifications or reasons for certain task allocations between man and
computer program will be based mostly on the practical experiences of human
factors engineers, programmers and systemusers. It is certainly hoped that
most of the material presented (e. g.,task allocations and performance
limitations) will become hypotheses for further research in order to refine
such statements.
This author believes that most of the standards, guidelines and objectives
presented will be applicable to information system design for at least
5 to7 years. Some of the criteria and performance standards should be longer
lasting. If current practices persist, though, the material will be good
for at least 25 years. But as programming technology and information on
man's capabilities becomes more sophisticated, there is no question that
some, or even much,of the contents will eventually be obsolete. Because
of the limited scope of the book, the author will not deal with man and
computer program design in future systems, viz., artificial intelligence
or heuristic programming.
8
April 17, 1967
5. Audience For The Book
1. This book can provide simple, commonsense guidelines to computer
programmers* when they are faced with the job of deciding what elements
of information processing tasks can be effectively allocated to man and
to computer systemcomponents (e.g., computer programs, displays, console).
They will be provided with criteria for judging the extent or level of
tradeoffs that can be permitted without degrading design or potential use.
Information on human performance limitations will enable them to quickly
judge whether they are designing for or around the human beings in the
systems. The book does not tell programmers how to program; it does, however,
suggest ways that computers and programs could be more efficiently utilized.
2. The information in this book can supply an understanding of computer
program design for the human factors engineer who has spent
most of his career designing machine components. The information can provide
him a means for judging computer system design efficiency and adequacy
from the human point of view that will enable him to better ensure human
reliability. In addition, much of the material can provide hypotheses for
research in this area.
3. The data in this book can also be used as a computer program quality
control medium by system design managers, to ensure that the computer
programs meet with system operational requirements from the customer's
point of view, and insure that man/computer criteria are included in design
specifications.
* A generic term used throughout the book to depict computer systems
advanced designers, operational designers and design implementers (e.g.,
coders); i.e., those disciplines responsible for the design of computer
programs and equipment utilization.
9
April 17, 1967
6. Present Status and Schedule
1. Status
Almost all required data has been collected and filed. Only a small
portion of the raw data on human errors, reliability and uses of natural
language have yet to be obtained. These are available locally, and will
be obtained shortly.
2. Schedule
April, 1967 : Complete data collection.
September, 1967: Complete first draft. Various chapters will be completed
before this data and will be reviewed internally.
October, 1967 : First draft of book for external and internal review.
November, 1967: Second draft of book for external review.
10
April 17, 1967
7. Author's Background
Current - Human Factors Scientist, Assoc. System Development Corporation.
Responsibility: Writing the book: HUMAN FACTORS IN COMPUTER SYSTEM DESIGN
on a corporate grant (Class I)
1964-1967- Human Factors Scientist, Assoc., Member, Personnel Subsystem
Analysis and Requirements Design Staff, Personnel Subsystem Group, Space
Programs Department, System Development Corporation, Santa Monica, California.
Responsibilities:
--Human Factors engineering consultation on computer program and information
system design for the Space System Division's (AFSC) Satellite Control
Facilities contract. Worked on computer program design teams and was responsible
for man/computer program function allocation and human interface requirements
(e.g., designing a radio frequency interference prediction program). Developed
user's manuals and procedures. Designed training programs and conducted
exercises. Worked on a teamresponsible for designing future Satellite Control
Facilities (SCF) information subsystem, operational control system philosophy
and configuration, operating requirements and personnel requirements.
--Organizational and personnel subsystem design for future Satellite
Test Center (at Sunnyvale) configuration. Responsible for the design of
personnel and organizational requirements, information subsystem operating
requirements and philosophy, workspace and equipment allocation.
--Human factors consultant to joint SSD/Aerospace Corporation committee
on future STC configuration design. Consulted on facilities design (with
architectural contractor), organizational and personnel requirements design,
and equipment allocation.
--Human factors member, joint SSD/Philco/Lockheed committee on human
engineering equipment design criteria for SCF systems.
--Developed design requirements and methodology for computer program
operational procedures; developed human engineering requirements for computer
program design.
--Performed liaison work with SSD personnel on information system procedure
document requirements and production.
--Responsible for group internal training on satellite and ground support
system telemetry, tracking and command functions.
11
April 17, 1967
1963-1964 - Technical Ass't. to Group Head, Operations and Training
Group, Space Programs Department, System Development Corporation, Santa
Monica, California
Responsibilities:
--Responsible for group administrative/technical matters. Developed
work plans, design documents, work schedules and manpower costing.
--Human factors engineering consultation on computer program design.
Designed, developed and produced various computer program operational procedures
documentation for use by STC operations personnel. Directed projects in
these areas.
--Organizational and personnel subsystem design for the STC information
system. Performed task analyses, link analyses, function analyses and developed
STC personnel planning information (QQPRI) reports on required organization
and personnel configurations within the information subsystem, based on
new system design specifications.
--Human factors member, joint SSD/Aerospace/Philco/Lockheed/SDC Human
Engineering Committee. Performed several "troubleshooting" analyses
of system operations to ascertain operating faults and constraints. Performed
liaison work with SSD on product requirements.
1962-1963 - Human Factors Scientist, Assoc., Operationa and Training
Group, Space ProgramsDepartment, System Development, Santa Monica, California.
Responsibilities:
--Developed work plans, design methodologies and production schedules
for SCF computer-based information system organizational and personnel
requirements documentation, operational procedures documentation, and system
task analyses. Produced organizational and personnel requirements documents
(personnel planning information) and operational procedures for the computerbased
system.
1960-1962 - Control Section Head, Personnel Subsystem Group, Strategic
Air Command ControlDepartment, System Development Corporation, Paramus,
New Jersey.
Responsibilities:
--Supervised the design and development of SAC control system organizational
and personnel requirements, and information system utilization procedures.
Directed initial work on system task and functions analysis. Performed
liaison work with SAC personnel in the development of personnel requirements
and procedure design.
12
April 17, 1967
1956-1960 - Instructor in Sociology, Long Island University, College
of Liberal Arts and Sciences, Brooklyn #1, New York.
Responsibilities:
--Taught all undergraduate and graduate courses in sociology, social
research and social psychology. Member graduate thesis committee in sociology
and psychology. Directed various social research projects and was undergraduate
student advisor in sociology. (I also attended graduate school at this
time).
1955-1956 - Consultant, Motivation Research, Benton and Bowles Advertising
Agency, NewYork City.
Responsibilities:
--Performed psychological analyses on attitude and opinion surveys for
large oil company client.
1951-1955 - Attended undergraduate and graduate school.
1951-1953 - News Correspondent, Fairchild Newspapers, Akron (Ohio) News
Bureau.
Responsibilities:
--Wrote news articles and represented the Fairchild News staff in the
Akron, Ohio area.
1949-1951 - Chief Copy "Boy", Fairchild Publications, East
12th Street, New York City.
Responsibilities:
--Supervised copy staff and trained new copy personnel in Fairchild
"style".
1946-1949 USAF service
EDUCATION:
B. A., Exper. Psychology, Kent StateUniversity, Ohio 1954
M. A., Sociology, Kent State University, Ohio 1956
Ph.D candidate, Columbia University, N.Y.C., 1955-1958 with all course
work completed in sociology.
PUBLICATIONS:
1. "Use of Comic Effect to Control Dysfunctional Behavior in Outer
Space", Human Factors, August, 1963
2. "The Space Jester," FM & Fine Arts magazine,
December, 1964.
13
April 17, 1967
3. "The Design and Production of SystemProcedures", in The
Design and Production of Computer-Based-Information Systems, ed. by
P. E. Rosove (to be published by Wiley, 1967). Included section on human
factors engineering of computer program design.
4. System Development Corporation publications: authored approximately
60 technical publications.
14
April 17, 1967
Annotated Outline of Chapters*
HUMAN FACTORS IN COMPUTER SYSTEM DESIGN
Table of Contents
PART I. THE NEED FOR HUMAN FACTORS ENGINEERING IN COMPUTER SYSTEM DESIGN
Chapter 1. Introduction
Chapter 2. How is Human Factors Engineering Related to Computer System
and Computer Program Design?
PART II. THE USES AND MISUSES OF MAN AND THE COMPUTER
Chapter 3. Capacities and Capabilities
Chapter 4. Human Reliability
Chapter 5. The Proper Use of Man: Allocating Task Elements
Chapter 6. The Misuses of Man: Case Histories
PART III. A MANUAL FOR THE COMPUTER PROGRAMMER
Chapter 7. Human Performance Guidelines
Chapter 8. Testing the Computer Program for Human Use
Chapter 9. Standards and Conventions for Task Allocation
*Book will contain approximately 200 pages
15
April 17, 1967
PART I. THE NEED FOR HUMAN FACTORS ENGINEERING OF COMPUTER SYSTEM AND
PROGRAM DESIGN
Chapter 1. Introduction
The purpose of this chapter will be to increase the computer system
designer's and computer programmer's awareness of the importance of computer
operator/ user's capabilities, capacities, limitations and operating requirements.
Section 1
1. A discussion of the consequences of a lack of understanding and implementation
of man's capabilities and capacities. How such a gap in knowledge and technique
can lead to increased costs, extended personnel training time, system degradation,
design retrofits, and cause a standstill in the stateoftheart and the business
of designing computer programs.
2. A discussion of the role of various system designers; that is, the
participation in the design and development process with discussion and
contributions and nominal limitations of each group: top management, user
technical specialists, system analysts, computer programmers, human factors
specialists, etc.
3. A discussion of some of the major causes of ineffective design, such
as poor design management, insufficient design analyses prior to design
commitments, inadequate "system" orientation leading to an improper
blending of man/machine/computer program; the egoinvolvement of computer
programmers with their offspring; the inadequate interactions and information
flow among designers, and between top level customer management and designers.
Section 2
3. Definitions of basic terminology used in this book and types of systems
that will be considered and their definitions.
4. The purposes of this book and why it is needed.
5. Ways in which to use this book.
16
April 17, 1967
Chapter 2. How is Human Factors Engineering Related to Computer System
and Program Design?
The purpose of this chapter is to describe how human factors engineering
should be used for the design, development, and validation testing of various
types of information systems components (programs, equipment usage).
1. A discussion of the ways in which the human factors engineer can
assist the designer and programmer during system planning, advanced design,
operational design, and implementations and testing. And, how the designer
and computer programmer can use the expertise of the human factors engineer
during all stages of design and production.
2. A discussion of the various tools and methods used by the human factors
engineer and how he uses them. For example, there will be a discussion
of functions and tasks analyses, human interface requirements analysis,
tradeoff and link analyses, personnel and organizational requirements,
etc., and their particular role in information system design. For the human
factors engineer, there will be an explanation of how to apply these techniques
to information system design.
3. A discussion of the types of information needed from the computer
programmer by the human factors engineer to adequately perform his several
design tasks, and the types of information the human factors engineer can
supply to the program designer for each type of information system being
designed.
17 - Blank
18
April 17, 1967
PART II. THE USES AND MISUSES OF MAN AND THE COMPUTER
Chapter 3. Capacities and Capabilities
The purpose of this chapter will be to provide specific data to computer
system designers and programmers (and human factors engineers) on man's
limitations and capabilities as applied to the design of computer program
and information system operations.
1. Data will be provided on the limits and ranges of man's abilities,
skills, aptitudes, and qualifications for consideration when designing
the man/computer interface. (There will be no discussion, however, of the
psychophysiological rudiments of man/machine interfaces; e.g., the limits
of psycho/motor/capabilities or vigilance in a tracking task. Vigilance
will be discussed, though, in terms of monitoring program operations.)
2. The data in this chapter will be arranged into two general categories,
and each factor discussed will be strictly related to man/computer tasks
only.
Section 1. Mental Senses/Capacities
1) Perception
2) Memory/Storage/Retention
3) Vigilance
4) Fatigue
5) Sensing
6) Attention
7) Identifying
8) Detecting/Discriminating
9) Interpretation
10) Speed
Section 2. Problem-Solving Capabilities
1) Goal-Setting
2) Judgment
3) Fallibility
4) Certitude
5) Control
6) Ambiguity
7) Flexibility
8) Motivation
9) Decisionmaking
10) Information processing
11) Feedback/feedforward
12) Coding
19
April 17, 1967
3. With these concepts and variables in mind, the chapter will be concerned
with how man can be expected to perform within various system contexts
according to his functions and capabilities. The types of users, their
skills, job requirements, etc., capacities and capabilities will be defined.
(For example, the subject of "Feedback" material will be concerned
with the need for feedback, reasons for feedback and consequences of lack
of feedback.)
4. Some discussion will be presented on the consequences to system operations
when specified human capability standards are ignored.
20
April 17, 1967
Chapter 4. Human Reliability
The purpose of this chapter is to identify and explain human performance
standards, requirements, conventions, and limitations within the context
of computer system operations. Included will be a discussion of ways of
optimizing human reliability, and the problems encountered when human performance
limitations are exceeded. The discussion will also illustrate how these
standards, etc., should be applied to various system functions(e.g., the
allocation of decisionmaking functions to man and to computer) within various
types of information systems; (e.g., timesharing, military command/control,
document retrieval, scientific, engineering, education, etc.). Much of
the data will be derived from actual design and operational experiences.
Section 1. Human Reliability
1) Performance Standards (workload, pacing)
2) Human Errors and Error Rates (human induced errors)
3) Design induced Errors (lack of information and other sins of omission
and commission)
4) Effects of Human Error on System
5) Error Recovery Techniques
Section 2. System Functions
1) Operate
2) Maintain
3) Control
4) Monitor
5) Use or Manage
Section 3. Human Attitudes, Skills and Requirements
1) Language (dialogue that should be used in various system contents)
2) Decisions (that man makes and that computers can make)
3) Transfer Function
4) Actuating/Amplifying
5) Manpower and Other Personnel Requirements
6) Skills (related to computer functions such as editing, computations,
storage, sorting, etc.)
21
April 17, 1967
Chapter 5. The Proper Use of Man: Allocating Task Elements
The purpose of this chapter is to introduce the "principle of complementary
allocation* of task elements." As complex as it may sound, this principle
merely purports to answer the question, "What portions of a single
information processing task should be "justly" allocated to man
and what portions to the computer?"
1. "Task" is defined as it should be applied to information
systems in particular. Explains how the traditional use of task (as in
"task analysis") can hinder the proper allocation of task elements
to man and computer programs.
2. Various data processing logical functions and operating
methods will be identified and discussed in terms of man's own processing
capabilities, and then recommendations will be made for allocating task
elements. Logical functions are those computer program operations that
augment man's capabilities. Operating methods are concerned with the proper
utilization of input/output and processing equipment according to man's
capabilities and his job requirements.
3. The discussion will, for each concept, indicate the criteria and
rationale for applying the principle of complementary allocation. Thus,
we could ask such questions as: how should a data sorting task be allocated?
Should data be first provided on a punched card? If yes, should these cards
be hand sorted? machine (EAM) sorted? or sorted by both man the computer?
How? What are man's limitations in terms of requirements and criteria for
sorting? What types of constant or variable errors can he make? And their
consequences. What are the allowable tradeoffs? When should man be allocated
a complete sorting task that could be more easily accomplished by a computer?
And vice versa.
4. The criteria for judging the effectiveness of task element allocation
will include: (a) criticality (of task, mission), (b) time factors, (c)
accuracy, (d) cost (manpower, training, etc.), (e) operating efficiency
(or automation), (f) standardization, and (g) control (types, centralized,
decentralized, etc.).
5. The basic discussions will be arranged in the following manner and
will include the following concepts:
*Although the term "allocations," meaning to distribute or
assign, has traditionally been accepted and will probably remain so; the
term "apportionment," used frequently in this proposal has a
meaning closer to what is meant here: "to divide and assign in just
proportion."
22
April 17, 1967
Section 1. Logical Operations and Functions
1) Inputs
a. Sorting data*
b. Merging data
c. Coding Information (cards, messages, mnemonics, etc.)
d. Language (dialogue)
e. Information Retrieval (data request techniques)
f. Editing (conversions)
g. Verification
2) Information Processing
a. Utility
(1) Merging (files, data)
(2) Sorting(data)
(3) Memory Storage
(4) Subroutines: buffering, indexing, queuing, table lookup, etc.
(5) Control (executive)
(6) Validation (e.g., data limits)
(7) Diagnostics
[handwritten] (8) File Maintenance
b. Operational
(1) Decision Algorithms
(2) Error Detection
(3) Error Recovery
(4) Updating
(5) Data Reduction
(6) Data Arrangement
(7) Data Processing Control
(8) Data Computations
3) Outputs
a. Language
b. Format
c. Contents/Mnemonics/Codes
d. Data Transmission and Distribution
e. Information Retrieval
f. Dynamic/Static Displays
g. Editing
*For example, will discuss the techniques man and computers use for
sorting; and will be related to Chapter 3's discussion on man's "identifying,"
"attention," and "interpretation" capabilities.
23
April 17, 1967
Section 2. Method of Operations
1) Inputs
a. Cards (format, content, usage, sorting)
b. Tapes (usage, merging)
c. Console (switches, data inputs)
d. Typewriter/Flexowriter/Keyboards
e. CRT, (uses, formats)
f. Disks, Drums (data storage, format)
2) Information Processing
a. Disks (use during processing)
b. Drums (format, contents, usage)
c. Tapes (format, contents, usage)
d. Core/Memory (multiprocessing/multiprogramming)
3) Outputs
a. Cards
b. Tape
c. Typewriter
d. Printers
e. Plotters
f. Displays
24
April 17, 1967
Chapter 6. The Misuses of Man: Case Histories
The purpose of this chapter is to illustrate the consequences of "poor"
allocation of task elements between man and computer program.
1. The case history method will be used to provide examples of imperfect
computer system designs and its effect on computer system operations. Various
examples will be chosen to illustrate how a pertinent human performance
deficiency was engendered.
2 After each case, a discussion will be presented on how these particular
computer programs significantly degraded information system operations,
increased human error, overloaded users, increased manpower requirements
and hindered the achievement of tasks and objectives.
25
April 17, 1967
PART III. A MANUAL FOR THE COMPUTER PROGRAMMER
Chapter 7. Human Performance Guidelines
A short chapter that outlines, probably in chart form, man's capabilities,
capacities and limitations according to:
1. The type of information system being designed (document retrieval,
scientific, timesharing, command and control, educational, etc.) and,
2. The type of human functions to be performedcontrol, use, operation,
maintenance, etc.
26
April 17, 1967
Chapter 8. Testing the Computer Programs for Human Usage
The purpose of this chapter is to indicate the importance of validation-testing
of computer systems and programs to insure optimum human reliability and
reduce potential human errors, before program delivery to a customer.
1. A discussion of the reasons for exercise/testing computer programs
in a simulated mode (near-real operating conditions) to further insure
that computer system operating requirements are compatible with potential
user operational requirements and personnel requirements.
2. A description of test design methods and principles that will allow
the programmer to integrate human reliability testing with his program
validation. The following test procedures will be discussed.
a. Designing the test exerciseparticipants, materials, reports, rules.
b. Setting up test criteria and standards.
c. Testing all human interfaces and operating instructions.
d. Stressing the program according to human performance limitations.
e. Checking adequacy of feedback and feedforward mechanisms, and recovery
procedures.
f. Evaluating the exercise run, evaluating human performance and reliability,
and making design changes (including discussion of allowable tradeoffs).
27
April 17, 1967
Chapter 9. Standards and Conventions
1. The purpose of this chapter is to provide simple guidelines for indicating
what, when and how task elements should be allocated
to either programs and/or man. This chapter is a working summary of Chapters
3, 4, and 5. It will provide easy access to relevant design arguments in
those cases where man is a component of an information system. There will
be no discussions of human performance limitations, but standards will
be derived from them.
2. The data will be arranged in a format illustrated in the attached
table. An example of table contents is also supplied.
Explanation of Table:
Column 1. System Functions: These represent the major functions (not
people) that are involved with computer system operations. Each function
has some purpose for which information processing tasks must be allocated
in a certain way. Thus, what can be required of a professional/technical
function may not always be required of management functions for each has
peculiar job and data requirements.
Column 2. This column will include indications of computer logical operations
(computer program functions) and operating method (equipment utilization).
Column 3. Standards: These are standards that will be based on man's
limitations and capabilities as well as the capabilities of the computer
system component. Thus, for each logical operation specified there will
be indicated the performance limitations of man, and the operating capabilities/
limits of the computer.
Column 4. Conventions: These are the normally accepted ways of performing
some task and is based on such things (for man) as "population stereotypes"
or general procedures for doing a job to which man is accustomed; and the
most efficient way for a computer component to perform some task that requires
a human interface.
28
April 17, 1967
3. Examples of Table Contents
Logic Operations: Input
Computer Operator: Sorting Data
Standards: