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