Software Engineering, Soren Lauesen  Home


Søren Lauesen har arbejdet med programmering og Software Engineering siden 1962. Her er 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, er mine erfaringer fra de første år i branchen - og om det er bedre i dag. Skriftet står i listen nedenfor, men lad mig lokke læseren til at se det straks:
Compiler-gruppen: Teknisk perfektionisme kontra nytte (11 sider): Download (pdf)

1969: Min første lærebog og SL69
Et par år efter at jeg var blevet kandidat i matematik og fysik, opfordrede professor Thøger Busk mig til at skrive en lærebog i programmering. 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.

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, og det blev til: 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.

1997: Objekt-orientering 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. ComputerWorld var den gang et debatforum med en tænksom redaktør, så det ikke blev ren mudderkastning. Alligevel blev det en lang debat. 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.

Typisk kom systemet til at bestå af to slags objekter: data-objekter og funktions-objekter. Data-objekterne indeholdt data, men havde kun de trivielle funktioner Ceate, Read, Update, Delete (CRUD). Man havde sådan set bare indpakket den relationelle database. Funktions-objekterne indeholdt kun metoder, men ingen data. Det var bare et "gammeldags" funktionsbibliotek i ny forklædning. Det var ikke det teorien havde lovet.

Det er ganske typisk for nye metoder. De oversælges (hype) og folk kaster sig over dem i tro på miraklet. Men man forstår ikke rigtigt metoden, så det hele ender med at man gør som man plejer, men pakker det ind i de nye ord.

Jeg undersøgte i detaljer 7 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 publicerede resultatet og mine egne erfaringer:
Soren Lauesen (1998): Object-Oriented Systems in Real Life. 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.
Soren Lauesen (1998): Data bag publikationerne ovenfor

2000: Dansk IT's lille hæfte om kravspecifikation
I årene op til 1999 startede jeg mine undersøgelser af kravspecifikationer. Hvad var praksis, hvad gik godt og hvor var problemerne. Sammen med et par studerende fandt jeg løsninger på nogle af de vanskelige problemer, fx hvordan man finder balancen mellem for vage krav og for løsningsorienterede. Et af resultaterne var en engelsk lærebog i kravspecifikation, udgivet på Samfundslitteratur. 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, 75 sider, 2000. Senere blev det til en større lærebog udgivet af Pearson/Addison-Wesley, 2002. I dag er det blevet til problem-orienterede krav - SL-07, se Problemorienterede krav.

2003: Erfaringer fra en EU udbudsforretning: Hvad gik godt og hvor var problemerne? 34 sider Download (pdf)
I 2002-2003 undersøgte Jens-Peder Vium og jeg en større anskaffelsessag, hvor en kommunal forsyningsvirksomhed anskaffede et system til samlet administration af el, vand, varme, etc. Vi undersøgte kundens og de fem leverandørers opfattelse af forløbet, herunder kravspecifikationens rolle. Der var mange misforståelser parterne imellem, specielt om hvad de forretningsmæssige målsætninger var. Den internationalt publicerede version findes i Soren Lauesen & Jens-Peder Vium: Communication Gaps in a Tender Process, 17 sider. Requirements Engineering Journal (REJ), september 2005.

2005: Compiler-gruppen: Teknisk perfektionisme kontra nytte: Download (pdf)
I oktober 2005 fejrede Dansk Datahistorisk Forening 50 året for oprettelsen af Regnecentralen med udgivelsen af et festskrift. Jeg bidrog med dette indlæg om Compilergruppen. Det er en sørg-munter historie om hvad vi dengang gjorde godt og hvor vi fejlede, og om det egentlig går bedre i dag.

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

2007: Søren Lauesen: Kan SOA gå på vandet? (Indlæg i ComputerWorld): Kan SOA gå på vandet? (pdf)
I årene 2004 til 2007 hørte vi lovsangene om at hvis IT systemer blev baseret på Service-Orienteret Arkitektur (SOA) ville alt gå let og smertefrit. 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".

2009 og frem: Hvordan store IT-projekter forulykker: Damages in large IT-projects
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.

For en programmør 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.

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: SOA. Systemsammenkobling er uhyre indviklet og mærkværdigvis er der ingen der forsker i årsagerne og foreslår metoder. Men her er en begyndelse:

2017: Christoffer Pagaard: Service-orienteret arkitektur (SOA) kontra delt database
Denne rapport sammenligner IT-arkitekturen i to offentlige organisationer: SKAT og STAR (Styrelsen for Arbejdsmarked og Rekruttering, bl.a. håndtering af dagpenge ved arbejdsløshed). SKAT bruger den ideelle SOA arkitektur, hvor en vilkårlig samling IT systemer kommunikerer ved hjælp af services. Data replikeres ikke, men hvert system henter efter behov hvad det skal bruge fra andre systemer. Det kan også have brug for at opdatere data i andre systemer ("indberette data").

STAR har en central, delt database styret af STAR selv, driftet og vedligeholdt af skiftende IT-leverandører. Ca. 50 IT-systemer i det offentlige og industrien trækker på databasen med services. De kan replikere data til eget brug, men referencedata er den delte database.

Konklusionen er at den delte database har mange fordele, fx bedre svartider, tilgængelighed og generel vedligehold. Der er dog et problem når et klient-system skal bruge data fra server-systemet på en ny måde. Så skal man aftale en ny service med STAR - en punkt-til-punkt forbindelse. Det tager lang tid for begge parter og er derfor dyrt. Det kunne forbedres hvis man i stedet brugte Odata (Open Data), hvor klienten selv kan specificere en SQL-streng, som server udfører og returnerer resultatet til klienten. Erfaringer fra andre systemer viser at vedligehold bliver meget lettere med Odata. I stedet for at to parter skal aftale og teste en service, gør Odata det muligt for klienten selv at definere og teste servicen. Sikkerhed og svartider er i princippet risikable, men i praksis viser det sig ikke at være værre end den traditionelle tilgang. Det er ikke tilfældige systemer der er klienter, men software-huse der har en aftale.

En faktor som Christoffer ignorerer, er behovet for at teste integrationen. Når man tester klient-systemet, er der behov for specielle testdata i serveren. Men dette data må ikke forstyrre serverens normale arbejde. Test-problemet findes i begge arkitekturer. Når man læser rapporten, bør man vide at Christoffer er næsten blind. Hent rapporten (pdf, på dansk)