B.W. van Schooten
version 3, 24 september 1998
A classification into the actual disciplines HCI, hardware, software seems the most obvious at first. However, I found that only few lectures actually fit neatly into one of these categories, and several used the same methods in different disciplines. After a while of shuffling and re-shuffling, I decided on the following classification, based also on my own interests in methods:
Almost all lectures about methods do include some quantitative method, but each focuses on either the qualitative (how do I create a schema?) or quantitative (how do I calculate the values?) aspects only, making the distiction clear. A few lectures do not really fit into either of these and are mostly listed in `miscellaneous'. When a lecture explicitly focuses on software, hardware, or HCI, this is mentioned at the beginning of its summary.
Part of the material of some of the lectures can be found, in more detail, in the handbook. In this case, the appropriate reference is given in the `recommended literature' for that lecture. Part of the handbook is not covered in any lecture.
Lecturer: Gianpetro Monfardini.
Discusses general (including organisational) aspects of safety. Some examples of the existing systems are given.
Lecturer: Antonio Rizzo.
Recommended literature: [ZN94]
First, the symbolic and subsymbolic debate is reviewed. It is argued that the subsymbolic view is more useful as metaphor for understanding cognition. This is illustrated by the coin example: people only learn those features of a coin that are needed to separate them from other coins. This is similar to pattern recognition as done by a perceptron. Main characteristics: content addressable memory and context-sensitive rule selection.
Errors are seen as the result of people's normal cognitive functions which happen to turn out badly due to adverse conditions. Classification into slip, lapse, mistake.
The theory of distributed cognition (which is close to activity theory [KKB95] according to Gerrit) maintains that cognitive activity is a combination of thinking (internal representation) and the use of artifacts (external representations). By choosing the right external representations, a task can be made easier and less prone to error.
Lecturer: Jean-claude Laprie.
Recommended literature: handbook [Lap98], chapter 2.1, 1.1.4, 1.1.5.1, 2.2.4.
Overview of fault tolerance. Def. of failure, error and fault, and their interrelation. Different kinds of faults and relative frequency. Dealing with faults. Review of fault-tolerant systems. Coverage factor. Examples of hardware redundancy. Fault tolerance testing, fault injection. Software fault tolerance: recovery points, design diversity, review. HCI fault tolerance: vicious cycle.
Lecturer: W. Görke
General risk statistics. Fault-cause classification. Some individual accidents are reviewed. Some implications are shown for future safety-critical systems.
Lecturer: Stuart Anderson
Review of sources of evidence, reporting, kinds of criteria in certification. Review of therac-25 accidents.
Lecturer: Uffe K. Mortensen
Focuses on software. First reviews some specific space accidents. Then, reviews methodological issues in safety-critical software engineering.
lecturer: Mohamed Kaâniche and Corinne Mazet
Recommended literature: handbook [Lap98], chapter 3.
General review of safety and its relation to standards and certification. Review of many design cycle models. Review of verification and standards: (ergonomics) standards and human-centered development process; software verification process; IEC1508 (based on complete design cycle); hazard and risk level analysis.
Safety can be checked using: verification, validation, assessment. Importance of independence of evaluating party. List of techniques.
Dependability-Explicit Development Model: this model has the stages requirements, design, realisation, integration. A number of guidelines is given for each.
Recommended literature: about GTA [vdVLB96], [vdVHL96]. Checklist [RA88].
Lecturer: Gerrit C. van der Veer.
Analysis: task model 1 (model of current situation), task model 2 (model of envisioned situation).
Specification: User's Virtual Machine, User Action Notation, dialogue model classification.
Evaluation: We may evaluate using the UVM, task model 2, formal specification, and a system setup with possibly varying degrees of realism. Various standard evaluation techniques are listed.
The dialogue model classification sees natural language as a metaphor rather than a style. Typical natural language system must then be seen as switching between several styles (command language, question answering), but the switching itself could be seen as a interaction style. More problems: isn't direct manipulation just command language with a different modality? Aren't menu and form filling just question answering with a different modality? Doesn't VR belong in the `look and feel' section?
Lecturer: Gerrit C. van der Veer.
This lecture focuses on the analysis part of interaction design.
The task analysis method used is GTA, which combines ethnography with more traditional task analysis methods like HTA (MAD), work flow analysis, object modeling. General procedure of GTA is explained, including task model 1 and 2, and a modeling tool.
Lecturer: David Embry
Review of human failure data.
Incident investigation using STEP (Sequentially Timed Events Plotting), based on general `incident model' based on the sequence failure-no defences-no recovery. A STEP diagram represents the causes which have lead to an incident in a cause-effect diagram, starting from the incident and working backwards. A BackStep diagram also allows working forwards from an unwanted situation (ex. alarm didn't go off) next to working backwards from incident. Causal tree analysis: one selects critical events from the STEP diagram, and draws causal trees for those. A tree represents all possible failures leading to an incident. STEP example.
Description of: Hierarchical Task Analysis (HTA); Predictive Human Error Analysis (PHEA) based on HTA diagram. Examples.
Case study: emergency response system in offshore oil rig.
Lecturer: Gerald Sonneck.
Recommended literature: handbook [Lap98], chapter 2.3.1.
The failure analysis methods and notations include human, software, hardware parts.
A review of dependability issues and terminology. Analysis methods: Hazard Analysis/Hazard and Operability Analysis (HAZOP); Failure Mode and Effects Analysis (FMEA); Fault Tree Analysis (FTA); Event Tree Analysis (ETA). FTA and ETA may include calculation of probability figures (=quantitative).
Lecturer: Gerald Sonneck.
The case study is an example of the aforementioned methods.
Discussion of software risks [LS92].
Comparative research [FPG94].
Lecturer: Bruno Ciciani
The examples focus mostly on hardware systems with unreliable components, but some of the mathematics (general statistics and Markov models) are useable for any kind of quantitative analysis.
Statistics, examples. Server reliability. Markov processes. Reliability metrics (failure rate, MTTF, MTTR, fault coverage). Examples of Markov-based reliability analysis. Markov models with reward index, examples. Satellite system example.
Focuses on software, but it is argued that such models may also be used for design reliability in complex hardware. According to Alberto Pasquini (+literature?), such models could also be applied to human reliability, but only when averaged over several people (what about human differences?).
Lecturer: Bev Littlewood.
Recommended literature: handbook [Lap98], chapter 2.3.3.
Discusses statistical prediction methods for predicting software reliability growth/change. Main data: time between failures. Best prediction method: u-calibration.
Lecturer: Karama Kanoun.
Discusses methodology and some practical guidelines for using statistical analysis of software reliability using failure data. Dependability measures, trend analyses.
Case study: software switching system.
Lecturer??
Recommended literature: handbook [Lap98], chapter 2.3.4.
Human error data for basic tasks can be obtained from databases, literature or expert judgement (either absolute error or based on relative error). Error data can be combined to form an estimate of the error of a specific task.
Hierarchical (event tree) or linear (sum of weighted errors) error model. Hierarchical: THERP. Linear: HEART, SLIM (single level/multilevel), IDEX.
Some models also give error cause/means of recovery classifications.
Lecturer: Karama Kanoun.
Recommended literature: handbook [Lap98], chapter 2.3.2.
General overview of dependability: terminology, statistical measures (availability, maintainability, MTTR, restoration rate).
Probabilistic evaluation methods: Reliability block diagrams; fault trees; Markov chains including homogeneous ones. Review of methods with examples.
[Gur94]: applicable to software/hardware design
Lecturer: Stuart Anderson
Overview of formal methods. Example using state charts.
After classification of the lectures, I found there is a large overlap in usage of some the terms and notations. A list of all notations together with their meaning and possible uses.
Quantifiable notations:
Report on OLOS 1st summer school, 7-13 september 1998
This document was generated using the LaTeX2HTML translator Version 96.1 (Feb 5, 1996) Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 -show_section_numbers olosreport.
The translation was initiated by Boris van Schooten on Thu Sep 24 19:45:32 MET DST 1998