Human Factors in System Design, Development, and Testing
eBook - ePub

Human Factors in System Design, Development, and Testing

  1. 264 pages
  2. English
  3. ePUB (mobile friendly)
  4. Available on iOS & Android
eBook - ePub

Human Factors in System Design, Development, and Testing

Book details
Book preview
Table of contents
Citations

About This Book

Human Factors in System Design, Development, and Testing describes engineering system design as a behavioral process, a process which raises questions the designer must answer. It focuses on the concepts underlying the design process, culminating in a behavioral theory of the design process. Special effort has been made to depict human facto

Frequently asked questions

Simply head over to the account section in settings and click on “Cancel Subscription” - it’s as simple as that. After you cancel, your membership will stay active for the remainder of the time you’ve paid for. Learn more here.
At the moment all of our mobile-responsive ePub books are available to download via the app. Most of our PDFs are also available to download and we're working on making the final remaining ones downloadable now. Learn more here.
Both plans give you full access to the library and all of Perlego’s features. The only differences are the price and subscription period: With the annual plan you’ll save around 30% compared to 12 months on the monthly plan.
We are an online textbook subscription service, where you can get access to an entire online library for less than the price of a single book per month. With over 1 million books across 1000+ topics, we’ve got you covered! Learn more here.
Look out for the read-aloud symbol on your next book to see if you can listen to it. The read-aloud tool reads text aloud for you, highlighting the text as it is being read. You can pause it, speed it up and slow it down. Learn more here.
Yes, you can access Human Factors in System Design, Development, and Testing by David Meister,Thomas P. Enderwick in PDF and/or ePUB format, as well as other popular books in Computer Science & Human-Computer Interaction. We have over one million books available in our catalogue for you to explore.

Information

Publisher
CRC Press
Year
2001
ISBN
9781135670405
Edition
1

1
An Overview of System Development

This book logically begins with a list of questions regarding human factors (HF) in design, development, and testing. Some of these questions cannot be answered at all, many of them can only be answered partially, but all of them require analysis.
The questions, which are discussed in the next section in greater detail, have merit not only because they can serve to organize the topics of the remainder of the book, but because answers to these questions help us improve the effectiveness of the HF specialist in system development.
A few definitions first. From now on, when we refer to the specialist, we mean the HF personnel working in design, development, and testing. We differentiate the specialist from the engineer (who may be one of several types: electrical, hydraulic, logistical, etc.) and designate him or her as the designer. Unless specified otherwise, we assume that the specialist is not the primary designer of a system (how much he or she contributes to the human-machine interface design undoubtedly varies), although he or she is probably a member of the design team. It is necessary to keep these two—specialist and designer—separate because the all-inclusive terms design and development tend to confuse their individual contributions. Also, rather than repeating the terms design, development, and testing throughout the book, we use the term design to refer to all these stages.
The questions for which we would like answers are:
1. What are the critical elements in system development, and who are the people involved?
2. How do designers design? What theories and models have been formulated to describe design and development?
3. What informational resources (e.g., design guidance, facts, data) do designers have, and how is the design guidance created? What information do designers want and need?
4. What is and should be the role of the specialist in system development? What information does the specialist require?
5. What are the criteria and attributes that distinguish a good design from one less good?
6. What should HF research do for system development, and what should be the characteristics of that research?
7. What are the significant differences between hardware and software design and between commercial and noncommercial design?
8. What should the user’s role be in system development? What information do we wish to secure from users, and how can it be elicited? How does user-centered design differ from any other kind of design?
9. What are the characteristics of the development process, and what theories have been constructed about it? What is the role of constructs like indeterminism and complexity?
10. What methods of analyzing design requirements and testing systems at various levels of complexity exist, and what information does each provide?
11. How does the organizational context (including the type of design problems to be solved) affect development?
12. How extensive are individual differences among designers and design practices, and what causes these differences?
It should be obvious that these questions are meta-level questions, and each subsumes a host of more specific ones.
This chapter is concerned with the nature of system development. For the individual specialist and designer, this is only a context for what he or she does at the design or drafting table. Although the overall developmental process affects what individual personnel do in the process, the effect may appear indirect or insubstantial. Nevertheless, because development as a whole does have an effect (however indirect) on individual design efficiency, it is necessary to examine what theorists have thought about it.
The nature of the equipment or system being designed (we use the general term system to represent all levels of equipment size and complexity) and the design problem presented also have an important effect. At a certain level of complexity, systems develop certain attributes they did not have at lower levels of complexity (e.g., automation, transparency, autonomy, etc), which must also be considered.

