(Informatie, september 1991)


Disclaimer
HET MENSELIJK TEKORT EN HET ONTWERP VAN COMPUTERSYSTEMEN

Donald A. Norman


In 1988 ging de Sovjet-satelliet Phobos 1, onderweg naar Mars, verloren. Hoe kwam dat? Volgens het blad Science doordat ‘kort na de lancering een grondtechnicus één enkele letter vergat in een serie digitale berichten die naar het ruimtevaartuig werden overgeseind. En door stom toeval veroorzaakte dat ene ontbrekende teken een vertaalfout in de code. Die vertaalfout zette het testprogramma in werking.’ Dat testprogramma, opgeslagen in een ROM, was uitsluitend bedoeld voor de ‘koude’ test van het ruimtevaartuig vóór de lancering (Waldrop, 1989). Phobos raakte in een vrije val, waar hij niet meer uitkwam.

Wat een vreemd bericht! ‘Stom toeval?’ Waarom stom toeval, waarom niet gewoon een stom ontwerp? Werd het probleem niet vooral veroorzaakt door het gebruik van een commandotaal waarin zo’n klein foutje zulke grote gevolgen kon hebben?
De effecten van elektrische ‘ruis’ bij de detectie, identificatie en betrouwbaarheid van signalen zijn vaak onderzocht. Van ontwerpers wordt verwacht dat ze foutdetecterende en foutcorrigerende codes hanteren. Stel dat het signaal naar Phobos in het ongerede was geraakt door een geďdentificeerde bron van elektromagnetische ruis. We zouden er niet over piekeren de grondtechnici de schuld te geven; we zouden zeggen dat de systeemontwerpers hadden gezondigd tegen de grondbeginselen van hun vak, en we zouden nog eens zorgvuldig naar het ontwerp kijken om dit soort problemen in de toekomst te voorkomen.

Mensen maken fouten. Dat is een vast gegeven. Een mens is geen precisie-instrument en niet gemaakt om honderd procent betrouwbaar te functioneren. Integendeel, wij mensen zijn apparaten van een compleet andere categorie. Creativiteit, aanpassingsvermogen en flexibiliteit zijn onze sterke, voortdurende waakzaamheid en nauwgezetheid bij het handelen of herinneren onze zwakke punten. We zijn verbazingwekkend goed bestand tegen fouten, zelfs als we fysiek beschadigd zijn. We zijn uiterst flexibel, nuchter, creatief en briljant als we zoeken naar verklaringen en samenhang op grond van incompleet en onbetrouwbaar feitenmateriaal. Dezelfde eigenschappen die verantwoordelijk zijn voor onze nuchterheid en creativiteit, veroorzaken ook onze fouten. De natuurlijke neiging om conclusies te trekken op grond van incompleet feitenmateriaal – een neiging waarvan wij overigens meestal alleen maar profijt hebben – kan een operator verleiden een verkeerde conclusie te trekken uit het ‘gedrag’ van zijn systeem. En het opsporen van zo’n verkeerde conclusie kan een heel karwei worden.

Er is veel bekend over menselijk gedrag en menselijke interactie met een computersysteem (Helander, 1988). Er bestaat een complete classificatie van menselijke fouten en het is mogelijk, gegeven de omstandigheden, de kans op een fout te voorspellen (Norman, 1983, 1988; Perrow, 1984). Er bestaan ‘foutbestendige’, ‘foutdetecterende’ en ‘foutcorrigerende’ communicatiesystemen. Zo doorgaande moet het zelfs mogelijk zijn iets zinnigs te zeggen over foutbestendige foutdetectie- of foutcorrectie-sessies tussen mens en computer (Leveson, 1986).
Er ontbreekt maar weinig aan onze kennis van de hardware en software van informatieverwerkende systemen, maar er is nog steeds één grote lacune: de inpassing van de mens die het systeem bedienen moet. Het gedrag van een informatieverwerkend systeem is niet zomaar het resultaat van de ontwerpspecificaties, het is het resultaat van de wisselwerking tussen die mens en het systeem. De systeemontwerper moet rekening houden met alle systeemcomponenten – inclusief de menselijke – en hun interacties. En wat zien we in de vakpers? Veel aandacht voor de software en de hardware, weinig aandacht voor het gedrag en de mogelijkheden van de menselijke systeemcomponent. Veel mislukkingen op het gebied van de informatiesystemen worden toegeschreven aan menselijk falen en niet aan het ontwerp. En als we geen andere benaderingswijze kiezen, zal de rij mislukkingen nog wel langer worden.

Een van de belangrijkste zaken die we ons eigen zullen moeten maken, is een andere denkwijze. Het gedrag dat we ‘menselijke fout’ noemen, is net zo voorspelbaar als een machinestoring, en misschien nog wel voorspelbaarder. Derhalve: in plaats van de schuld te leggen bij de mens die toevallig de fout maakte, kunnen we beter proberen de systeemkarakteristieken te achterhalen die het incident hebben veroorzaakt en dan het ontwerp veranderen, hetzij door zo’n situatie effectief onmogelijk te maken, hetzij door tenminste de gevolgen voor de toekomst te minimaliseren. Het is al heel wat als we de term ‘menselijke fout’ uit ons woordenboek schrappen en eens nadenken over de vraag of het echt nodig is een zondebok te zoeken. En het is nog beter als we ontwerpspecificaties ontwikkelen die rekening houden met de menselijke eigenschappen, op een even zorgvuldige wijze als met de rest van het systeem.

