 |
Olika utvecklingsparadigm
Utvecklingsmetoder
En nackdel med traditionell s.k. vattenfallsmetod är att man försöker skriva en kravspecifikation därefter överlämnas detta till en person som ofta inte varit i verksamhetens kontext och som då bygger ett system som inte är det kunden förväntar sig. Bara i den här korta beskrivningen finns steg som är omöjlig att hantera:
Skriva en explicit kravspecifikation: Inom kunskapsteori pratar man ofta om implicit och explicit kunskap. Explicit är den kunskap som man har i huvudet och som man också kan uttrycka och överföra till andra (föutsett att de personer som är inblandade i kommunikationen har tillräcklig grundförståelse eller gemensam förståelsebas för att förstå och tolka det som uttrycks - "Common ground"). Implicit är kunskap som du har men som du inte kan uttrycka och förklara. Försök exempelvis att beskriva hur din metabolism fungerar. Ändå kan hjärnan kontrollera det här systemet. En enklare, men ändå nog så svår övning kan vara att beskriva hur du gör när du kör om en annan bil. Tänk även på hur svårt det är för en nybörjare att utföra precis det någon annan förklarar.
Förstå information (eller egentligen data) i ett annat kontext: Om man inte har en gemensam förståelsebas (common ground) är det svårt att förstå något som någon annan har skrivit. Exempelvis kan samma ord betyda olika saker i olika domäner/branscher.
En slutsats är att det är väldigt svårt att skriva tillräckligt bra kravspecifikationer - i alla fall avseende lite mer komplexa system.
En bättre ansats är ofta att jobba med utvecklings- eller design-metoder som brukar benämnas som evolutionära metoder där det finns metoder så som prototyping och SCRUM.
Utvecklingsparadigm
Med utvecklingsparadigm menar man att man genom åren har haft olika tankemönster, att man har tänkt på olika sätt, avseende systemutveckling. Dessa kan exemplifieras på följande sätt:
Konstruktion
Experterna hade all makt. Man ansåg att användare inte kunde bidra till utveckling av informationsystem (IS).
Detta föll primärt på att man måste ha verksamhetskunskap och förstå användarnas behov.
Evolution (participatory design)
All makt åt användarna. De ska skriva kravspecifikationer och programmerarna ska bara göra det som är tillsagt.
Man lärde sig även här att det inte funkar bra. Komplexa IS (informationssystem) är så svåra att det inte går att skriva ner och lämna över till någon annan.
(jämför med implicit respektive explicit kunskap - hade det gått så skulle du kunna skriva ner hur man konstruerar ett munstycke för en rymdraket och sedan lämna över det till en nyanställd som då hade klarat jobbet lika bra.)
Intervention
En symbios av ovanstående: Användarna får göra sin röst hörd, men samtidigt får experten göra som han tror blir bäst. I komplexa system förstår inte alltid användarna ens vad det är för information som hanteras, hur den hänger ihop etc. Man har ofta ingen konsistent begreppskarta vilket är kärnan i IS-design. Samtidigt har heller experten kanske inte kunskap om det företagsspecifika arbetssättet, kulturen, beslutsprocesserna etc.
|
