Min rejse i IT-verdenen, Søren Lauesen  Home


Jeg blev i 1962, 19 år gammel, ansat på Regnecentralen (RC) som "koder" (programmør). Siden 1958 havde Regnecentralen haft én computer, DASK. Den fyldte en spisestue. De havde netop bygget en ny computer, GIER, og jeg havde lært mig selv alle maskinordrerne. Men ikke at programmere på en velstruktureret og læselig måde. Den slags var slet ikke opfundet endnu. Min første opgave blev at skrive et program der kunne spille Nimbi, et spil opfundet af Piet Hein. Det kom til at virke, men var en gang spaghetti. Til gengæld er det det mest brugervenlige system jeg har lavet. Man kan spille det på www.datamuseum.dk/nimbi

Siden har jeg arbejdet med programmering og Software Engineering. Her er nogle projekter jeg har arbejdet på: Project CV (pdf). Nedenfor er der nogle publikationer på vejen. Der er flere i Publikationslisten, bl.a. om operativsystemer, test og forsøg med brugergrænseflader.

Det skrift jeg selv synes bedst om, handler om den perfektionisme der forhindrede os i at løse de egentlige problemer - og om det er bedre i dag. Du kan læse det straks: Compiler-gruppen: Teknisk perfektionisme kontra nytte (11 sider): RChistorie (pdf)

GIER's betjeningspanel

1962: GIER - den første computer jeg arbejdede med. Billedet viser betjeningspanelet. GIER selv stod ved siden af og fyldte som et klædeskab. Lageret var 5 kB, heraf 50 bytes til operativsystemet. Resten blev delt mellem program og data.

1962-73: Min tid på Regnecentralen, RC

De første år arbejdede jeg som almindelig programmør. Jeg lavede fx et program til kemikere. Det kunne beregne molekulers form ud fra diffraktions-billeder - pletter på et røntgen-billede. Og et program nogle astronomer brugte til at løse 3-legemeproblemet. Og et program der udregnede den optimale rute for sukkertransporter i Polen. Og et program der fandt den optimale bemanding af sporvogns- og buslinier (det kom dog aldrig i drift, fordi fagforeningen sagde nej).

I 1965 blev jeg kandidat i matematik og fysik, og blev "forfremmet" til compiler-gruppen, hvor jeg fik den ære at dele kontor med Peter Naur. Jeg programmerede Algol-compilere og operativsystem til Regnecentralens nye fler-bruger computer, RC4000.

1968: Min første lærebog og SL69

I 1968 opfordrede professor Thøger Busk fra DTU mig til at skrive en lærebog i programmering, så der også kunne undervises i det på DTU. Det blev til Elementær Datamatik. Gyldendalske Boghandel, 1969, 138 sider. ISBN 87 00 78361 7. Det sker stadig at kolleger fortæller mig om de aha-oplevelser de fik ud af den bog. For at afmystificere computeren, opfandt jeg en meget simpel computer som kunne beskrives i detaljer. Ved hjælp af den kunne jeg forklare hvad et program var, hvordan det kom ind i computeren, osv. Kolleger har fortalt at man senere på Datamatiker-uddannelsen simulerede denne computer og brugte den i undervisningen under navnet SL69.

Peter Naur var optaget af at planlægge en universitetsuddannelse i datalogi. Det kom vi til at arbejde sammen om. Det store problem var hvad undervisningen skulle indeholde. Naurs plan handlede om forholdet mellem forelæsninger, øvelser, feedback, eksamener, osv. men sagde meget lidt om hvad der skulle undervises i. Der var ingen lærebøger vi kunne bruge - bortset fra SL69. Der var heller ingen eksempler fra erhvervslivet med virkelige anvendelsesprogrammer. Så det hele blev meget maskin-nært.

Søren forelæser

1970: Søren forelæser ved datalogistudiets start.

1970-73: Datalogi-uddannelsen starter på KU

I 1970 startede datalogi-uddannelsen ved Københavns Universitet. Naur, H. B. Hansen og jeg selv var lærere. Jeg udviklede og underviste et fag for hvert af uddannelsens tre år. Fagene blev gradvis mere forretnings- og brugerorienterede, fx hvordan en Magasin-regning hænger sammen med data i en database.

De to første år ledte jeg samtidig på Regnecentralen en projektgruppe der udviklede fler-bruger operativsystemet Boss 2 til RC4000.

1973-76: Min tid på BBC (nu ABB)

BBC var et svejtsisk firma, der lavede store industrisystemer, fx kraftværker og transformerstationer. De lavede en afdeling i Danmark, bemandet af 6 udbrydere fra Regnecentralen, herunder mig. Vi lavede systemer til overvågning og styring af el-nettet. Takket være Jørgen Green, der som elektroingeniør virkelig forstod brugernes behov, fik vi lavet nogle fantastiske brugergrænseflader, der med en farveskærm på 32 linier, hver med 64 tegn i 8 farver, kunne vise et kort over en transformerstation og dens mange el-ledninger ud i landskabet, hver med en grafisk angivelse af antal ampere lige nu og stillingen af "bryderne" (dvs. kontakter der kan afbryde stærkstrøm på 100 A). Fascinerende at kunne klikke på en bryder - og så har de ingen strøm i Himmerland.

1974-75: Et år i Ghana

For at se noget helt andet, havde jeg søgt og fået en 1-årig stilling som IT-ekspert i Ghana. Jeg fik orlov fra BBC og flyttede med familjen til hovedstaden, Accra. Det var nok det mest lærerige år i mit liv. Min familje og jeg levede mellem de indfødte, havde indfødte venner og meget lidt kontakt med de hvide i landet. Meget var anderledes end derhjemme, fx troede alle fuldt og fast på trolddom (witchcraft), men alligevel fungerede samfundet så nogenlunde - bortset fra korruptionen, som vi aldrig vænnede os til.

Min arbejdsgiver var ILO (International Labour Office), som finansierede det lokale MDPI (Management, Development and Productivity Institute). Jeg havde forestillet mig at der var nogle administrative anvendelser, som jeg skulle programmere - eller undervise nogle lokale der så kunne tage over. Men ingen vidste hvad jeg skulle lave - det måtte jeg selv finde ud af. Jeg prøvede at undervise mine sorte kolleger i programmering, så de kunne forklare ministre mv. hvad man kunne bruge en computer til. Men det lykkedes ikke.

Jeg undersøgte hvad der svarer til det danske cpr-system, men sådan et havde Ghana ikke. Hvert ministerium havde sin egen computer med sit eget personregister. Fx havde valgministeriet sin egen computer og egen personfortegnelse, skat en anden computer med sin egen personfortegnelse, osv. Så borgeren havde et nummer hvert sted. Numrene var fortløbende tal på 8 cifre (skrevet uden mellemrum), svarende til potentielt 100 millioner personer (Ok, Ghana havde ca. 9 mio indbyggere). Der var ingen check-cifre eller andre kontroller, men alle registreringer blev tastet to gange for at fange tastefejl.

Jeg foreslog at gøre som i Danmark og det vakte interesse, men man kunne ikke finde ud af om det var ILO-bevillingen eller regeringen der skulle betale - og så skulle jeg jo kun være der 5 måneder endnu. Desuden var der det problem at ghanesere ikke kender deres fødselsdag, men til gengæld den ugedag de var født.

Jeg havde kun én IT-succes: To canadiske vej-eksperter var udstationeret i Accra for at hjælpe regeringen med vedligehold af landets vejnet. Landet havde ca. 12 regioner, hver med en "borgmester". De mødtes i Accra for at aftale hvordan den årlige bevilling til vejarbejde skulle fordeles mellem regionerne. Der var selvfølgelig vild uenighed om fordelingen. Men canadierne havde normtal for hvor meget der var behov for pr. km grusvej, pr. km asfalt, pr. drænløb under vejen, etc. Normtallene afhang af den årlige regnmængde og varierede derfor fra region til region.

