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 />
Men först i början av november 1984 kom man igång. En särskild identitet lades upp,<br />
ett antal band (till slut blev det 16 stycken) skickades upp till IBM i Kista och användarna<br />
började, tillsammans med en person på dataavdelningen, lägga upp ett antal<br />
register med tillhörande kringrutiner. I stort sett konverterade man det gamla systemet.<br />
I början av maj 1985 var detta färdigt för demonstration för andra användare<br />
och direktion. Man hade en hel del problem under uppläggningsarbetet. Bl a hände<br />
det relativt ofta att systemet i Kista gick ner och att man fick vänta flera timmar på att<br />
det skulle komma ingång igen. Däremot var det inga problem att få in grunddata. Arbetet<br />
skedde parallellt med användarnas övriga arbete och tog därför tämligen lång<br />
tid. Bortsett från detta fungerade testinstallationen relativt bra och mottogs med entusiasm<br />
av företaget. Man har vid årsskiftet 1985/86 fattat beslut att installera ett<br />
sådant system plus ett nätverk som gör att även de enskilda divisionerna, med sina<br />
olika datasystem, kan använda databasen. Detta är som ett led i företagets decentralisering<br />
samtidigt som det möjliggör ett väl tillgängligt ekonomisystem för hela koncernen.<br />
5.7.4 Kommentarer<br />
Detta avsnitt skulle också kunna finnas i kapitel 6, men jag tycker det är mest logiskt<br />
att sätta det här, eftersom det direkt hänför sig till vad som hände på Företaget. I<br />
projektet har vi stött på några av de problem Andersson (1983) anger. Problemet med<br />
behov av mycket datakraft har vi stött på via två vägar, dels genom den stora datavolymen<br />
dels genom kostnaden att bygga ut den befintliga IBM-maskinen.<br />
Kravspecifikation<br />
I början av projektet använde vi oss också av något felaktiga systemeringsmetoder i<br />
och med att vi försökte få fram en traditionell kravspecifikation. Vi försökte använda<br />
följande metoder för att få fram kraven på den nya databasen:<br />
• Missnöjesanalys av det nuvarande systemet.<br />
• Ta reda på vad som redan finns i försystemen.<br />
• Studera verksamheten och se vilken information som behövs för densamma.<br />
• Utdataspecifikation.<br />
• Prototypanvändning.<br />
Utdataspecifikationen (dvs den traditionella metoden) förespråkades varmt av datachefen.<br />
Vid något tillfälle sa han att vi skulle ställa användarna mot väggen och<br />
tvinga fram en kravspecifikation. Siv Friis var rätt mycket för tanken att man skulle<br />
hitta någon flaskhals och börja nysta upp saker och ting därifrån, alltså en kombination<br />
av missnöjesanalys och utdataspecifikation. Själv trodde jag att verksamhetsanalys<br />
skulle vara möjlig att använda, men insåg snart att "information" och "verksamhet"<br />
förekom på minst fyra olika nivåer (fig 5.11). Att hålla isär alla dessa nivåer<br />
och de olika regler som gäller för varje nivå skulle vara alldeles omöjligt.<br />
150