07.12.2012 Views

Flensburg P: Personlig databehandling - Per Flensburgs hemsida

Flensburg P: Personlig databehandling - Per Flensburgs hemsida

Flensburg P: Personlig databehandling - Per Flensburgs hemsida

SHOW MORE
SHOW LESS

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 />

I figur 2.14 har jag beskrivit systemutveckling som en transformationsprocess (enl<br />

Kraushaar & Shirland 1985), där systemet under sin livstid kan inta fyra möjliga tillstånd:<br />

• Kravspecifikation enligt användare<br />

• Kravspecifikation enligt systemutvecklare<br />

• Realiserat system<br />

• System i användning<br />

Misstag kan uppkomma i transformeringen mellan dessa olika tillstånd förutom att<br />

det kan vara fel från början. Speciellt stor är risken för misstag då man går över<br />

kommunikationsmuren mellan dataexpert och användare. Kommunikationen mellan<br />

dataexpert och dataanvändare sker som regel i dataexpertens yrkesspråk. Det innebär<br />

att endast fenomen som är relevanta i den miljön kan beskrivas och således medvetandegöras.<br />

Beskrivningen av det befintliga arbetet blir ofullständig. Dessutom behärskar<br />

användaren dåligt detta språk, varför missförstånd lätt uppstår. Ytterligare<br />

en källa till felaktigheter är att dataexpertens yrkesspråk i sig inte är generellt väldefinierat<br />

utan leverantörs- ja rent av datormodellbundet. Detta utnyttjas ofta som ett<br />

medel att hårdare knyta köpare av datorer till leverantörerna.<br />

Misstag av typ 1 uppkommer automatiskt efter ett tag. Organisationen förändras,<br />

världen förändras och så även användningen av datasystem. Det måste därför finnas<br />

möjlighet att göra relativt täta justeringar av kravspecifikationen för att säkerställa ett<br />

korrekt resultat från datasystemet.<br />

Felaktigheter av typ 2 är mycket vanliga och beror enligt min mening till stor del på<br />

användarens tysta yrkeskunskap, vilken inte går att förmedla explicit. Precis som<br />

man i språket ofta blir medveten om en regel först då man bryter mot den (Israel<br />

1979), men ändå inte kan formulera den explicit, vet man vad man vill ha först då<br />

man fått det. Om traditionell systemutveckling tillämpas finns råd till bara ett försök.<br />

Med hjälp av prototyper och evolutionär systemutveckling kan man i viss utsträckning<br />

ändra på dessa förhållanden och förmodligen ännu mer vid interaktiv systemutveckling.<br />

Misstag av typen 3, systemutvecklarens misstag, kan man minska på flera sätt. Ett är<br />

bättre utbildning av systemkonstruktören, ett annat är bättre systemutvecklingsmodeller.<br />

Det har gjorts lovande försök att specificera systemen genom att sätta upp ett<br />

antal "informations requirements" med tillhörande "constraints" i något beskrivningsspråk<br />

och därefter automatiskt generera det färdiga systemet. I praktiken innebär<br />

det att delar av systemeringsarbetet blir automatiserat. Eftersom beskrivningsspråket<br />

måste nära ansluta till användarens yrkesspråk medför det att användaren<br />

själv utan alltför stort besvär eller skolning själv skulle kunna göra åtminstone förändringar<br />

i systemet.<br />

Den fjärde typen av fel, att utdata tolkas felaktigt av användarna kan bero på att utdata<br />

är felaktig och då gäller något av de andra felen, eller att användaren inte kan<br />

32

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!