Flensburg P: Personlig databehandling - Per Flensburgs hemsida
Flensburg P: Personlig databehandling - Per Flensburgs hemsida
Flensburg P: Personlig databehandling - Per Flensburgs hemsida
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Per</strong> <strong>Flensburg</strong>: <strong><strong>Per</strong>sonlig</strong> <strong>databehandling</strong><br />
jag en gång följande mycket belysande yttrande: "Varför ge en människa chans att<br />
göra fel, när en dator kan göra rätt?" Greenbaum (1976) har gjort en historisk analys<br />
av arbetsdelningen inom datayrken.<br />
Sammanfattningsvis kan man säga att SIS/RAS anser verkligheten vara objektiv och<br />
neutral, möjlig att dela upp i av varandra beroende delar samt möjlig att beskriva på<br />
ett enhetligt och objektivt sätt i expertspråk. Detta förutsätter att kunskapen även den<br />
är objektiv och neutral. Man anlägger ett harmoniperspektiv, där motsättningar bara<br />
beror på bristande information. Organisationen ses som ett styrt system och människan<br />
ses som en mekanism för att utföra specialiserade arbetsuppgifter. Detta är med<br />
andra ord ett klassiskt, tayloristiskt perspektiv.<br />
Till saken hör att systemutvecklingsmodeller i praktiken sällan används på avsett vis.<br />
Motiveringen är att den inte går att anpassa till det just då aktuella projektet (<strong>Flensburg</strong><br />
& Sandström, 1980). Men ändå anses de viktiga och det forskas mycket på dem<br />
(Revay 1977, Brandt et al 1978, Brandt & Johansson 1980). Liknande analyser av<br />
andra systemutvecklingsmodeller och med ungefär samma resultat har även gjorts av<br />
t ex Olerup (1982, 1985), Swanson (1976) och Wood-Harper & Fitzgerald (1982).<br />
2.3.3 Övriga ansatser<br />
Det har under senare år lanserats ett antal alternativa sätt att utveckla system. Prototyping<br />
och evolutionär systemutveckling är sådana alternativ. Idén med prototyper<br />
är att göra en i vissa avseenden förenklad eller ofullständig konstruktion, avsedd<br />
att testas av de blivande användarna. På så sätt får användarna direkt se systemerarens<br />
tolkning av deras önskemål. För systemeraren blir prototypen en fungerande<br />
kravspecifikation, vilket undanröjer många missförstånd. Enligt Jenkins (1985) bygger<br />
prototyping på ett enda enkelt antagande, nämligen att det är lätt för en användare<br />
att tala om vad som är dåligt i ett existerande dataeller informationssystem, men<br />
mycket svårt att säga hur det ska vara istället. Kraushaar & Shirland (1985 ) anger<br />
dock behov av ökad systemutvecklingskapacitet som ett av huvudskälen till att införa<br />
prototyping.<br />
Det finns likheter, men också väsentliga skillnader, jämfört med prototyper i industriell<br />
design. Jenkins (1985, sid 2) pekar på en del skillnader (tab 2.1) vilka enligt min<br />
mening inte är principiella. Grundidén är densamma: nämligen att göra utvärdering<br />
och mätningar innan en massa pengar investeras i en färdig produkt eller produktionsenhet.<br />
Men i genomförandet påminner dock Jenkins om traditionell Systems<br />
Life Cycle. Användaren kallas dock user/designer och dataexperten kallas systems/<br />
builder. Denna terminologi visar på en mera realistisk rollfördelning, men har tilllämpats<br />
i traditionell systemutveckling sedan lång tid tillbaka. Det finns även andra<br />
metoder föreslagna (Kraushaar & Shirland 1985, Berrisford & Wetherbe 1983).<br />
28
Change language