Om terug te komen op die Marsraket uit de Sovjet-Unie: voor Science stond het als een paal boven water dat het probleem geheel te wijten was aan die incompetente grondtechnicus. Het blad vroeg Roald Kremnev, de directeur van het Sovjet-ruimtevaartlaboratorium, om commentaar. En zo geeft Science zijn woorden weer:

‘... wat gebeurde er met de grondtechnicus die de fout maakte? Met een grimmig gezicht maakt Kremnev Science duidelijk dat hij niet in de gevangenis of in Siberië is beland. Hij was zelfs degene die uiteindelijk de fout in de code ontdekte. Niettemin, zegt Kremnev, “hij kon niet verder deelnemen aan het Phobos-programma.” ’ (Waldrop, 1989).

Zowel de vraag van de verslaggever als het antwoord van Kremnev gaan ervan uit dat de grondtechnicus een verwijt treft. Ook al was hij degene die de fout ontdekte, hij werd toch gestraft (al bleef Siberië hem dan bespaard).
Maar de ontwerpers van de commandotaal en de software, of de methoden die zij hebben gebruikt? Die blijven buiten schot. Het probleem met deze benaderingswijze is dat ze ons belet iets van het voorval te leren en een foutgevoelige situatie laat voortbestaan.

We hoeven niet lang te zoeken naar vergelijkbare voorbeelden van computersystemen die falen dankzij ‘menselijke fouten’. Kernenergie, de luchtvaart, de zakenwereld, de aandelenmarkt, en, natuurlijk, de computerindustrie zelf – iedere bedrijfstak heeft zijn griezelverhalen. In Communications of the ACM van augustus 1989 vinden we in de rubriek ‘News Track’ het volgende berichtje:

‘Een computeroperateur bij het hoofdkantoor van Exxon in Houston is ontslagen wegens het (onopzettelijk) vernietigen van tekstbestanden met de inhoud van duizenden documenten die vermoedelijk belangrijke informatie bevatten over de olieramp in Alaska... De ex-werknemer stelt echter dat hij als zondebok gebruikt wordt en dat op geen van de banden die hij gewist heeft een etiket “Niet vernietigen” zat.’

Dit berichtje alleen is wat te mager om een conclusie te trekken, maar duidelijk is wel: als men bij het systeemontwerp rekening had gehouden met de karakteristieke eigenschappen van een menselijke bediener, zou het al dan niet bewaren van een band niet hebben afgehangen van een simpel (door een mens gegenereerd?) etiketje ‘Niet vernietigen’. Dan zou het incident niet hebben plaatsgevonden, of het excuus was niet plausibel geweest.

Misschien is voor ACM de tijd rijp om het voortouw te nemen bij het inbouwen van het menselijk tekort in het computerontwerp. Binnen de ACM-gelederen is voldoende deskundigheid te vinden; te denken valt aan het Committee on Computers and Public Policy, en er is ook een werkgroep die zich met verwante problemen bezighoudt (de SIGCHI, de Special Interest Group on Computer-Human Interaction).
Ook een beginpunt is niet moeilijk te vinden. Via de computernetwerken kan men in contact komen met Peter Neumann en zijn onvolprezen forum over de publieke risico's van computers en aanverwante systemen, werkend onder de paraplu van het ACM Committee on Computers and Public Policy. Dit RISKS-forum verzamelt incidenten veroorzaakt door menselijke fouten en ontwerpfouten, rapporteert erover en voorziet ze van commentaar. Maar zo'n rapport is zelden zodanig gedetailleerd en gedocumenteerd dat er iets van te leren valt. De informatiebron is meestal een berichtje uit de media, dat incompleet is, vaak geschreven vóórdat alle relevante informatie beschikbaar was, en met de sporen van de onnauwkeurigheden en vooroordelen van de journalist. (De geciteerde stukjes uit Science en de rubriek ‘News Track’ van Communications of the ACM zijn heel illustratief.) Een grondige studie van ontwerpfouten kan heel wat vruchten afwerpen; specialisten uit andere disciplines kunnen dat bevestigen (Petroski, 1985). Waarom zou men de rapporten van het RISKS-forum niet gebruiken als leidraad voor een beter ontwerp?