DEVELOPMENTAL ELEMENTS

The following are not in order of importance or in any logical sequence. Some elements may be more important than others, but this appears only with further consideration. Having briefly noted what the system development elements are, we examine each in greater detail later. Each of these elements implies a question: what, how, and why?

The Nature of the Overall System Development Process

We differentiate between the design process and system development; the latter subsumes the former because it is more comprehensive. For example, development includes continuing testing and evaluation of design outputs like software scenarios and hardware drawings. This results in iterative feedback loops that modify the original design. Design takes place in a context that is development and testing. Consequently, one must try to understand how the development context proceeds and affects the design of the individual equipment and system. One wishes to determine the structural characteristics of the design process because this understanding provides, to some extent, the ability to control them. We wish to know whether these processes are highly rational or influenced by irrational factors: Does design proceed from top to bottom, bottom to top, or both? What are the stages of development and characteristics of each? Is the design new, an updated version of an earlier system, or a redesign, and what effect does this have?

The Nature of the Equipment/System to Be Designed

We draw distinctions among systems, equipments, and products. An equipment is the individual work station; the system is composed of a number of work stations, all functioning together for a concerted purpose or mission. A product is something developed to perform a function; a product does not have a purpose or mission. These distinctions are hardly rigid; they meld into each other. For example, an automobile is certainly a product; however, although it is not a work station (or is it?), it is an equipment and may even be considered a system because it contains subequipments or modules. The same piece of hardware or software may be considered in one or other category depending on whether the individual encountering the device is an operator or technician. In general, in this book, we are concerned more with equipments and systems, but whether that device is fish or fowl depends on the user’s point of view. When it is difficult to even establish basic categories, the complexity of the problem we examine is revealed.
Whatever one wishes to call the device, however, certain factors determine what we call these machines (e.g., whether the machine performs a function or has a purpose given it by its operator—only a system has a purpose; an equipment has only a function). Another factor is whether a device is an output of another device, in which case we call it a product. For example, a can has a function (to enclose an object), but cannot be considered an equipment or a system, although the machine that makes the can is certainly considered an equipment.
Because we are interested in the process that leads to an output, but not necessarily the output itself, we confine ourselves to equipments and systems. Yet products are technologically derived, and more people are involved with products than are involved with equipments and systems. Yet one must confine oneself to what is feasible. Although it is difficult to make the distinction because the terms equipment and system are often used interchangeably, nevertheless the system has attributes other than those of the individual equipment and produces effects that are not those of the equipment. These system attributes include a greater degree of complexity (because of the multiplicity of equipments) and a mission.
Certain parameters associated with the nature of the equipment/system strongly influence the details of the design process. Among these are the degree of complexity and automation involved; the degree of transparency and autonomy; whether the system is to be military, industrial, or commercial; whether the system is to be largely hardware or software or both; and the specific type of system. Later we examine other factors associated with the equipment/system type that influence the design.

The Nature of System Design

This is a matter of high-level conceptualization or abstraction because no one individual can really define the design process; it is so big that only by making it into abstraction can one tie the process down. Hence, conceptualizations of the design process are like philosophical propositions—like the scholastic philosophers in the Middle Ages worrying about how many angels can stand on the head of a pin. Because the design process is under no one’s control (even that of the engineering manager), it contains everything, and consequently it is essentially our perception of phenomena.

The Characteristics of Design Personnel

Design (and here we include the specialist’s activities as well because he or she is intimately involved in the design team) is essentially idiosyncratic because it is informal (being a problem to be solved). Theorists can propose formal methods to be followed by the design process, but whether these are implemented depends on the individual designer, hence his or her skills, knowledge, and attitudes (and even such rules as exist). Other factors include the information a...

Table of contents

  1. Human Factors and Ergonomics
  2. Contents
  3. Series Foreword
  4. Preface
  5. List of Acronyms
  6. 1 An Overview of System Development
  7. 2 The Design Process
  8. 3 Design Methods
  9. 4 Design Practice
  10. 5 Information Resources
  11. 6 Software Design
  12. 7 The User
  13. 8 A Behavioral Theory of System Design
  14. References
  15. Author Index
  16. Subject Index