Flensburg P: Personlig databehandling - Per Flensburgs hemsida

Per Flensburg: Personlig databehandling
I mina försök att begripa ekonomisystemet försökte jag med hjälp av min uppfattning
om användarnas koder bygga upp först en hierarkisk datamodell och sedan en nätverksdatamodell.
Men det visade sig hela tiden att jag missuppfattat väsentliga begrepp.
Jag saknade en dokumentation på en mer övergripande och lättbegriplig nivå.
Den jag fått av användarna var paradoxalt nog alldeles för dataorienterad för att jag
(dataexperten!) skulle förstå den. Men när jag och Företagets projektledare satt och
diskuterade dessa saker och jag klagade över att jag inte hade någon mellannivå, så
vände han sig om och tog ner en pärm från bokhyllan på vilken det stod "Kontoplan".
"Det skulle väl vara den här då!", sa han. Det var precis den översiktliga, men ändå
detaljerade beskrivning jag sökt efter hela tiden.
Kravspecifikationer i teori och praktik
Under arbetet med prototyperna fick användarna ställa "frågor" till det tänkta systemet.
Sedermera gjorde även Företagets projektledare en grov kravspecifikation. De
krav som framfördes var av typen: "Kostnadsstruktur för bränsleförbrukningen på
adv 4 i fabrik B på division A". Detta är inget krav, om man talar "allmänna dataspråket"
men i det specifika yrkesspråket på Företaget var det ett krav. Själv undrade jag
över vad "kostnadsstruktur" kunde tänkas innebära, men jag valde att inte dyka in i
det vid ifrågavarande tillfälle, eftersom det lätt hade kunnat leda arbetet långt på villovägar.
Men såvitt jag förstod var kravet snarare fråga om vad man vill göra med
informationen än vilken information man vill ha. Så småningom begrep jag att "kostnadsstruktur"
innebar någon form av uppdelning men exakt vilken vet jag inte. Denna
kunskap hör till den specifika yrkeskunskapen hos användarna på Företaget.
Dessutom vill man därefter ha ytterligare uppdelning av vissa kostnader och sedan
ytterligare uppdelning. Vilket som ska uppdelas och hur det ska uppdelas kan inte
sägas på förhand. Det ingår i den informella yrkeskunskapen, att direkt kunna "se"
att en viss siffra är "mystisk". Liknande fenomen beträffande registreringsarbete har
beskrivits av Göranzon (1983) och beträffande laboratoriearbete av Sandström
(1985). Traditionell kravspecifikation förutsätter att begreppen är välkända och väldefinierade
från början och att alla uppdelningar är kända på förhand. Att så ofta inte
är fallet kan vara en av orsakerna till att datasystem i allmänhet inte ger de förväntade
resultaten. Detta sätt att göra kravspecifikation kan kallas det verksamhetsorienterade
sättet.
Ett annat exempel är datamodellering enligt relationsdatamodellen. Ta t ex kontoklass
3, "Allmänna omkostnader". I denna kontoklass finns ett antal konton, från
30010 "Styrelse och revision" till 39690 "Skyddspatent varumärken övrigt". På vart
och ett av dessa konton finns transaktioner, vilka representerar enskilda affärshändelser
eller aggregeringar av affärshändelser. Om det är aggregeringar, kan man i
motsvarande försystem lösa upp dem i transaktioner representerande enskilda affärshändelser.
Om detta skulle representeras i en relationsdatabas, skulle det bli ungefär
följande:
153