De havde allerede tallene for hver region. Kunne jeg lave et program der regnede omkostningerne ud for hver region? Det var jo lige til et regneark (som ikke var opfundet den gang). I stedet brugte jeg et hulkort pr. region med regionens tal. Computeren læste de 12 kort, printede en overskriftslinie og derunder hvert kort på en linje med det samlede beløb til sidst og landstotalen nederst. Canadierne var glade, men jeg var skeptisk. Druknede det ikke bare i politik? Et par dage efter kom canadierne: Det var gået fantastisk. Alle kunne jo se hinandens tal og forstod pludselig hvorfor nogle havde været så ophidset.

Hvad lærte jeg så i Ghana? At viden om ledelse, organisation og økonomi var afgørende, og at jeg var ignorant på alle tre områder. Jeg fik lært bogholderi dernede med en teach-yourself bog, og tog en HD-uddannelse da jeg kom hjem. Det skulle jeg have gjort mange år før.

1976-79: Gæsteprofessor på DIKU (Datalogisk Institut ved KU)

Jeg tog mod et tilbud om at blive gæsteprofessor på DIKU. Forskningsmæssigt var jeg interesseret i operativsystemer der bestod af moduler, der kunne skiftes ud under driften. Desuden var der meget der skulle ryddes op i på DIKU, både undervisningsmæssigt, forskningsmæssigt og økonomisk, så de sidste 2 år var jeg institutleder.

Undervisningsmæssigt fik jeg indført meget om alt det der ligger uden for programmering. Fx startede Dat 1 i 1978 med at se på annoncer efter edb-folk, fx systemplanlægger, driftsoperatør, driftsplanlægger og forklarede hvad sådan nogle gør. Der var meget om databaser, sikkerhed, behovsanalyse og økonomi. Og der var detaljerede case-studier om bedre systemer til fx repro-branchen.

DIKU kunne ikke skaffe lærere nok, bl.a. fordi de ikke havde stillinger nok. Dekanen ville ikke tale om det (for så skulle han afskedige folk ved andre institutter). Det endte med at jeg skrev direkte til undervisningsministeren, samtidig med at jeg fik direktør Chr. Rovsing til at henvende sig til ministeren om mangel på dataloger i industrien. Resultatet var en særbevilling til DIKU - og en "næse" til mig fra ministeren - for at gå uden om både dekan og rektor.

1979-85: Min tid på NCR

NCR var et af de store, amerikanske IT-firmaer. De havde gennem deres danske salgsafdeling hørt om dygtige IT-folk i Danmark og besluttede at lave en dansk udviklingsafdeling på ca. 30 personer. Jeg kom med og blev afdelingsleder med to ansvarsområder: Kvalitetssikring og "advanced development". Kvalitetssikring af software var på mode, men svært at gøre noget ved. En af vores dygtigste udviklere, Jens Brix Christiansen, viste sig at være et geni - også på det område. Han fik specificeret og idriftsat en systematisk og pragmatisk tilgang til kvalitetssikring. Hvor andre virksomheder frygtede kvalitetskontrollen, blev Jens's tilgang budt velkommen. Han evnede at formidle gode ideer mellem afdelingerne og at gøre kontrollen til en hjælp, så udviklingen gik lettere.

Jeg tog mig af Advanced Development, som skulle være nye produkt-ideer. Jeg havde tre på beddingen: Det modulære operativsystem, regneark og et højniveau programmeringssprog (DocDB). Det vi kender i dag som regneark fandtes ikke den gang. Jeg havde set hvordan økonomer opstillede diverse regnskaber i ark og manuelt beregnede indholdet af arkets celler. Såvidt jeg kunne se, kunne man give dem et værktøj hvor de kunne skrive formler i nogle af cellerne - så beregnede computeren selv resultatet. Vi valgte det modulære operativsystem. Det var meget heldigt, for året efter blev regnearket VisiCalc introduceret.

Ideen med DocDB var at udvikle systemer ved at opbevare alt input til systemet (dokumenter og skærmbilleder) i en temporal database, uden at splitte data ud i database-tabeller. Alle resultater fremkom ved at udtrække data fra det rå, gemte input. Vi fik støtte fra Teknologistyrelsen. Det projekt gik helt i fisk: De beregninger der skulle udtrække data, blev komplicerede. Vi var ikke gode til at lave interaktive systemer, og tidlige brugervenlighedstest viste at systemet var meget langt fra noget en almindelig bruger kunne anvende. Da vi lukkede projektet, havde vi produceret 66.000 linier kode. (Der kan man se hvad der kan ske, hvis man tror man kan springe E/R datamodellen over.)

IT-verdenen begynder at snakke om "expertsystemer", som svarer til hvad vi i dag kalder AI (kunstig intelligens). Under Erik Reehs ledelse prøver vi også det. Et eksempel var et ekspertsystem der kunne hjælpe supermarkeder med at bestille den optimale mængde af hver vare, så der kommer mindst muligt spild på forældede varer. God idé - men resultatet var overraskende: Hvis man stræbte efter nul forældede varer, skulle man bare bestille nul af dem - selvfølgelig! Så det var noget andet man skulle optimere, noget med den samlede fortjeneste. Men ansatte i butikken må ikke kende avancen på varerne - og så gik projektet i stå.

Hvad med det modulære operativsystem? Jeg fik til opgave at finde samarbejdspartnere, så NCR ikke stod alene med et nyt operativsystem til de PC-er der spirede op overalt. Så jeg rejste med skiftende kolleger rundt mellem de store leverandører, Microsoft, Intel, DEC, mv. for at sælge ideen. Nogle var interesserede, men ville have eneret. Microsoft mente de selv havde det nødvendige, men tilbød mig et job.

NCR havde i Danmark solgt én licens på det modulære operativsystem. Det havde jeg glemt alt om, men ved et tilfælde møder jeg i 2022 en medarbejder fra det firma der købte licensen. Systemet var blevet en stor succes hos dem og blev stadig brugt.

1985-99: Professor på Handelshøjskolen i København (HHK, nu CBS)

Handelshøjskolen besluttede at oprette en uddannelse i datalogi og økonomi (DØK). De opslog et professorat og bad mig søge. Det gjorde jeg, blev valgt, sagde pænt farvel til NCR, og startede et nyt liv.

HHK havde til formålet oprettet et nyt institut, DASY, Institut for Anvendt Datalogi og Systemvidenskab. I princippet skulle vi lave det samme som på DIKU, men mere virksomhedsorienteret. Til en begyndelse startede vi med et programmeringskursus der benyttede dBase II - et database-system til PC-er. Manualer, mv. til det, var ubrugelige, så jeg eksperimenterede mig frem til hvordan systemet virkede og skrev en manual (opslagsbog) til det.

Vi havde store bemandingsproblemer, men fik flere dygtige forskere/lærere til at arbejde på sagen. Men hvad skulle vi med Systemvidenskab? De kørte deres eget løb, som bl.a. inkluderede filosofi og operationsanalyse. Jeg savnede målbeskrivelser for kurserne ("hvad skal den studerende kunne efter kurset og hvordan måler vi det"). Jeg trivedes ikke og skrev kun to publikationer i perioden 1985-89 (den ene er dBASE II manualen, den anden handler om gode brugervejledninger). Desuden forsøgte jeg og kolleger at lave bedre værktøjer til at udvikle interaktive systemer, men fik ikke publiceret noget.

I dag kan jeg se hvad rod-problemet var: Vi underviste i og udviklede værktøjer, vi mente virksomheder og organisationer havde brug for. Men vi anede ikke hvad de reelt skulle bruges til. Vi havde ikke de rigtige kontakter.

Trods alt fik vi skabt en succesfuld uddannelse, som stadig (2023) tiltrækker mange studerende. Mange af de gamle studerende er i dag mine dygtige kolleger, som jeg møder i flere sammenhænge.

1989: Flytter til Institut for Informatik og Økonomistyring (IIØ)

