Flensburg P: Personlig databehandling - Per Flensburgs hemsida
Flensburg P: Personlig databehandling - Per Flensburgs hemsida
Flensburg P: Personlig databehandling - Per Flensburgs hemsida
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Per</strong> <strong>Flensburg</strong>: <strong><strong>Per</strong>sonlig</strong> <strong>databehandling</strong><br />
Skissen kom dock att mera likna en prototyp, dvs ett förslag till en del av det nya systemet.<br />
Kravspecifikationsarbetet gick därmed över i arbete med prototyper. Prototypen<br />
bestod av en generell sökbild, med följande utseende (Fig 5.10):<br />
Kostnadsställe:<br />
Kostnadsslag:<br />
Belopp:<br />
Fig 5.10 Sökbild för skiss<br />
Man kunde ange namn eller delar av namn på kostnadsslag och kostnadsställe samt<br />
om beloppen skulle vara större än eller mindre än ett givet belopp. Utrymmet kunde<br />
också lämnas blankt. Det fanns ett transaktionsregister, som innehöll transaktioner<br />
med samma format som sökbilden ovan. Detta genomsöktes i sekvens och poster där<br />
träff med samtliga argument inträffade skrevs ut. Det fanns också två specialprogram<br />
som beräknade totaler för olika kostnadsslag eller kostnadsställe. Kostnadsstället var<br />
uppbyggt som en hierarkisk kod. Jag antog att det fanns tre divisioner A, B och C,<br />
samt 3 fabriker 1, 2, och 3 på varje division. Varje fabrik hade i sin tur 3 avdelningar.<br />
Om jag t ex ville ha ut alla affärsomkostnader på division B, fabrik 2, avdelning 1 så<br />
skrev jag AFFO (eller bara FF, eller eller något annat entydigt) på kostnadsslaget och<br />
B21 på kostnadsställe. Då kom önskade transaktioner på skärmen, dock utan budgetjämförelse<br />
eller summeringar. Skissen skrevs i Dbase II, som är ett databasprogram<br />
för persondatorer. Vid presentationen för projektdeltagarna gav den upphov<br />
till en livlig diskussion om hur det färdiga SOKRHATES-systemet skulle se ut.<br />
Vi enades om följande huvudmeny :<br />
1. Förutbestämda listor<br />
2. Förutbestämda frågor<br />
3. Spontana listor<br />
4. Spontana frågor<br />
5. Kataloger över befintliga frågor och listor<br />
6. Ta bort gamla eller oönskade listor eller frågor<br />
7. Rätta i register<br />
Om en fråga antingen tar lång tid att besvara eller ger ett långt svar bör det bli en lista<br />
istället. I punkterna 3 och 4 ovan kan man tänka sig en funktion som anger förväntad<br />
söktid eller förväntat antal svar. Användaren kan då få möjlighet att ångra sig. Det är<br />
vidare tänkt att man skall kunna lagra sina frågor eller begäran om listor för att kunna<br />
använda dem fler gånger. Punkten 5 är en katalog över sådana lagrade utsökningar.<br />
Användarna kan med hjälp av detta system analysera varför det gått som det gått. Det<br />
kan ibland leda till frågor till kostnadsansvariga. Dessa borde själva vara intresserade<br />
av att kunna ställa liknande frågor och i planerna ingick att systemet ska ställas till<br />
146
Change language