Human Supervisory Control

Slides:



Advertisements
Similar presentations
Chapter 15: Analytical evaluation
Advertisements

Chapter 14: Usability testing and field studies
Human Supervisory Control
Design, prototyping and construction
Modelling with expert systems. Expert systems Modelling with expert systems Coaching modelling with expert systems Advantages and limitations of modelling.
References Prof. Saul Greenberg, University of Calgary, notes and articles INUSE 6.2 and RESPECT 5.3 Handbook Prof. , University of , Notes and articles.
SENG521 (Fall SENG 521 Software Reliability & Testing Operational Profiles (Part 5b) Department of Electrical & Computer Engineering,
Human Aspects of System Design Introduction –Designing the human element into a system is paramount to its success –One error incorporated by the human.
The design process IACT 403 IACT 931 CSCI 324 Human Computer Interface Lecturer:Gene Awyzio Room:3.117 Phone:
SECOND MIDTERM REVIEW CS 580 Human Computer Interaction.
Human Supervisory Control Human-Centered Systems Engineering Design Approaches Massachusetts Institute of Technology.
Lecture 3 – Skills Theory
IS214 Recap. IS214 Understanding Users and Their Work –User and task analysis –Ethnographic methods –Site visits: observation, interviews –Contextual.
Automation and Ability Benjamin A. Clegg Department of Psychology Colorado State University Eric D. Heggestad Department of Psychology University of North.
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
ECE 796/896 Human Factor Engineering Chapter 22 Human Factors in System design.
Chapter 14: Usability testing and field studies. 2 FJK User-Centered Design and Development Instructor: Franz J. Kurfess Computer Science Dept.
Empirical Methods in Human- Computer Interaction.
Mary (Missy) Cummings Humans & Automation Lab
Marakas: Decision Support Systems, 2nd Edition © 2003, Prentice-Hall Chapter Chapter 7: Expert Systems and Artificial Intelligence Decision Support.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Overview of Software Requirements
4. Interaction Design Overview 4.1. Ergonomics 4.2. Designing complex interactive systems Situated design Collaborative design: a multidisciplinary.
Principles and Methods
Principles of High Quality Assessment
Meaningful Learning in an Information Age
IIBA Denver | may 20, 2015 | Kym Byron , MBA, CBAP, PMP, CSM, CSPO
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
The Context of Forest Management & Economics, Modeling Fundamentals Lecture 1 (03/30/2015)
Web Design Process CMPT 281. Outline How do we know good sites from bad sites? Web design process Class design exercise.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
The design process z Software engineering and the design process for interactive systems z Standards and guidelines as design rules z Usability engineering.
1. Human – the end-user of a program – the others in the organization Computer – the machine the program runs on – often split between clients & servers.
 A set of objectives or student learning outcomes for a course or a set of courses.  Specifies the set of concepts and skills that the student must.
S/W Project Management
A Case for Theory-Based Research on Level of Automation and Adaptive Automation David B. Kaber Department of Industrial Engineering North Carolina State.
Copyright 2002 Prentice-Hall, Inc. Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design.
Advanced Topics in Requirement Engineering. Requirements Elicitation Elicit means to gather, acquire, extract, and obtain, etc. Requirements elicitation.
Business Analysis and Essential Competencies
SLB /04/07 Thinking and Communicating “The Spiritual Life is Thinking!” (R.B. Thieme, Jr.)
Ecological Interface Design
Requirements Engineering Requirements Elicitation Process Lecture-8.
A COMPETENCY APPROACH TO HUMAN RESOURCE MANAGEMENT
HCI in Software Process Material from Authors of Human Computer Interaction Alan Dix, et al.
Leadership in Organizations Perspectives on Effective Leaders Behavior (Ch 3) Presented by K.C.TAI.
Chapter 4 Finding out about tasks and work. Terminology GOAL: End result or objective TASK: An activity that a person has to do to accomplish a goal ACTION:
Human Supervisory Control Issues in Unmanned Vehicle Operations
1 Introduction to Software Engineering Lecture 1.
INTERACTION DESIGN PROCESS Textbook: S. Heim, The Resonant Interface: HCI Foundations for Interaction Design [Chapter 3] Addison-Wesley, 2007 February.
User Interfaces 4 BTECH: IT WIKI PAGE:
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
Requirements Validation
Chapter 15: Analytical evaluation. Aims: Describe inspection methods. Show how heuristic evaluation can be adapted to evaluate different products. Explain.
Optimization Techniques for Natural Resources SEFS 540 / ESRM 490 B Lecture 1 (3/30/2016)
Design Evaluation Overview Introduction Model for Interface Design Evaluation Types of Evaluation –Conceptual Design –Usability –Learning Outcome.
Copyright 2006 John Wiley & Sons, Inc Chapter 5 – Cognitive Engineering HCI: Developing Effective Organizational Information Systems Dov Te’eni Jane Carey.
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
Systems Analysis Lecture 5 Requirements Investigation and Analysis 1 BTEC HNC Systems Support Castle College 2007/8.
1 Design and evaluation methods: Objectives n Design life cycle: HF input and neglect n Levels of system design: Going beyond the interface n Sources of.
Fundamentals of Information Systems, Sixth Edition
Object-Oriented Software Engineering Using UML, Patterns, and Java,
The design process Software engineering and the design process for interactive systems Standards and guidelines as design rules Usability engineering.
The design process Software engineering and the design process for interactive systems Standards and guidelines as design rules Usability engineering.
Informatics 121 Software Design I
Informatics 121 Software Design I
Usability Techniques Lecture 13.
Informatics 121 Software Design I
Evaluation.
Informatics 121 Software Design I
Presentation transcript:

16.422 Human Supervisory Control Function Allocation and Task Analysis Massachusetts Institute of Technology

Human Systems Engineering* “Vision” System/Software Reqs. User survey, needs analysis, etc. Feasitility assessment Artifact and like-system evaluatio Perform ance and usatility reqs Innovative concepts for Next version release HE labor/budget planning Installation Preliminary Design System/Software Acquisition cycle Finalize customer support Needs and task analysis Conduct on-site assessment Storyboards and demonstrations Provide training materials Ul design standards Integration & Test Detailed Design Plan perform ance tests Design tradeoff and workllow analysis Scenario-based assessment Detailed Ul designs and protctypes Develop training materials On-line help and documentation Unit Development HE heuristic review Define perform ance and effectiveness criteria Usatility evaluation of prototypes Planning →Analysis→Detail Design→Test & Evaluation

Functions & Tasks Planning Analysis Function Analysis Design Mission & Scenario Analysis Analysis Function Analysis Function Allocation Task Analysis Design Test & Evaluation System Design

Fitts’ List Attribute Machine Human Speed Power Output Superior Comparatively slow Superior in level in consistency Comparatively weak Ideal for consistent, repetitive action Unreliable, learning & fatigue a factor Consistency Information Capacity Multi-channel Primarily single channel Ideal for literal reproduction, access restricted and formal Better for principles & strategies, access versatile & innovative Memory Reasoning Computation Deductive, tedious to program, fast & accurate, poor error correction Inductive, easier to program, slow, accurate, good error correction Good at quantitative assessment, poor at pattern recognition Wide ranges, multi-function, judgment Sensing Copes with variation poorly, susceptible to noise Copes with variation better, susceptible to noise Perceiving Hollnagel, 2000 inductiveand deductive. Induction is usually described as moving from the specific to the general, while deduction begins with the general and ends with the specific; arguments based on experience or observation are best expressed inductively, while arguments based on laws, rules, or other widely accepted principles are best expressed deductively.

Some problems with Fitts… Tasks/functions defined in machine terms, not human-oriented Introduces a bias “Laws of human behavior” Environmental/ecologic context Learning, fatigue, stress, anxiety generally not incorporated into design picture Task division vs. task complement Static vs. dynamic allocation Adaptive allocation/automation Function allocation is not binary •Bandwidth •Trust •Machine/computer metaphors

Designing automation to support information processing Human Perception/Working Memory Sensory Processing Decision Making Response Selection Automation Decision & Action Selection Information Acquisition Information Analysis Action Implementation *Parasuraman, Sheridan, Wickens, 2000

A Model of Types and Levels of Automation* What should be automated? Identify types of automation Decision & Action Selection Information Acquisition Information Analysis Action Implementation A Model of Types and Levels of Automation* Identify levels of automation Low (manual) High (full automation) Apply primary evaluative criteria: Human Performance Consequences •Mental workload •Situation awareness •Complacency •Skill degradation Initial types & levels of automation Apply secondary evaluative criteria: •Automation reliability •Costs of action outcomes Final types & levels of automation *Parasuraman, Sheridan, Wickens, 2000

Sheridan and Verplank’s10 Levels of Automation of Decision and Action Selection Automation Level Automation Description The computer offers no assistance: human must take all decision and actions. The computer offers a complete set of decision/action alternatives, or narrows the selection down to a few, or suggests one alternative, and executes that suggestion if the human approves, or allows the human a restricted time to veto before automatic execution, or executes automatically, then necessarily informs humans, and informs the human only if asked, or informs the human only if it, the computer, decides to. The computer decides everything and acts autonomously, ignoring the human.

A Model of Types and Levels of Automation* What should be automated? Identify types of automation Decision & Action Selection Information Acquisition Information Analysis Action Implementation A Model of Types and Levels of Automation* Identify levels of automation Low (manual) High (full automation) Apply primary evaluative criteria: Human Performance Consequences •Mental workload •Situation awareness •Complacency •Skill degradation Initial types & levels of automation Apply secondary evaluative criteria: •Automation reliability •Costs of action outcomes Final types & levels of automation *Parasuraman, Sheridan, Wickens, 2000

Function Allocation Criteria No difference in the relative capabilities of human & machine. Human performance > machine performance. Machine performance > human. Machine performance is so poor that the functions should be allocated to humans. Human performance is so poor that the functions should be allocated to machine. Unacceptable performance by both human and machine. Three function allocation criteria: Balance of value Utilitarian & cost-based allocation Allocation for affective or cognitive support. Excellent Machine Unsatisfactory Unsatisfactory Human Excellent Price, 1985

Functions & Tasks Planning Analysis Function Analysis Design Mission & Scenario Analysis Analysis Function Analysis Function Allocation Task Analysis Design Test & Evaluation System Design

Task Analysis Determining what an operator must accomplish to meet a mission goal Interactions both on a local and system level are critical Will contain actions and/or cognitive processes Flow process charts, operational sequence diagrams, critical task analysis Attempt to understand how a particular task could exceed human limitations, both physical and cognitive Cognitive task analysis Not the only system analytic method but a critical one Shift away from system control to systems management. Supervisory control becoming more about cognitive tasking than manual tasking, especially with increasing automation

Cognitive Task Analysis (CTA) Goal: To analyze and represent the knowledge and cognitive activities needed in complex work domains CTA is generally a descriptive modeling technique of workers’ knowledge and cognition As opposed to Computational Cognitive Models (CCM) Knowledge Elicitation techniques provide input to CTA and CCM Experts vs. Novices Evolutionary systems vs. revolutionary systems Background Research Standards, procedures, manuals, organizational charts Field Studies In both real environments and high fidelity simulations Questionnaires/Surveys http://www.ul.ie/~infopolis/methods/incident.html

CTA, Cont. Interviews Observations Design Reviews Problems with CTA Individuals vs. focus groups Critical Incident Technique/Critical Decision Method Observations PARI Method (Precursor (reason for action), Action, Result, Interpretation (of result)) Verbal protocols Design Reviews Usability, Expert, Heuristic Problems with CTA Labor intensive Generate much data that is difficult to analyze Gap between CTA and design Opportunistic

CTA: A Bootstrapping Process COGNITIVE TASK ANALYSIS Understanding the way people operate in their world Discovering support for how people will operate in their world Goal : Understand/model expertise se, knowledge, strategies, s, and error Techniques : Semantic Mapping Ethnographic / Observational investigations Critical Incident Technique Critical Decision Method Structured Interview T w Techniques Practitioner(s) CTA Model Desig Ba Basis Scratch Growth of Understanding Field of Pr Practice CTA Representation Prototype Representation Goal : Understand/model complexities, demands, variability, and complicating factors Tech chniques : Functional/Means-ends Analysis Ethnographic / Observational investigations Functional Task and Workflow Modeling Structured Interview Techniques The Domain Discovering how to support the way the world will work Understanding the way the world works Time Time Exploring the Current World Exploring the Envisioned World Adapted from Carnegie Group, Inc. critical decision method in which participants are asked to describe a specific decision-making incident in detail and then to respond to probes seeking elaboration of important aspects of the decision sequences. Semantic mapping (a.k.a., mind-mapping, idea mapping, word webbing, etc.) is a term which describes a variety of strategies designed to show how key words or concepts are related to one another through graphic representations.Mapping is an effectivetechnique for teaching vocabulary and textual patterns of organization; and it is also effectivefor improving note taking and creative thinking skills.

Functional Means/Ends Analysis Abstraction (Means/ends) Decomposition (Whole/Part) Total System Subsystems Subassembly Component Functional Purpose Abstract Function Generalized Function Physical Function Physical Form

CTA: A Bootstrapping Process COGNITIVE TASK ANALYSIS Understanding the way people operate in their world Discovering support for how people will operate in their world Goal : Discovery of unsupported expertise, knowledge, and strategies Techniques : Storyboard walkthroughs Participatory design Wizard-of-Oz technique High-fidelity simulations Goal : Understand/model expertise, knowledge, strategies, s, and error Techniques : Semantic Mapping Ethnographic / Observational investigations Critical Incident Technique Critical Decision Method Structured Interview T w Techniques Practitioner(s) Growth th of Understanding Artifacts as Hypotheses Field of Pr Practice Scratch Design Basis CTA Representation Prototype Representation The Domain Goal : Understand/model complexities, demands, variability, and complicating factors Techniques : Functional/Means-ends Analysis Ethnographic / Observational investigations Functional Task and Workflow Modeling Structured Interview Techniques Goal : Discovery of unsupported complexities, demands, variability, and complicating factors Techniques : Scenario generation based on: - Textbook cases - Complicating factors - Cascading effects - Exceptions Understanding the way the world works Discovering how to support the way the world will work Time Time Exploring the Current World Exploring the Envisioned World Adapted from Carnegie Group, Inc. WoZ: http://www.dcs.napier.ac.uk/marble/Usability/WizardOfOz.html

Work Analysis v. Task Analysis Descriptive v. Normative v. Prescriptive Ecological focus Constraints v. instructions Map v. directions Not a mutually exclusive set normative analysis focuses on "how decision makers should ideally perform" an activity. Bell et al. (1988) have claimed that "normative theory has something to do with how idealized, rational, super-intelligent people should think and should act." Normative analysis is often contrasted with prescriptive analysis, which is usually said to be geared toward examining what realpeople ought to do given their real-world constraints and cognitive limitations (or how decision aids might aid real decision makers).

Resources A Survey of Cognitive Engineering Methods and Uses http://mentalmodels.mitre.org/cog_eng/index.htm ONR/Aptima Cognitive Task Analysis website http://www.ctaresource.com/