I 1989 er jeg så frustreret at en gruppe kolleger beder mig finde et andet job. Jeg går til rektor og klager min nød. Han fortæller at min situation er meget almindelig på HHK, og foreslår at jeg snakker med IIØ. Det går godt. 1/9 1989 flytter jeg - med professoratet - til IIØ og en ny tid begynder. IIØ har kontakt med mange IT-folk i industrien og jeg finder gradvis ud af hvor IT-problemerne ligger og hvad man kan gøre ved dem. De største problemer er kravspecifikation og brugergrænseflader. Nogle siger at det er håbløst at løse de problemer - så den udfordring tager jeg op.

I 1992 bliver jeg valgt til institutleder på IIØ, og bliver på posten til 1999, hvor jeg flytter til IT-Universitetet (ITU).

I 1993 har jeg sammen med Morten Harning udviklet en metode til at designe brugergrænseflader. Den går ud på at lave en datamodel for systemet, og derefter udforme skærmbilleder der viser uddrag af data på en måde brugeren kan forstå og udnytte. Med dataflow-diagrammer sætter vi dernæst funktionalitet på - som senere bliver til knapper, menuer, mv. Vi skriver en artikel om det og får den optaget på en konference i Wien.

Da vi har præsenteret metoden på konferencen, stiller en IBM-medarbejder sig op og påstår, at sådan har IBM gjort i årevis. Dyb tavshed - hvordan kan man modbevise det? Så rejser en kinesisk pige sig og siger: Jeg har læst alt der er skrevet om dette emne: Der er ingen der har gjort noget der blot minder om det vi har set. Wow! Jeg vandt. Pigen hed Liz Chang, var fra Australien og havde aldrig før været i Europa. Ville jeg være hendes guide? Ja selvfølgelig (selvom jeg aldrig før havde været i Wien). Hun foreslår at jeg næste år kommer til OZCHI-konferencen i Melbourne, hvor hun bor.

1993: Software til apparater

I årene 1988-93 sad jeg i Statens Teknisk-Videnskabelige Forskningsråd, kommission E. En af de ting man diskuterede her var hvordan det stod til med software der blev indbygget i apparater. Jeg blev bedt om at undersøge sagen og skrive en rapport. En af de ting der skulle belyses var samspillet mellem universitetsuddannelserne og praksis. Jeg fik Bodil Schrøder og Jan Pries-Heje med på projektet.

Der var mange resultater, fx at forskere troede de vidste hvad industrien havde brug for, men reelt ikke forstod behovene. Fx troede man at matematisk specifikation af kravene var løsningen. Samtidig havde virksomhederne også selv svært ved at forstå deres egne problemer. Især var der store problemer med kravspecifikation og kvalitetssikring. (Når jeg ser på situationen idag (2023), er der ikke sket de store forbedringer).

Resultaterne er publiceret i: Bodil Schrøder, Søren Lauesen, Jan Pries-Heje (1993): Software til apparater: Industri kontra forskning (pdf). Copenhagen Business School, 70 pages. ISSN 0903-6571 93/1. Den internationalt publicerede version er: Soren Lauesen, Jan Pries-Heje, Bodil Schrøder (1993): Embedded Software: Industry Versus Research (pdf). Proceedings of IRIS, Copenhagen, 11 pages.

GIER's betjeningspanel

1994: Liz Chang og Søren ved Wilson's Prom. Vi fodrer de lokale "gråspurve".

1994: Det lykkes at få en artikel optaget på OZCHI i Melbourne (en udbygning af den fra Wien, 1993). To af mine studerende har også fået en artikel optaget der: De har eksperimentelt bevist at brugervenlighedstest af en papir-prototype kan være lige så effektiv som en test med det rigtige system. Sammen med en af deres veninder tager vi til en anden veninde der bor i Sydney. Nogle af os tager senere videre til konferencen i Melbourne. Det bliver en festlig affære. Jeg bliver lidt længere, for Liz Chang har lokket sin chef (Tharam fra Malaysia) til at køre os alle tre på sightseeing i Melbourne-området, med overnatning i chefens sommerhus, nær Wilson's Prom.

1994: Objekt-orientering (OO) i praksis

I årene 1994 til 2002 hørte vi lovsangene om at hvis IT systemer blev baseret på Objekt-Orienteret Arkitektur (OO), ville alt gå let og smertefrit. Med OO deler man verden op i objekter. Hvert objekt indeholder noget data og nogle funktioner som andre objekter kan trække på. Teoretikerne kom hele tiden med små eksempler på OO-systemer, fx kaffekander og cykler. Men skalerede det op? Næ, der var store problemer, fx med at få databasen til at hænge sammen med brugergrænsefladen - og samtidig gøre den brugervenlig.

Jeg undersøgte i detaljer 3 danske virksomheder der brugte objekt-orienteret udvikling. Der var kun én af dem der havde succes med det (det danske firma ObjectDesign, senere kaldt The Danish Object Company). Jeg skrev en artikel om det i Computer World under titlen Kejserens nye objekter. ComputerWorld var den gang et debatforum med en tænksom redaktør, så det ikke blev ren mudderkastning. Alligevel blev det en lang debat.

1996-97: Sabbatical i Melbourne

Jeg har undervist og administreret så meget på Handelshøjskolen, at jeg får bevilget et års sabbatical. Jeg vil gerne knække nødden om hvordan man skriver brugbare krav til IT-systemer. Jeg finder ud af at Swinburne University i Melbourne arbejder med den slags. De vil gerne være min vært. Desuden har de Brian Henderson-Sellers som gæst. Han er en af guruerne på OO-området og mener, at hvis blot alt laves objekt-orienteret, vil systemet blive en succes.

Da vi mødes i Melbourne, fortæller jeg hvad jeg har fundet i Danmark. Men Brian insisterer: Det må være nogle rigtigt dårlige eksempler, siger han. Han sætter mig i kontakt med 4 virksomheder i Australien, som gør det "rigtigt", mener han. Dem besøger jeg, og det viser sig at de har de samme problemer som de danske. Ved et internt seminar på Swinburne, prøver Brian at redde æren, men han ender i "kaffekande-eksempler".

Heldigvis er han nysgerrig og vi får et frugtbart samarbejde, også med andre på Swinburne. Bl.a. undersøger vi om OO-præsentationerne for de studerende er "brugervenlige", og konkluderer at det er de ikke.

Jeg publicerede resultaterne om OO og mine egne erfaringer: Soren Lauesen (1998): Object-Oriented Systems in Real Life (pdf). IEEE Software, 1998, March/April, p. 76-83. Blev også publiceret i et japansk tidsskrift og en japansk bog: Nikkei Computer, 1998.6.22, p. 209-217, og Nikkei Computer Books, ISBN 4-8222-0771-4, p. 118-129.
Se også: Soren Lauesen (1998): Data bag publikationerne ovenfor

Hvad er status så i dag? OO er fremragende til at definere hvad der skal være i IT-systemet. Fx er de vidt udbredte programmeringssprog Java og C#, objekt-orienterede. Hver dims du ser på skærmen (fx tekstbokse og knapper) er et objekt. Det indeholder data, fx om dimsens størrelse, placering og farve. Og det indeholder funktioner, fx en funktion der gør noget når man klikker på dimsen. Det var den slags objekter ObjectDesign havde opfundet. Der er også en database der indeholder data om brugerens verden, fx posteringer på en bankkonto. Men de er ikke rigtigt objekter. Og så er der en masse objekter med teknisk formål, fx til opdatering af skærmbilledet eller ændring af databasen når brugeren klikker. Men de svarer ikke rigtigt til noget i brugerens verden.

1998: Vi opfinder Task Descriptions

