Undgå misforståelser i software-udvikling

Bragt i Computerworld den 2. december 2005.

Der er en mere almen beskrivelse her.

Hvordan forstår udviklere egentlig de tekniske specifikationer og beskrivelser som de læser?

Jeg er lektor på Datalogisk Institut Københavns Universitet, og syntes spørgsmålet var værd at undersøge, især da der er rigeligt med bøger som fortæller hvordan man bør skrive specifikationer for software, men tilsyneladende ingen som ved hvad udviklerne får ud af at læse dem. 

Derfor lavede jeg et forsøg hvor tretten softwareudviklere hver læste beskrivelser af fire forskellige systemer – tre læste kun en teknisk beskrivelse, fem læste en teknisk beskrivelse og et traditionelt scenarie og fem læste en teknisk beskrivelse og en beskrivelse af brugssituationen med følelser og konflikter, altså lige som i en roman eller novelle. Bagefter interviewede jeg deltagerne, optog interviewene på bånd og analyserede de omkring hundrede sider udskrifter. 

Det viste sig at læsernes forståelse af tekniske beskrivelser er en langt mere kreativ proces end vi normalt forestiller os. Softwareudvikleren som læser en specifikation konstruerer rent bogstaveligt sin egen personlige forståelse af den. Han kombinerer dele af teksten med dele af sine egne erfaringer og med elementer fra den øjeblikkelige situation, for eksempel et spørgsmål en kollega stiller om noget helt andet. Han prøver at finde stumper som kan give en nogenlunde sammenhængende forståelse, og ignorerer de stumper som ikke passer sammen med resten, og han ender måske med at konstruere en forståelse som er i direkte modstrid med dele af teksten. 

Da en af deltagerne skulle svare på et spørgsmål om et af systemerne, fortalte han i stedet i detaljer hvordan et system han tidligere havde arbejdet på fungerede. Det var ikke fordi han huskede forkert eller havde misforstået den beskrivelse han havde læst. Da jeg stillede flere spørgsmål om det han havde læst, blev han klar over at hans forståelse var forkert, og han kunne så fortælle korrekt hvordan systemet i beskrivelsen fungerede. 

Hvordan kan vi så udnytte disse resultater i softwareudvikling?

Først og fremmest viser resultaterne at de enkelte læseres forståelse af tekniske beskrivelser er langt mere forskellige end vi normalt forestiller os, og at læseren ofte ikke er klar over at han eller hun har konstrueret en forståelse som er i modstrid med dele af teksten. Derfor er det ikke tilstrækkeligt at sende en beskrivelse som attachment til en e-mail og bede modtageren vende tilbage hvis der er spørgsmål. Hvis man skal være sikker på at læseren forstår teksten, er det nødvendigt at bede ham eller hun fortælle om sin personlige forståelse af den. 

Forsøget viser at læsere ofte bruger både personlige erfaringer og situationer som de selv forestiller sig, når de skal konstruere en forståelse af det de læser. Det kan skabe problemer i softwareudvikling når resten af gruppen hverken kender de erfaringer eller de fiktive eksempler som den enkelte deltager har brugt til at konstruere sin egen forståelse. Derfor kan det være en god ide at diskutere disse personlige eksempler og erfaringer. Man kan så få en bedre fælles forståelse af hvordan beskrivelsen af opgaven egentlig skal opfattes.

Deltagere som havde læst et scenarie eller en fortælling sammen med den tekniske beskrivelse henviste mere end dobbelt så ofte til den. Det tyder på at softwareudviklere som læser et scenarie eller en fortælling som beskriver brugen af et system har langt lettere ved at finde rundt i en teknisk beskrivelse af det. 

De deltagere der kun havde læst tekniske beskrivelser eller scenarier misforstod nogle af brugssituationerne ­ deres forståelse passede ikke med hvad der stod i dele af teksten. Til gengæld var der ingen misforståelser blandt de deltagere som havde læst fortællinger med følelser og konflikter. Det lader til at jo flere aspekter der er med når læseren skal konstruere sin forståelse ­ i det her tilfælde ikke blot selve teknikken men også nogle følelser og menneskelige konflikter ­ jo mere pålidelig bliver forståelsen. 

Endelig er der en erfaring fra forsøget som det er værd at bruge når man læser teknisk dokumentation, scenarier, rapporter eller skildringer af brugs- og andre situationer. Trods de mange forskellige mulige forståelser var der ikke nogen deltagere i forsøget som fortalte at de overvejede at en tekst kunne forstås på mere end en måde. Det lader til at mennesker har en tendens til at holde fast ved den første forståelse som ser ud til at kunne passe. Når man læser, er det derfor en god ide at overveje at den samme tekst kan forstås på flere forskellige måder, og at man ikke altid kan sige med sikkerhed hvilken der er den mest rigtige. 

Det er nok det vigtigste resultat af forsøget. At det er naturligt at forskellige mennesker opfatter det de læser vidt forskelligt, også selv om de er grundige og gør sig umage, og at man i softwareudvikling er nødt til at være åben overfor de forskellige forståelser og bruge tid på at finde og diskutere dem. 

Kilde: 

Georg Strom: The reader creates a personal meaning: A comparative study of scenarios and human-centered stories, in People and Computers IX ­ The Bigger Picture ed. by Tom McEwan, David Benyon & Jan Gulliksen, Springer UK 2005 PDF-version for download – layout er forskelligt fra den trykte version