In andere industrieën bestaan al beproefde systemen die als model kunnen dienen. In de vliegtuigwereld is er een onuitputtelijke bron van waardevolle adviezen: een verzameling van incidenten die bekend staat als ASRS, het Aviation Safety Reporting System, als database geëxploiteerd door NASA-Ames en beheerd door Battelle. Het is in de vliegtuigwereld een goed gebruik dat iemand die getuige is van een fout, of er zelf een maakt, dan wel tegen een verwant probleem aanloopt, het incident en zijn interpretatie ervan op schrift stelt en aan ASRS doet toekomen. De ASRS-onderzoekers zullen in veel gevallen contact met hem opnemen om de gegevens te controleren of te completeren, maar zodra de feiten vaststaan en duidelijk zijn, wordt dat deel van het formulier dat de persoonlijke gegevens van de rapporteur bevat, aan hem teruggestuurd. ASRS zorgt er ook voor dat informatie waaruit zou kunnen blijken wie precies de rapporteur was of om welk incident het precies gaat, buiten de database blijft. Met deze anonimiteit staat of valt de nauwkeurigheid en betrouwbaarheid van de database. Omdat NASA geen regels kan afkondigen en een goede reputatie heeft op het terrein van omgaan met vertrouwelijke informatie, heeft de vliegtuigwereld een groot vertrouwen in deze database. Wie zich tot ASRS wendt, vertelt zonder schroom wat hij gedaan heeft, in de wetenschap dat zijn rapport alleen gebruikt wordt om de veiligheid van het luchtverkeer te verbeteren. En aan de ontwerpers die lering hebben getrokken uit de foutpatronen die ze dankzij de database konden onderkennen, zijn heel wat verbeteringen in de opstelling binnen de cockpit en andere delen van een vliegtuig te danken.
Een belangrijk aspect aan het ASRS-systeem is dat de rapporten niet onder ogen komen van de chefs van de rapporteurs. De reden dat bij andere industriesectoren een soortgelijk informatiesysteem niet van de grond is gekomen, was dat de rapporten eerst een hele reeks autoriteiten moesten passeren, onder wie de directe chef van de rapporteur of de directie van zijn bedrijf – mensen die geneigd zijn het rapport bij te schaven of de gebeurtenissen bij te schrijven op de conduitestaat van de rapporteur.
Daarom is bijvoorbeeld het rapportagesysteem van incidenten bij de nucleaire industrie geen goede gids voor de werkelijke gang van zaken in een kernreactor. Anonimiteit en rapportage op eigen initiatief, in combinatie met een systeem van verificatie en verduidelijking, blijken nog het best te werken; dat kunnen we leren van het NASA/ASRS-team (dat voornamelijk bemand wordt door gepensioneerde luchtvaartmensen).

Op een vergelijkbare wijze analyseert de Amerikaanse National Transportation Safety Board (NTSB) gedetailleerd alle ongelukken in de transportsector (ongeacht of daarbij een vliegtuig, een vrachtwagen, een schip, een trein of een pijplijn betrokken is). Deze rapporten leveren een schat aan informatie voor ieder die zich bezighoudt met de veiligheid binnen de transportwereld. (De NTSB-rapporten mogen statutair niet gebruikt worden om de schuldvraag te beantwoorden bij een juridische procedure. Een dergelijke bepaling is essentieel om te waarborgen dat het onderzoek voortgang kan vinden zonder angst dat de resultaten verkeerd geďnterpreteerd of gebruikt worden, een angst die niet ongerechtvaardigd is gezien de Amerikaanse procedeerlust.)

Moet ACM een soortgelijk initiatief van de grond gaan tillen? Ik ben er niet helemaal zeker van, want de computerwereld verschilt toch wel radicaal van de andere industriesectoren. Maar ik zou wel willen voorstellen dat ACM onderzoekt of er verbeteringen mogelijk zijn in dit stukje vakgebied. ACM kan het voortouw nemen bij het pogen de menselijke kant van de computerwetenschap op hetzelfde niveau te brengen als de fysieke en de mathematische. Deze kant is namelijk even belangrijk en verdient evenveel aandacht.


Literatuur
  • Helander, M. (ed.) (1988), Handbook of Human-Computer Interaction, North-Holland, New York.
  • Leveson, N.G. (1986), ‘Software safety: Why, what and how’, ACM Computer Surveys 18-2 (juni 1986), blz. 125-163.
  • Norman, D.A. (1983), ‘Design rules based on analyses of human error’, Communications of the ACM 26-4 (april 1983), blz. 254-258.
  • Norman, D.A. (1988), The psychology of everyday things, Basic Books, New York. (Een Nederlandse vertaling is uitgegeven door Bruna.)
  • Perrow, C. (1984), Normal accidents, Basic Books, New York.
  • Petroski, H. (1985), To engineer is human: The role of failure in successful design, St. Martin's Press, New York.
  • Waldrop, M.M. (1989), ‘Phobos at Mars: A dramatic view ─ and then failure’, Science 245, blz. 1044-45.

Donald A. Norman is hoogleraar aan en decaan van het Department of Cognitive Science aan de universiteit van Californië in San Diego.
Dit artikel verscheen eerder in Communications of the ACM 33-1 (januari 1990), blz. 4-7. De vertaling is van de hand van I. Schurer.

♦ ♦ ♦ ♦ ♦ ♦
KANTTEKENINGEN. I. Schurer is een anagram van S. Reurich.
Voor wie het niet wist: de ACM is de Association for Computing Machinery, een internationaal opererende organisatie van computerdeskundigen. De club is van eerbiedwaardige ouderdom (opgericht in 1947!). Zie zijn website: www.acm.org.