Vestsjællands Amt havde dårlige erfaringer med kravspecifikationer. Jeg får et tip fra en af IIØ's kontakter om at Amtet nu skal anskaffe et nyt system til vagtplanlægning. Der er tre mulige leverandører i Danmark. Sammen med Marianne Mathiassen (specialestuderende) arbejder jeg på at skrive kravspecifikationen. Vi viser amtets IT-folk forskellige former for krav, og umiddelbart synes de at Use Cases ser mest lovende ud. Men de duer ikke rigtigt fordi man i en use case skal beskrive den ønskede dialog med systemet i to kolonner: Hvad brugeren gør til venstre og systemet svarer til højre. Men det er svært og man kan let komme til at forfordele en af leverandørerne ved at beskrive netop hans dialog. Og skal vi skrive hvad der sker i dag eller hvad vi ønsker der skal ske? Og hvad hvis leverandøren har et system der gør det lidt anderledes? Vi prøver mange kombinationer af menneske/maskine og nu/fremtid.

Vi ender med det jeg senere kalder task descriptions: Et task begynder når en bruger skal bruge systemet og slutter når brugeren skal noget andet, fx gå til frokost. Der er to kolonner: Venstre kolonne beskriver hvad menneske og maskine tilsammen skal gøre (behovet, problemet eller "tasket"). Højre kolonne beskriver hvad systemet skal gøre (løsningen). Kunden må godt skrive et forslag i højre kolonne, men forslaget er ikke et krav. Leverandøren giver et tilbud hvor han har udfyldt højre kolonne, eller bare sagt ok til kundens forslag.

Kravet er at alle de specificerede task skal støttes, men det kan gøres mere eller mindre godt. Hvor godt de støttes, kan være en del af tildelingskriterierne når kunden skal vælge mellem flere leverandører der har givet tilbud.

Vi interviewer og observerer de forskellige slags brugere i amtet og beskriver de task systemet skal støtte - otte i alt. Så præsenterer vi disse krav for kunden (amtet), som bliver meget begejstret. Desværre viser det sig at amtet, mens vi arbejdede med metoden, havde gennemført udbuddet (med deres egne krav) og skrevet kontrakt med en af leverandørerne. Men nu kan kunden se hvad systemet egentlig skal bruges til, og opdager at han har valgt en forkert leverandør. Han havde bl.a. forventet en økonomisk gevinst på 160 mio kr. pr. år, ved at spare overarbejdspenge. Med den valgte leverandør får han dem ikke. Vi viser også vores nye krav til leverandørerne (én leverandør ad gangen). De er også meget positive, bl.a. fordi det vil blive muligt for dem at vise hvordan de kan overgå kundens forventninger. Task-begrebet ser ud til at være win-win for alle parter, så det er lovende for nye projekter.

1999-2002: Lærebøger om kravspecifikation

Task-begrebet svarer til det man traditionelt kalder funktionelle krav. Men det er kun en del af IT-kravene. Hvad gør vi ved de andre kravområder, fx datakrav, brugervenlighed, sikkerhed, rapporter, integration med andre systemer? Det eksperimenterer jeg med i forbindelse med en lang række projekter. Hvert kravområde har sine egne regler, og vi kan ikke bare skelne mellem funktionelle og non-funktionelle krav. Men der er et fælles princip jeg kalder problem-orienterede krav: Beskriv ikke hvad systemet skal gøre, men hvad det skal bruges til eller hvilke problemer det skal løse. Lad leverandøren beskrive hvad hans system kan gøre.

Langsomt gror der en lærebog frem: Software Requirements, Styles and Techniques, Samfundslitteratur, 2000, 191 sider, heraf 70 sider med klassiske krav fra virkelige projekter, bl.a. et skibsværft. Dansk Dataforening (nu Dansk IT) opfordrede mig til at udgive de mest centrale ting som et lille hæfte på dansk. Det blev til IT-anskaffelse, Kravspecifikationen. Dansk Dataforening, 2000, 75 sider, heraf 7 sider om brugervenlighed og hvordan man opnår den.

Senere blev det til en international lærebog: Software Requirements, Styles and Techniques, Pearson/Addison-Wesley, 2002, 591 sider. Den gennemgår alle de klassiske kravområder, fx funktionelle krav, datakrav, kvalitetskrav, hvordan man finder kravene og tester dem. For hvert område er der realistiske eksempler og diskussion af gode og dårlige teknikker. Desuden er der 5 eksempler på kravspecifikationer fra virkelige projekter - med diskussion af hvad der gik godt og skidt.

1999-2019: Professor på IT-Universitetet

En dag banker Mads Tofte på min dør på Handelshøjskolen. Han forklarer at han er ved at oprette et universitet dedikeret til IT. Hverken KU, DTU eller Handelshøjskolen giver de kvalifikationer som IT-industrien efterspørger. Vil jeg være med? I første omgang skal det være kurser på kandidatniveau, dvs. at deltagerne kommer med forskellige bachelor-områder og så læser IT. Jeg sover på det og siger så ja.

Mads samler en lille kerne af folk med forskellige perspektiver på sagen. Sammen definerer vi hvad man skal kunne som uddannet fra ITU: Alle skal på et grundlæggende niveau kunne det tekniske, det brugermæssige og det forretningsmæssige, som der er behov for i et IT-projekt. Derudover kan man specialisere sig inden for et af områderne. Ligesom der står i min krav-lærebog, anvender vi fokusgrupper med potentielle studerende, virksomheder og lærere, for at få ideer til uddannelsen.

Der kommer hurtigt lidt grus i maskineriet, for skal alle fx kunne designe et IT-system? Og hvad vil det sige at "designe" et system. Nogle mener at bare man studerer og beskriver i detaljer hvem brugerne er og hvad de gør i dag (den antropologiske tilgang), så har man lavet analysearbejdet og kan overlade resten til programmørerne.

For mit vedkommende bidrager jeg med to kurser: Et i design af brugergrænseflader og et i at anskaffe IT-systemer, herunder skrive en kravspecikation.

Brugergrænsefladekurset holder jeg ca. 20 gange i perioden 1999-2010 i forskellig kontekst, fx som del af bachelorstudiet eller åbne uddannelser. Kurset bliver langsomt overdraget til andre, desværre folk med beskeden praktisk erfaring.

Kravspecifikationskurset holder jeg ca. 20 gange i perioden 2006 til 2019 som aftenkursus med 30-50 deltagere, fx studerende og folk fra industrien. På kurset skal man sideløbende med undervisningen skrive en kravspecifikation for et virkeligt projekt. Man arbejder i grupper på højst 4. Det viser sig at grupper med en kombination af erfarne IT-folk og studerende fungerer rigtig godt. Kravene skal i princippet kunne gives til en leverandør. Ved eksamen er censor en med erfaring fra IT-anskaffelser, fx en leverandør eller konsulent.

2001-2002: Systematisk design af brugergrænseflader

I 2001 til 2002 var jeg igen på sabbatical i Melbourne. Jeg havde styr på hvordan man skriver krav, men hvordan kommer man på en systematisk måde herfra til brugergrænsefladen? Jeg havde sammen med Morten Harning skitseret og publiceret en metode vi kaldte Virtual Windows, IEEE Software, 2001 (Det er en udbygning af den fra Wien, 1993). Nu prøver jeg i detaljer at designe, implementere og usability-teste det gennemgående eksempel: et system til hotel-receptionister. De Australske studerende er heldigvis meget villige til at være testpersoner og de Australske hoteller villige til at forklare de systemer de har og hvad problemerne er.

For at lave prototyper med funktionalitet, er jeg nødt til at lære hvordan man programmerer en brugergrænseflade der kommunikerer med en database. Det er meget, meget svært. Værktøjerne passer ikke sammen og der er ingen brugbare lærebøger. Det viser sig at det letteste er at bruge MS-Access, som både har database og nogle muligheder for skærmbilleder og funktionalitet (Visual Basic). Det går op for mig, at hvis jeg troværdigt skal undervise i at designe brugergrænseflader, er jeg nødt til også at kunne programmere dem. Mens jeg lærer det, skriver jeg en MS-Access lærebog.

I 2005 bliver design-erfaringerne til en lærebog på Addison-Wesley: User Interface Design - A Software Engineering perspective, 603 sider. Den bliver lærebogen på de kurser jeg holder i over 10 år på IT-Universitetet i første semester. Access-lærebogen stiller jeg til rådighed på mit web-site og som et hæfte til undervisningen.

