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.
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)
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.
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.
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.
1969: Søren forelæser ved datalogistudiets start.
De to første år ledte jeg samtidig på Regnecentralen en projektgruppe der udviklede fler-bruger operativsystemet Boss 2 til RC4000.
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 marts 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 vej. 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 en "database" med et hulkort pr. vej med vejens navn, længde, antal drænløb, regionsnummer, mv. Computeren læste alle kortene, printede en overskriftslinie og derunder en linje for hver region med regionens samlede tal, fx samlet antal km med asfalt og samlede omkostninger. Og nederst landstotalen.
Canadierne var glade, men jeg var skeptisk. Druknede det ikke bare i politik? Et par dage efter marts-mødet 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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)
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.
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.
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.
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)
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.
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.
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.
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.