Det viser sig at der er et enormt behov for den Access lærebog, og den downloades i massevis til kurser over hele verden. Desværre er der ikke den samme efterspørgsel efter design-bogen.

2003: Fyns Amt EPJ - Elektronisk Patient Journal

I 2003 skulle Fyns Amt anskaffe et nyt EPJ-system. De havde hørt om task-metoden til at formulere krav - og fordelen fremfor use-cases, der ellers var på mode. Vi etablerede et samarbejde, hvor jeg stod for datamodel og task - de to centrale dele af kravene. Resultatet var en succes for Amtet.

2005-2017: EPJ strategi - visioner og realiteter

Jeg har i perioden været blandet ind i EPJ-anstrengelserne på flere måder, fx den nationale strategi, økonomien, valg og anskaffelse af Sundhedsplatformen (EPIC). Se: EPJ - Elektronisk patientjournal

2006: Masteruddannelse i IT-ledelse

I 2006 beder ITU mig om at starte en masteruddannelse i IT-ledelse i samarbejde med Bo Svarre Nielsen, som har omfattende erhvervserfaring og mange kontakter. Vi starter med at mødes med nogle af kontakterne for at samle potentielle emner og potentielle undervisere. Vi sætter en stor tabel op der viser sammenhængen mellem emner og undervisere. Og så prøver vi at fordele emner på personer, mødes med dem for at give kurset et navn, og fastlægge indhold og læringsmål - og for at lokke dem til at undervise. En af lærerne fandt jeg, fordi vi tilfældigvis var kommet til at sidde ved siden af hinanden ved et møde i Landstingssalen om elektroniske patientjournaler.

Planen lykkes! Jeg deltog selv i nogle af kurserne, fx et om supportfunktionen (en del af ITIL-standarden). Kurset startede med at vi skulle lege supportere ved Apollo 13 rum-missionen. Vi fik de meldinger som optrådte i den virkelige mission og skulle håndtere dem ved at finde oplysninger hos de rette specialister. Det var uhyre stressende selvom det bare var en leg. Undervejs holdt vi en pause - puuh - og overvejede en anden måde at organisere os på. Og så fortsatte vi med den nye organisation. Glimrende kursus!

2007: Uvis-projektet opstår

Baseret på erfaringerne med EPJ, indser jeg at der er et stort behov for systemer der har én database, men mange brugergrænseflader. Fx behøver et hospital kun én database med patienter, diagnoser, behandlinger, osv. Men hvert speciale har brug for sin egen brugergrænseflade. Ideelt burde specialeafdelingens IT-nørd kunne lave afdelingens brugergrænseflade, men med eksisterende IT-værktøjer er det alt for svært.

I princippet er det ikke svært: En brugergrænseflade består af visuelle komponenter som tekstbokse, knapper, rammer og grafer. Hver komponent har nogle egenskaber, fx lodret og vandret position, højde, bredde, farve, og det data komponenten skal vise. Vi skal "bare" skabe komponenterne og beregne de rigtige egenskaber.

Vi kan lade hver komponent udregne sine egne egenskaber, fx at den vandrette position af tekstboks A skal være 5 pixels til højre for komponent H. Den tekst A viser, skal den tage fra et talfelt i databasen. Farven skal være rød hvis tallet er større end det tal brugeren lige har indtastet i komponent B. Det sker ved at hver egenskab har en formel der beregner farven, tallet eller teksten.

Princippet svarer til et regneark: Hver celle i arket har en formel der beregner sig selv ud fra indholdet af andre celler. Med Uvis er det dog ikke celler der skal beregnes, men komponenters egenskaber. En person der kan det der med regneark, burde også kunne lave brugergrænseflader med vores værktøj.

Jeg søger videnskabsministeriet's NABIIT pulje om midler til at lave sådan et værktøj, og sammen med en tilsvarende bevilling fra IT-Universitetet, står jeg med 11 mio. kr til projektet. Ud over at lave værktøjet, skal jeg også sørge for at 4 personer får en Ph.D. grad.

Det lykkes at bemande projektet med 4 potentielle Ph.D'er: Mohammad Kuhail (statsløs palæstinenser), Shangjin Xu (kineser), Kostas Pandazos (græker) og Søren Lippert (thoraxkirurg med IT som hobby). Desuden fik vi allieret os med ortopædkirurgisk klinik på Bispebjerg Hospital og privathospitalet MyClinic i Allerød.

2007: SL-07 opstår

I 2007 nedsatte VTU (Ministeriet for Videnskab, Teknologi og Udvikling) et udvalg, der skulle skrive en standardkontrakt (K02) for IT-anskaffelser. Kontraktens bilag 4 er kravspecifikationen og de ville gerne vise en eksemplarisk en. Kunne jeg lave sådan en? Jeg havde i flere projekter lavet de vigtigste dele af kravene - task og datamodel - men ikke alt det andet, fx sikkerhedskrav, brugervenlighed, systemintegration og tildelingskriterier. Jeg kunne jo tage udgangspunkt i den elektroniske patientjournal fra Fyns Amt og gøre den til den eksemplariske kravspecifikation? Efter en dags betænkningstid tilbød jeg at gøre det på 35 timer - OK.

Senere skrev jeg en vejledning til kravene, hvordan man finder dem, hvorfor de ser ud som de gør (problem-orienterede), hvordan man tester om de er opfyldt, mv. Mine studerende på semestrets krav-kursus kunne bruge kravene som skabelon og de var meget begejstrede. Men det hele skulle have et navn, sagde de. Kontrakten hed jo K02 - kunne kravene hedde SL07 (Søren Lauesen 2007)?. Hvad med SL-007 som agent-007? Pas nu på med overmod, så det blev SL-07, også kaldet problem-orienterede krav. Den kom også på engelsk og blev jævnligt opdateret. Vejledning plus krav var først 72 sider (2007), men groede til 128 sider (version 9, 2022). Fra 2018 (version 6) indeholder SL-07 også en eksemplarisk kontrakt, og krav til støtte af projektlederen. Se: Problemorienterede krav.

2008: Søren Lauesen: Kan SOA gå på vandet? (Indlæg i ComputerWorld)

I årene 2004 til 2008 hørte vi lovsangene om at hvis IT systemer blev baseret på Service-Orienteret Arkitektur (SOA) ville alt gå let og smertefrit. Alle systemer kunne arbejde sammen. Garvede rotter i faget havde hørt tilsvarende lovsange før, fx om at hvis bare alting var objekt-orienteret ville det hele gå fint.

Jeg havde observeret flere store SOA satsninger som løb ind i alvorlige problemer. Der var simpelthen nogle basale problemer ved SOA som man overså - eller fortiede. I 2007 fik jeg optaget artiklen Kan SOA gå på vandet? i ComputerWorld. Jeg fik mange anerkendende henvendelser. Nogle havde spurgt deres lokale IT arkitekt om det virkelig var rigtigt hvad jeg skrev. Svaret var: "Ja, og det er endda endnu værre". Se: Kan SOA gå på vandet? (pdf)

2009: IBM er interesseret i SL-07

IBM markedsførte deres egen udviklingsmetode, kaldet Rational. Den bestod af en lang række skabeloner projektledelsen skulle udfylde. Men de viste aldrig eksempler på udfyldte skabeloner. Fx havde de en skabelon med et felt der hed Forretningsmæssige mål. Inden i feltet stod der: Her skriver du de forretningsmæssige mål. De havde set at SL-07 altid viste realistiske eksempler på forretningsmæssige mål, krav, mv. De foreslog at vi arbejdede sammen for at se om vi kunne lave en ny "Rational". Det prøvede vi intenst i en uge, men konklusionen blev at det meste af deres materiale skulle laves om og deres tusinde konsulenter worldwide omskoles. Og så var jeg jo ikke nogen forretningsmæssig trussel.

2009: Jeg bliver konsulent for Rigsrevisionen

Jeg havde et par gange holdt indlæg for Rigsrevisionen. En af gangene var et seminar i Hofteatret hvor leverandører og myndigheder forklarede hvordan de så de store IT-anskaffelser. Jeg var efterhånden blevet troværdig og da Rigsrevisionen skulle undersøge den Elektroniske Tinglysning (eTL), kom jeg med på vognen. Jeg startede med på egen hånd at spørge et par advokater og ejendomsmæglere om deres oplevelser med eTL, som lige var sat i drift. Så var jeg forberedt - men det var en meget utraditionel måde at gøre det på. Rigsrevisionen plejede kun at spørge den myndighed de skulle undersøge. De gik tøvende med til at vi også snakkede med leverandøren (CSC, tidligere Datacentralen), og var overraskede over at CSC var meget interesseret, og at vi nu fik en helt anden forklaring af hvad der var sket.

Man kan kun være konsulent for Rigsrevisonen i 4 år - for at man ikke skal blive alt for indspist. I mine 4 år var jeg med til at undersøge mange store og mindre sager, bl.a. Rejsekortet, PolSag (Politiets nye sagsbehandlingssystem), EFI (SKAT's Gældsinddrivelse), STAR (Styrelsen for Arbejdsmarked og Rekruttering). Se mere: Damages and Damage Causes.

2009 og frem: Hvordan store IT-projekter forulykker:

Siden 2009 har jeg fået indsigt i hvad der sker i store IT-projekter, især de offentlige. I begyndelsen var det som konsulent for Rigsrevisionen, der skulle undersøge diverse IT-katastrofer. Senere var det på egen hånd. Se: Damages and Damage Causes.

For en programmør som mig, var det interessant at se hvor problemerne kom fra. Offentligheden - og mange IT-forskere - tror det er programmeringen der er noget galt med. Det var derfor overraskende at se, at næsten alle ulykkerne stammer fra analytikerne, konsulenter, ledelsen og manglende brugervenlighed.

I alt har vi fundet 36 årsager til IT-katastrofer, fx at kravene ikke dækker kundens behov, at man ikke planlægger de nye arbejdsprocesser, at der ikke er nogen forretningsmæssige mål - eller at man glemmer dem, at man ikke tester brugervenligheden, at man ikke finder rodårsagerne til problemerne. Hvert af de 5 store projekter jeg har undersøgt, lider af ca. 13 af dødsårsagerne. Hver af årsagerne er observeret mindst to gange.

Forskning og metodeudvikling på programmeringsområdet har sejret. Det er ikke der det halter. Jo, der er fejl som først opdages sent, men ikke noget der skaber katastrofer. Jeg har kun fundet én undtagelse: Service-Orienteret arkitektur (SOA), som stadig forpester store IT projekter. SOA er uhyre indviklet og mærkværdigvis er der ingen der forsker i årsagerne eller foreslår løsninger. Alternativet er en fælles database, der evt. kan replikeres. Christoffer Pagaard har i 2017 sammenlignet de to muligheder: Service-orienteret arkitektur (SOA) kontra fælles database. Han har en klar konklusion: Den fælles database er hurtigst, mest driftsikker, og lettest at vedligeholde og udbygge.

2010: Hvordan gik det så med SL-07 i Danmark?

SL-07 var jo beregnet til Statens K02 kontrakt, som de fleste af Statens IT-projekter brugte. Hvordan gik det? Jeg snakkede med Statens IT. De havde prøvet med flere projekter, men SL-07 virkede ikke, sagde de. Kammeradvokaten havde endda frarådet SL-07, sagde de - hvad Kammeradvokaten benægtede, da vi mødtes ansigt til ansigt. Statens IT sagde at det bedste eksempel de havde på et SL-07 projekt, var energimærkningen. (Et energimærke er en attest på hvor godt en ejendom er isoleret. Sælgeren af en ejendom skal bede en energikonsulent om at lave attesten.) Jamen så send mig kravspec'en og lad os mødes og se på det, sagde jeg.

Spec'en viste sig at være totalt misforstået. Her er det bedste task, jeg kunne finde. Data har man helt opgivet at beskrive i kravene:

   C3. Modtagelse af data fra felter i XML-fil
   1. Modtag data fra XML-fil.
   2. Systemet skal returnere en fejlmeddelelse.
   . . .
   D. Data . . . Vil blive beskrevet senere

Dette ligner i opstillingen nogle SL-07 krav, men de er det rene vrøvl. Et task skal være noget menneske og maskine gør sammen - fra "trigger" til "kaffepause". C3 er tydeligvis ikke et task. Hvem skal udføre dette? spurgte jeg. Det var der ingen der vidste.

Hvem skal bruge systemet? spurgte jeg. Det var da et godt spørgsmål, svarede de. Ved at forene vores viden, kunne vi på 10 minutter liste de brugergrupper der er: Sælgeren af ejendommen, energikonsulenten, potentielle købere, boligministeriet (som fx ved stikprøver, skal sikre at der ikke svindles med "fine attester" til en "fin pris"). Nu var det ret enkelt at skrive et eller to task for hver brugergruppe. Det burde være gjort som noget af det første i projektet.

2011: Use cases versus task-beskrivelser

Use-cases var på dette tidspunkt vidt udbredt som krav, men virkede de? Var task-beskrivelser bedre? Sammen med Mohammad Kuhail undersøgte jeg det eksperimentelt. Vi fik 8 erfarne use-case brugere og 7 erfarne task-brugere til at skrive krav til samme anskaffelse: et støtte-system til en hotline der betjente ca. 1000 brugere.

Det viste sig at use-case kravene dækkede kundens behov langt dårligere end task-kravene, især på områder der var vigtige, men svære at støtte. Use-case kravene indskrænkede også løsningsrummet, sådan at det ville være sværere at finde en leverandør der gjorde som use-casen foreskrev. Se: Task descriptions versus use cases (pdf)

2012: Uvis-projektet lukker

Vi har nu et Uvis som brugere på regnearks-niveau kan bruge til at lave brugergrænseflader. Det er baseret på MS-Windows .NET, som var det mest oplagte da vi startede. Vores thoraxkirurg-medlem har selv brugt Uvis til at lave en EPJ (elektronisk patientjournal) med 22.000 mulige diagnoser (hentet fra de internationale tabeller), 13.000 slags medicin, 17.000 slags lab-tests og 17.000 andre ydelser, fx røntgenbilleder.

Vi har vist systemet til diverse IT-leverandører på sundhedsområdet, som alle siger at det ville de gerne have brugt hvis vi var i 2007, men nu skal alting være web-baseret og det er ikke ligetil at flytte Uvis dertil. Vi har offentliggjort koden og dokumentationen - for hvis nu nogen skulle have lyst til at genoptage det. Og så fik vi også 3 Ph.D.er - kirurgen havde ikke brug for nogen Ph.D. Se EPJ-skærmbillederne, Uvis toolboxen, eksempler på formler, mv.: Uvis og EHR. Desværre har ingen vist interesse for at genoptage projektet i en web-baseret udgave.

2013: Y-Fonden (pseudonym): Problemorienterede krav i praksis

To gange om året modtager og vurderer Y-Fonden ca. 300 ansøgninger, og giver bevilling til nogle af dem. Processen er indviklet og omfatter ansøgere, sekretariat, bedømmelsesudvalg, revisor, web-redaktør, udbetalinger, indberetning til Skat, og et nyt web-site. Fonden havde brug for et IT-systen til det hele og jeg blev på konsulentbasis projektleder. Jeg brugte selvfølgelig SL-07 og dens anbefalinger.

Det gik ret godt. Budgettet holdt, tvister blev løst, de forretningsmæssige mål blev nået, og brugerne var glade. Men vi blev 9 måneder forsinket. Der var flere årsager: Leverandøren havde bl.a. solgt sig på at det hele skulle være web-baseret, så det var til rådighed overalt. Det viste sig at være hype. Brugerne (fx bedømmelsesudvalget) havde PC og Apple, desuden forskellige browsere og firmaopsætninger af fx sikkerhed. Det kom aldrig til at virke fuldt ud på alle disse kombinationer, og nogle medlemmer af bedømmelsesudvalget måtte have en særlig computer til Fonds-formål. Integration til bank, økonomisystem og Skat kostede mange kræfter. Og endelig begik vi den fejl at acceptere overtagelsen og betale for leverancen, med forbehold for de sidste fejl, som kunne udbedres under vedligeholdelseskontrakten. OK, men vi overså at leverandørens motivation nu forsvandt og arbejdet gik meget langsomt. Jeg lærte rigtig meget, som jeg byggede ind i næste version af SL-07, til gavn for andre.

Du kan se hele kravspecifikationen med leverandørens svar, projektforløbet, issue-listen (fejl og ændringsønsker), og reflektioner over hvorfor vi blev forsinket og hvad vi kunne have gjort. Se: Y-Fonden.

2019: Gik på pension

Da jeg fyldte 77 besluttede jeg at gå på pension og blev emeritus. Da ITU startede var visionen at alle studerende skulle kunne det tekniske, det brugermæssige og det forretningsmæssige. Og så kunne man specialisere sig i et eller andet område. Men det var blevet til at man studerede ét af områderne, og blev orienteret i de to andre. Der var fx et studienævn for hvert af de tre områder. De to fagområder jeg plejede at undervise i, kravspecifikation og brugergrænseflade-design, var tværgående og smuldrede væk. De krævede også god kontakt med virksomheder. Reelt var der ikke andre end mig der kunne undervise i dem.

2022: User stories versus task-beskrivelser

I 2022 var use-cases ved at gå af mode. Man brugte user stories i stedet. Her er et eksempel på en user-story: Som hotline-supporter vil jeg gerne se en liste af sager der venter. Men kunne user stories bruges som krav og var de dækkende? Sammen med Mohammad Kuhail lavede jeg et tilsvarende eksperiment som i 2011 (use cases). Samme system, men nu bad vi 8 erfarne user-story brugere om at skrive krav med user stories eller hvad de ellers foretrak. Det viste sig at besvarelserne i gennemsnit kun dækkede 33% af de behov kunden havde givet udtryk for. Krav som kunden ikke havde nævnt, men som normalt er vigtige, blev ignoreret, fx brugervenlighed. Se: User Story Quality in Practice: A Case Study (pdf)

2022: Danmark skal have MitID

I Danmark havde vi i mange år brugt NemID - med nøglekort af pap - til elektronisk identifikation af personer. Det var en to-faktor-identifikation: on-line password plus et tal man aflæste på sit papkort. Desværre havde der været et par e-røverier med wire-tapping på de offentlige biblioteks-computere plus tyveri af papkortet. To af de skyldige fik 4 henholdsvis 6 års fængsel.

Man opdager at NemID kontrakten er ved at løbe ud, og fortolker EU-reglerne sådan at man skal i nyt udbud. Der annonceres et nyt projekt, MitID, som primært begrundes med at være sikrere end papkortet. MitID har også to-faktor identifikation: Computer plus Mobiltelefon eller nøglebrik. Lyder let og smart, men det bliver vanvittigt kompliceret med en masse aktører og leverandører og forskellige versioner af mobiler og browsere. Brugervenlighed udskyder man, og da man går i luften kender man en masse brugervenlighedsproblemer, men aner ikke hvad man skal gøre ved dem. Hver kommune må udvide deres borgercenter med folk der kan hjælpe. Det får omkostningerne til at galopere.


2023: Mine egne erfaringer med brugervenlighed

Set i bakspejlet, hvordan er det gået med at lave brugervenlige systemer? Her er nogle af mine observationer gennem årene:

1995: Lokalereservation på Handelshøjskolen (CBS). CBS kan ikke forstå hvorfor alle 150 undervisningslokaler altid er registreret som optaget, selvom der sjældent er nogen i dem. Morten Harning finder ud af hvorfor: Alle reservationer registreres som et lille papkort i en lomme på en kæmpe tavle med 150 lodrette rækker (en pr. undervisningslokale), hver med 40 små lommer, én pr. undervisningstime i ugen. Når nogen ringer for at reservere et lokale, ser sekretæren på tavlen efter en tom lomme. Men næsten alle lommer ser fulde ud, selvom de måske kun er reserveret i en enkelt uge. Hvordan klarer et IT-system det? Datapræsentationen er afgørende. Morten laver 6 iterationer med virtuelle vinduer og forståelsestest. Dernæst et par runder med prototyper. Han følger alle usability-specialisternes råd. Så programmerer han det selv. Systemet bliver en stor succes og bruges vist stadig.

1998? Kreditforening: Ejendomsmæglere vil gerne kunne få lånetilbud i weekenderne, hvor kreditforeningen har lukket. Kreditforeningens IT-folk har lavet en første udgave af et system der kan beregne tilbud, og hyrer nogle UX'er til at hjælpe med brugervenlighedstest. Kredit-folkene tager det meget seriøst. De skriver en kort intro man tænker at give til mæglere der skal bruge systemet. Man indkalder forsøgspersoner, sætter test-udstyr op med kameraer og med lyttepost i naborummet. Forsøgspersonerne får intro-skriftet, og prøver så. Og selvfølgelig går det galt: Mæglerne kan ikke udføre opgaverne tilfredsstillende. Så kommer ledelsen ind: Nu har vi brugt tid nok på det her. Vi sætter systemet i drift. Og det gjorde de - og tog det ud af drift efter en måned.

2001: Bruel & Kjær: Bruel & Kjær laver lydmåleudstyr til ingeniører. De vil prøve at følge UX-reglerne for et nyt, bærbart produkt, der kan vise lydintensitet, mv. på overfladen af store maskiner eller bygninger. De har en vision om at vise lyden på 3D tegninger af maskinen - ambitiøst dengang. De vil lede brugeren trin-for-trin gennem målingerne. Den første usability-test foregår med en mockup og ingeniører i USA, hvor de har et stort marked. Det går helt galt. Men i løbet af weekenden får de revideret designet, så det bl.a. ikke er trin-for-trin. De tester med nogle ingeniører mandag-tirsdag. Det ser lovende ud. Derhjemme afpudser de det, usability-tester lidt mere og så går det til programmering.

Det bliver en succes. Det er første gang et B & K produkt er blevet færdigt til tiden (dvs. til den messe hvor det skal udstilles) - tilmed uden stress. Det vækker stor opmærksomhed på messen, man sælger dobbelt så mange som man plejer af den slags, selvom man har sat prisen op til det dobbelte. Metoden spreder sig til de andre B & K afdelinger.

2001: Newstech (pseudonym): Støttesystem til nyhedsredaktører. En redaktion skal samle ideer, vælge nyheder der skal dækkes, og fordele arbejdet. Det er svært og ofte hektisk. Newstech har et ok-produkt, men vil gerne støtte kunderne bedre. Jeg hjælper dem med UX-principper til at lave et nyt produkt, og det bliver væsentligt mere brugervenligt. Et års tid efter følger jeg op: Desværre, siger min kontakt. Chefen så det nye og insisterede på at det skulle være på hans måde - ligesom den gamle version. Det blev ikke bedre.

2002: Australien - Hotelsystem (til receptionen): Jeg har i tidens løb set mange hotelsystemer og hørt om hvor svære de er at bruge. Jeg bruger et år i Australien til at designe et hotelsystem, og lære at programmere brugergrænseflader med MS-Access. Jeg laver masser af brugervenlighedstest. Jeg dokumenterer det hele i min bog User interface design - a software enginering perspective. Jeg får et godt indblik i hvad der sker bag disken i receptionen. Der er mange ting jeg ikke dækker, fx sæson-priser og firma-rabatter. Det går også op for mig at hoteller har et potentiale de ikke bruger: Receptionen kan ikke se hvilke værelser der er klargjort til nye gæster, og kan derfor ikke hjælpe fly-trætte morgengæster. De må alle vente til efter 12. Her burde være et forretningspotentiale.

På mine danske kurser i brugergrænseflade-design er der ofte receptionister. De kan bekræfte hvad jeg skriver om de eksisterende systemer og viser mig det uhyrlige system de selv bruger. (Til min overraskelse er der ingen hotelsystem-leverandører der er interesserede, men jeg forsøger heller ikke at sælge dem idéen. Jeg har travlt med andre ting).

2003: IT-Universitetet: IT-Universitetet havde et kursusevalueringssystem som var designet og udviklet af rektor, men besværligt at bruge. For at have endnu et virkeligt eksempel i min bog, prøver jeg at designe et nyt. Jeg følger slavisk den metode jeg har beskrevet. Fx beskriver jeg de "forretningsmæssige" mål med systemet, konstaterer at de ikke alle nås, og designer en løsning i det nye system. Jeg har let adgang til rigtige brugere og laver flere runder af usability test. Det hele dokumenteres i min bog. Det er også første gang jeg prøver at lave et web-baseret system, men metoden egner sig lige så godt til det, viser det sig. Nogle få af mine løsninger bliver implementeret.

2004: Mobil (pseudonym): Støttesystem til mobil-operatører. Pludselig får jeg en henvendelse fra en start-up virksomhed, der vil lave et system til at optimere antenne-placering, mv. i mobil-net. Deres ekspertice er beregning af signal-dækningen ved forskellige antenneløsninger. Deres løsning præsenterer resultaterne af beregningen i tabeller med mange oplysninger pr. antennemast. Hvad mener jeg om brugervenligheden? Jeg foreslår en løsning hvor det hele vises på et kort, hvor man kan se masterne og de enkelte antenner på hver mast, som linjer der går ud fra masten. De detaljerede data kan vises i en tabel når man klikker på masten. Jeg viser flere eksempler på hvordan det kan se ud. Alle synes det er en god idé, men der er lang vej fra idé til produkt. De vil skrive en kravspecifikation baseret på use cases og lister af funktioner der skal støttes. Jeg synes det skal være tasks så man kan se hvem der skal bruge systemet, hvornår og til hvad. Her skilles vore veje, men efter et par år, får jeg en mail fra direktøren: Det gik ikke godt. Vi skulle have lyttet til dig!

2006: Julie Krogh: Julie har som eksamensprojekt designet et støttesystem til rengøringsassistenter. Hun har brugt Virtual-Windows metoden og dokumenterer alle trin, så det illustrerer metoden. Det er også grundigt brugervenlighedstestet. Desværre får hun ikke mulighed for at gøre det til et produkt. Se PDA projektet

2008: Britt Morelli Hansen: Britt har som eksamensprojekt designet et støttesystem til barselsrefusion. Det er også meget imponerende og grundigt brugervenlighedstestet, og dokumenteret så det illustrerer Virtual-Windows metoden. 40 udviklere i det softwarehus der skulle levere systemet havde arbejdet på projektet i to år uden at designe et eneste skærmbillede. Britt's løsning er baseret på faneblade, men det værktøj udviklerne bruger (SAP) kunne på dette tidspunkt ikke vise faneblade - brugeren kan da bare scrolle ned, sagde SAP-folkene. Se Barselsrefusion

2009: Elektronisk tinglysning: Udviklingstiden var estimeret til 1,2 år, men blev 2,7 år. Systemet gik i drift september 2009. Få kunne finde ud af at bruge det, og hushandler blev svært forsinket og mange tabte penge på dyre lån. Der stod i kontrakten at der skulle laves tidlige prototyper med brugervenlighedstest. Det skete ikke. I stedet designede tinglysningsdommeren og en grafisk designer brugergrænsefladen de sidste måneder inden idriftsættelsen. Resultatet var at kun tinglysningsdommere kunne finde ud af det. Nogle af dem der havde tabt penge, sagsøgte Domstolsstyrelsen. Sagen endte i Højesteret, der frifandt Domstolsstyrelsen fordi det i 2009 ikke var almen praksis at udføre brugervenlighedstest.

2010: King Hotel system (pseudonym): Pludselig dukker der en person op der vil lave verdens bedste hotelsystem. Det skal være web-baseret, hvilket er helt nyt på det tidspunkt. Han har hørt om mig flere steder. Jeg fortæller hvad der mangler i min løsning, fx hvilke værelser der er parat, og laver en ny prototype hvor det er med. Jeg vil gerne lave usability-test med den, men han går ud til et hotel han kender og viser et par af skærmbillederne. De forstår ikke hvad de ser, rapporterer han. Til gengæld sender han mig til en dyr fotograf der i sit atelier sætter kulisser op og fotograferer mig. Så bliver der lavet brochurer om systemet med mig som illustration.

Han har også truffet aftale med et pakistansk software-hus (med repræsentation i Danmark), og de går i gang. Han inviterer en venture-kapitalist der skal finansiere det. Jeg er inviteret med til mødet. Pakistanerne sidder med en tidlig udgave af zoom (en i Pakistan og en i CPH), og snakker sammen om teknikken (på engelsk). De diskuterer tabelstrukturen for rabatter og morer sig med hvad zoom kan, og om modparten kan se hvor kassen nu er trukket hen på skærmen. Det bliver mere og mere pinligt. Investor spørger hvem af dem der ved noget om hoteldrift. Det er der ingen der gør. Jeg undskylder mig med at jeg skal til et andet møde og går. Senere får jeg at vide at investor ikke ville skyde penge i det, ikke så meget pga. det tekniske - det ville de nok finde ud af, mente han - men fordi amerikanerne var så langt forud med Web-løsninger at vi ikke kunne indhente dem.

2003-12: Det elektroniske, landsdækkende rejsekort: Udviklingstiden var estimeret til 3,5 år, men blev 7,5 år. Der var uenighed om hvem der skulle levere back-office delen (kortudstedelse, betaling og kundeservice). Kunden troede at leverandøren havde lavet back-office før, men det havde han altid overdraget til lokale folk. Kontrakten sagde at der skulle laves tidlige prototyper og brugervenlighedstest, men ikke hvem der skulle udbedre problemerne. Efter lange diskussioner endte det med at en underleverandør (Accenture) lavede hele backoffice-delen. Systemet gik i drift lidt efter lidt, uden de store problemer.

2010: Uvis: Udviklingsværktøj til brugergrænseflader. Jeg og mit team designede og udviklede Uvis systemet i C#. Der blev lavet mange brugervenlighestest og problemrettelser undervejs. Systemet kom aldrig i drift, fordi det blev overhalet af Web-teknologien, som systemet ikke umiddelbart kunne flyttes til.

2013: Y-Fonden: Støttesystem til uddeling af fondsmidler. Jeg var selv projektleder, først for back-office delen til sekretær, revisor og bedømmelsesudvalg, senere også for ansøgerdelen (fondens web-site). Brugervenlighedsproblemer i back-office-delen blev opdaget undervejs og udbedret agilt. Direktøren for fonden insisterede på at ansøgerdelen skulle være en "karussel" hvor store kulørte helsidesbilleder skiftevis kom ind på skærmen. Det var svært for brugeren at ramme der "hvor der skete noget". Jeg fik lavet brugervenlighedstest af ansøgerdelen og den viste (selvfølgelig) at brugervenligheden var meget ringe. Jeg gik til direktøren og fremlagde resultatet og forslag til hvad der skulle gøres. Direktøren fastholdt sin karussel, hvorefter jeg sagde op for den del af systemet. Den kunne jeg ikke tage ansvar for.

2022: MitID: Landsdækkende person-id til juridisk gyldige meddelelser, især mellem myndigheder og borgere. Jeg har skrevet om MitID ovenfor. Kort fortalt lavede man nogle brugervenlighedstest og fandt omkring 50 problemer. Men det er uklart hvilke situationer der blev testet og hvor meget hjælp forsøgspersonerne fik. Der var ingen realistiske forslag til hvordan man skulle udbedre problemerne.