ISRN-nr: LIU-IEI-FIL-G--08/00263--SE
Prototyper i systemutveckling
Agila och traditionella angreppssätt
Prototyping in Systems Development
Agile and Traditional approaches
Anders Nawroth
Höstterminen 2008
Handledare: Tommy Wedlund
Systemvetenskapliga programmet
Linköpings universitet
Institutionen för ekonomisk och
industriell utveckling (IEI)
kandIdatUppsats
Anders Nawroth
andna041@student.liu.se
Handledare: Tommy Wedlund
Prototyper
i systemutveckling
Tack
Ett varmt tack riktas till samtliga intervjupersoner för att de tog sig tid att medverka i denna studie.
Tack till Tommy Wedlund för återkoppling och stöd och till Hans Holmgren för litteraturtips och idéutbyte.
Sammanfattning
Syftet med studien är att undersöka prototyper i samband med sys-temutveckling, och då särskilt om agila utvecklingsmetoder har på-verkat hur prototypning används.
En genomgång av begreppet prototyp och närliggande begrepp görs för att klargöra vad som kan avses med prototyper inom system-utveckling. En översikt över olika synsätt på prototyper och deras användning presenteras, och leder vidare till en teoretisk modell för prototyper i systemutveckling.
Systemutvecklare och experter intervjuas för att bringa klarhet i begreppen och ta reda på hur prototyper används i systemutveck-lingsprojekt i praktiken. Utifrån detta material presenteras en vida-reutveckling av den första teoretiska modellen. Problemrymd och lösningsrymd hör till modellens centrala begrepp.
Studien visar att agila utvecklingsmetoder påverkar arbetet med pro-totyper i riktning mot att utföra prototypning i det ordinarie utveck-lingsspåret samt att hämta in regelbunden återkoppling på prototy-per från användare och andra intressenter under hela systemutveck-lingsprojektets gång. Sådana arbetssätt visade sig också förekomma inom den praktiska systemutvecklingen.
Innehåll
1 Inledning . . . 1 1.1 Bakgrund. . . 1 1.2 Syfte . . . 1 1.3 Intresseområde . . . 2 1.4 Frågeställningar. . . 2 1.5 Avgränsning . . . 2 1.6 Målgrupp . . . 3 1.7 Referenshantering . . . 4 1.8 Disposition . . . 4 2 Metod. . . 5 2.1 Inledande anmärkning . . . 5 2.2 Förförståelse . . . 5 2.3 Kunskapsläge. . . 6 2.4 Kunskapsbehov . . . 7 2.4.1 Kunskapskarakterisering . . . 7 2.5 Kunskapsstrategi . . . 8 2.6 Metodval. . . 82.7 Reliabilitet och validitet . . . 9
2.8 Metodkritik. . . 9
3 Teori . . . .11
3.1 Begrepp. . . .11
3.1.1 Prototyp. . . .11
3.1.2 Systemutveckling. . . .13
3.1.3 Design och designer. . . .13
3.1.4 Programmering . . . 14
3.1.5 Problemlösning . . . 14
3.2 Prototyper och prototypning. . . 16
3.2.1 Användningssätt . . . .17
3.2.2 «Slit och släng» kontra evolutionär prototypning . . . . .17
3.2.3 Presentationsprototyper: lo-fi och hi-fi . . . 19
3.2.4 Horisontella och vertikala prototyper . . . 19
3.2.5 Utforskande och experimentella prototyper. . . 20
3.3 Systemutvecklingsmodeller . . . 22 3.3.1 Vattenfallsmodellen . . . 22 3.3.2 Agil utveckling. . . 23 3.3.3 Användarcentrerad systemdesign. . . 24 3.4 Att förstå systemutveckling. . . 25 3.4.1 Peter Naur . . . 25 3.4.2 Pelle Ehn . . . 28
3.5 Systemutveckling och prototyper . . . 29
3.5.1 Prototypning i verksamhetsutveckling. . . 29
3.5.2 Agila prototyper. . . 30
3.5.3 Prototypernas roll . . . .31
3.6 En sammanfattande modell . . . 32
3.6.1 Motivering av modellen. . . 32
3.6.2 Preliminär begreppsmodell för prototypning. . . 32
4 Empiri . . . 37
4.1 Upplägg för intervjuerna . . . 37
4.1.1 Preliminär teoretisk modell . . . 37
4.1.2 Intervjuernas ställning i uppsatsen. . . 37
4.1.3 Urval av intervjupersoner. . . 37
4.1.4 Praktiskt genomförande. . . 37
4.1.5 Återgivningen av intervjuerna . . . 38
4.2 Intervjuer. . . 39
4.2.1 Intervju med Lars Degerstedt . . . 39
4.2.2 Intervju med Arne Jönsson . . . 47
4.2.3 Intervju med T. Nilsson och A. Larsson. . . 50
4.2.4 Intervju med Mårten Herberthson . . . 59
4.2.5 Intervju med Tomas Volavka . . . 65
4.2.6 Intervju med Bo Olls. . . 69
4.2.7 Intervju med Karl-Göran Andersson . . . 75
4.2.8 Intervju med Michael Garrido. . . 82
4.2.9 Intervju med Peter Grew . . . 88
4.3 Sammanfattning av empiri . . . 91
4.3.1 Sammanfattning av intervjuer inriktade på teori . . . 91
4.3.2 Sammanfattning av intervjuer inriktade på praktisk systemutveckling. . . 93
4.3.3 Sammanfattning av intervju kring konstprojekt i
offentliga miljöer . . . 97
5 Analys och diskussion. . . 99
5.1 Prototypbegreppet och systemutvecklingsprocessen . . . 99
5.1.1 Begreppet prototyp i teori och praktik. . . 99
5.1.2 Vidareutveckling av den teoretiska modellen. . . 99
5.2 Agil och traditionell systemutveckling . . . .103
5.3 Prototyper och systemutveckling i praktiken. . . .105
5.3.1 Resultat . . . 106
5.3.2 Gränsdragningar . . . .107
5.4 Råd för användning av prototyper i systemutveckling. . . . .107
5.5 Konstprojekt jämfört med systemutveckling. . . 108
6 Slutsats . . . 111
7 Avslutning . . . 115
8 Begreppslista. . . 117
9 Källor . . . .119
Tabeller
Tabell 1: Kunskapsbehov och kunskapskaraktär . . . 7 Tabell 2: Ram för systemutvecklingsprojekt . . . 32 Tabell 3: Skillnader mellan agil och traditionell
systemutveckling. . . .105 Tabell 4: Sammanställning av resultat. . . 106
Figurer och bilder
Figur 1. Avgränsning av vad denna uppsats behandlar. . . 3 Figur 2. Förhållandet mellan prototyp och utvecklare. (Schneider
1996, s. 523) . . . 16 Figur 3. En utvecklingsmodell för prototypning.
(Andersen 1994, s. 412) . . . 18 Figur 4. Tre olika slags prototyper: vertikal, horisontell eller i form
av ett scenario.
(Figur efter Gulliksen & Göransson 2002, s. 245) . . . 20 Figur 5. Tre olika dimensioner för prototyper: roll, utseende och
be-teende samt implementation.
(Figur efter Houde & Hill 1997, s. 6). . . .21 Figur 6. Livscykelmodellen. (Figur efter Andersen 1994, s. 48) . . . 23 Figur 7. Grundelementen i en iterativ användarcentrerad process.
(Figur efter Gulliksen & Göransson 2002, s. 109). . . 25 Figur 8. Relationen mellan systemutveckling och utvecklingen av
verksamhetsprocesser i verkliga livet. (Figur efter Gulliksen & Göransson 2002, s. 299) . . . 29 Figur 9. Prototypning under hela verksamhetsutvecklingen för att
tidigare kunna ta fram krav som är begripliga för användaren. (Figur efter Gulliksen & Göransson 2002, s. 300) . . . 29 Figur 10. Tidig och kontinuerlig prototypning får produkten att
«växa» till. (Figur efter Gulliksen & Göransson 2002, s. 301) . . 30 Figur 11. Utkast till modell för prototyper i systemutveckling. . . . 33 Figur 12. Preliminär modell för prototyper i systemutveckling.. . . 34 Figur 13. Den andra iterationen av begreppsmodellen. . . 36 Figur 14. Den ursprungliga versionen av begreppsmodellen
inklu-sive anteckningar under intervjun med Lars Degerstedt. . . 46 Figur 15. Den tredje iterationen av den teoretiska modellen.. . . . 100 Där inget annat anges rör det sig om egna figurer. Tillstånd att an-vända fotografier har inhämtats i förekommande fall.
Figur 16. Den teoretiska modellen kompletterad med tre slags prototyper utifrån Houde & Hill (1997).. . . .101 Figur 17. Den teoretiska modellen med exempel på olika slags
prototyper.. . . 102 Figur 18. Den teoretiska modellen med tendenserna till dokument
respektive aktivitet tillagda.. . . 104 Figur 19. Den teoretiska modellen så långt den utvecklats i
studien. . . 112 Bild 1. «Dubbelgångare» av konstnären Kent Karlsson.
Foto: Bo Olls. . . 72 Bild 2. «Dubbelgångare» av konstnären Kent Karlsson.
1
Inledning
Detta kapitel beskriver uppsatsens bakgrund, syfte och frågeställ-ningar.
1.1
Bakgrund
Under 1980-talet var prototypning ett område som drog mycket in-tresse till sig, och även framfördes som en övergripande modell för utveckling av mjukvara (se Bischofberger & Pomberger 1992). Sedan dess har mycket hänt, bland annat har agila utvecklingsmetoder börjat göra sig allt mer gällande (se Wiktorin 2003). Frågan uppstår hur detta påverkat prototypning.
Från att datorer en gång var något som endast specialister använde, gick utvecklingen i den riktningen att allt fler kom i direktkontakt med dem. Till exempel innebar introduktionen av IBM pC 1981 ett viktigt steg (se Encyclopædia Britannica 2007) som stärkte utveck-lingen i denna riktning.
Denna utveckling förde med sig ett intresse för hur gränssnitt för människa-datorinteraktion kunde tas fram på ett bättre sätt. Ett sätt att angripa detta område är att använda prototyper för användar-gränssnitt.
Det handlar också om vilka tekniska möjligheter som står till för-fogande. Jag har själv varit med om webbens utveckling från primi-tiva möjligheter att utforma gränssnitt till dagens stora möjligheter. Som medlem i Web Standards Group vet jag också att prototyper för webbplatser och webbapplikationer är något som diskuteras livligt inom branschen.
Närliggande områden är användarmedverkan och användbarhet, där prototyper spelar en viktig roll.
Förarbetet till uppsatsen har utförts med stöd av kunskapsprojekte-ring enligt Goldkuhls Kunskapande (1998).
1.2 Syfte
Syftet med denna studie är att bidra till en ökad förståelse av proto-typer och prototypning. Särskild vikt läggs vid prototypning sedd i
kontexten av systemutvecklingsprojekt, och hur prototypning even-tuellt påverkats genom agila metoder.
1.3 Intresseområde
Något jag är nyfiken på är hur man kan arbeta med prototyper på olika sätt i systemutveckling. Vilka perspektiv på prototyper finns det, och vad får de för konsekvenser i praktiken? Vad finns det för möjligheter och problem när man arbetar med prototyper utifrån olika angreppssätt?
På senare år har något som kallas för lättviktsmetoder («Agile meth-odologies», se Wiktorin 2003) stigit fram som ett alternativ till mer traditionella sätt att arbeta med systemutveckling. Här undrar jag hur detta påverkat synen på prototyper. Innebär lättviktsmetoder ett annat sätt att tänka om och använda prototyper? Och hur ser det ut hos företag som sysslar med systemutveckling? Har man anammat dessa nya synsätt, eller arbetar man efter de traditionella metoderna på området?
1.4 Frågeställningar
Vad innebär begreppet prototyp inom systemutveckling?
Hur kan man relatera prototyper till systemutvecklingsproces-
sen?
Skiljer sig synen på dessa frågor mellan traditonella och agila
angreppssätt?
Hur ser användningen av prototyper ut inom systemutveckling
idag, har agila metoder fått ett genomslag där?
1.5 Avgränsning
I samband med en prototyp finns det systemutvecklare som på något sätt har med prototypen att göra. De kan utveckla prototypen med hjälp av olika verktyg, samt följa en utvecklingsmodell i sitt utveck-lingsarbete i stort. Detta utgör en sida av prototypens omgivning. Ofta finns en annan sida, med användare, beställare och övriga in-tressenter. Se figur 1 för en bild av detta, samt den avgränsning som gjorts i denna uppsats.
Denna studie begränsar sig till att se på prototyper ur systemutveck-larens perspektiv. Att även bearbeta användarperspektivet utförligt
skulle ge en större bredd, men samtidigt ge ett minskat djup, och har därför valts bort.
Jag kommer inte heller att gå in på andra intressenters upplevelser och erfarenheter av prototyper. Där finns till exempel personer med en beställarroll och andra leverantörer som man samarbetar med. Yt-terligare ett område som lämnas utanför studien är det verktygsstöd för att tillverka prototyper som finns.
1.6 Målgrupp
Målgruppen för detta arbete är personer med intresse för hur system-utveckling kan bedrivas på ett klokt sätt med stöd av prototyper och prototypning. De kan till exempel vara studenter i systemvetenskap eller blivande ingenjörer. Även personer som bidragit med kunskap och erfarenhet till studien kan ha intresse av att se sitt bidrag i det sammanhang som denna studie utgör.
Kunskapen i studien baseras på publicerade forskningsresultat samt intervjuer med experter och praktiskt verksamma systemutvecklare.
systemutvecklare
prototyp
utvecklingsmodell
användare verktyg
beställare övriga intressenter
1.7 Referenshantering
Referenshanteringen följer i stort sett den «Guide till Harvardsyste-met» som tillhandahålls av Högskolan i Borås (2007).
För att underlätta när det finns flera referenser till resurser på en och samma webbplats har dessa grupperats i en lista i källförteckningen. Muntliga källor anges inom parentes direkt i texten istället för i fot-noter.
1.8 Disposition
Uppsatsen är indelad i delar som följer på varandra i en logisk ord-ning: Inledning Metod Teori Empiri
Analys och diskussion
Slutsats
Avslutning
I slutet av teorikapitlet finns en teoretisk modell som sedan används som en preliminär utgångspunkt i genomförandet av empirin. Empi-rikapitlet innehåller utdrag ur de intervjuer som har genomförts, och avslutas med en sammanfattning av varje intervju.
Studiens till stor del explorativa karaktär har lett till att intervjuma-terialet är mångfasetterat och rikligt. För att kunna göra maintervjuma-terialet rättvisa har relativt omfattande utdrag tagits med i rapporten. Man kan nöja sig med att läsa sammanfattningarna, men för den som vill ta del av en rikare bild finns utdragen direkt tillgängliga i rapporten. Före källförteckningen finns det en lista med några förklarade be-grepp som läsaren kan ha nytta av.
Samtliga källor finns med i en sammanhållen källförteckning. Utvalda länkar till webbplatser av relevans för studien finns sist i rapporten.
2
Metod
Detta kapitel presenterar förförståelse, kunskapsbehov och de me-todval som gjorts. Syftet är att man ska kunna förstå tanken med studiens upplägg.
2.1 Inledande anmärkning
Uppsatsens metod har tagits fram med stöd i kunskapsprojektering som beskrivs av Goldkuhl (1998) i hans Kunskapande. Läsaren hän-visas till denna skrift när det gäller bakgrund till detta kapitel och de begrepp som används här. (Se även länktips, kapitel 10.)
2.2 Förförståelse
Mina egna erfarenheter av prototypning kommer från webbområdet. Det har rört sig om snabba skisser på papper i en inledande fas samt att arbeta med en fungerande webbplats och förfina den tills kunden är nöjd. Det senare kan man välja att se som en körbar prototyp. Jag har även erfarenhet från olika kurser i det systemvetenskapliga programmet, där främst det stora systemutvecklingsprojektet under det första året samt kursen i handlingsbarhet under det tredje året innebar arbete med prototyper.
Ett problem när man ger sig in i detta fält är vilka begrepp man ska arbeta med. Man kan tala om både prototyp som substantiv och pro-totypning som verb, och även mena olika saker med dessa begrepp. Mitt perspektiv blir här att inte lägga fast en «kanonisk» innebörd i begreppen, utan istället bearbeta dem tillsammans med olika perso-ner för att snarare utforska begreppen och deras möjliga innebörder. Den bild av området som jag har med mig in i arbetet har två sidor. Prototyper framställs å ena sidan som en lösning på viktiga problem i systemutveckling, särskilt kommunikationen med slutanvändare och andra intressenter. Å andra sidan hävdar somliga att arbetssättet är förenat med stora problem, till exempel risk för missförstånd av olika slag. I en sådan situation blir det uppenbart hur viktigt det är med kunskap om området för att kunna dra nytta av fördelarna utan att råka ut för de fallgropar som existerar.
Man kan även betrakta prototyper som sådana, men jag har valt att se dem i samband med systemutveckling.
Till grund för mina resonemang och mina metodval ligger synsättet att systemutveckling handlar om att arbeta med och hantera begrepp på olika nivåer. Dessa begrepp hämtas till exempel från it-systemets verksamhetskontext, från programutvecklingsmiljöns och program-meringsspråkens symboler samt systemutvecklingsmetodernas olika begrepp.
2.3 Kunskapsläge
Den källa som kommer allra närmast området för min undersökning är boken Användarcentrerad systemdesign (Gulliksen & Göransson 2002). I den finns det material som jag kan bygga vidare på; inte minst ger den en god överblick över området.
Boken Systemutveckling (Andersen 1994) har ett kapitel om proto-typning som innehåller värdefull kunskap. Bland annat tar den upp begreppet prototypning i samband med experimentell systemutveck-ling.
I sin bok The Object Primer (2004) lägger författaren Scott W. Am-bler fram en lättviktsmetod för objektorienterad systemutveckling. Den har även några intressanta sidor om prototypning av användar-gränssnitt.
Artikeln What do Prototypes Prototype? (Houde & Hill 1997) visar på ett sätt att kategorisera prototyper utifrån vilka aspekter av ett sys-tem eller en produkt som står i förgrunden.
En magisteruppsats med titeln Tillämpning av prototyper i Rational
Unified Process undersöker hur prototyper och RUp fungerar
tillsam-mans (Leventis & Tomazic 2001). Den empiriska delen undersökte ett webbprojekt och slutsatsen blev att prototyputveckling inte på-verkas av RUp, men att RUp använder prototyper som ett stöd i sys-temutvecklingsarbetet.
Något vetenskapligt arbete kring prototyper i samband med agila utvecklingsmetoder har jag inte kunnat hitta. Därmed finns det en kunskapsmässig lucka att fylla på detta område.
2.4 Kunskapsbehov
Hur relaterar viktiga begrepp som hör samman med prototyputveck-ling tillvarandra? Exempel på sådana begrepp är it-system, systemut-veckling, prototyp, prototypning, användare, designer och utvecklare. Jag saknar en mer övergripande bild av detta, och vill göra ett försök att ta fram en sådan bild.
Hur förhåller sig denna bild i sin tur till traditionella respektive lätt-viktsperspektiv på systemutveckling? Detta är en annan fråga som jag vill utforska.
Var står man idag inom praktisk systemutveckling när man arbetar med prototyper? Vilka begrepp står i centrum, och hur tänker man kring prototypning?
Målet med att utforska ovanstående är att kunna ge en hjälp till bätt-re förståelse av arbete med prototyper i systemutveckling, och i viss mån systemutveckling över huvud taget, eftersom centrala begrepp bearbetas.
2.4.1 Kunskapskarakterisering
Tabell 1: Kunskapsbehov och kunskapskaraktär
Kunskapsbehov Kunskapskaraktär
Relation mellan begrepp Kategoriell och klassificerande kun-skap
Systemutvecklingsperspektiv Kategoriell och klassificerande kun-skap
Dagens systemutveckling Deskriptiv kunskap, förståelseinrik-tad kunskap
Framtidens systemutveckling Normativ kunskap
Studien har en tonvikt på att klargöra begreppen inom det studerade området, och att studera olika möjliga sätt som dessa begrepp kan relatera till varandra. Detta arbete förväntas leda fram till en struk-turering av begreppens relationer så att en klassificering i kategorier blir möjlig utifrån olika dimensioner. Detta i sin tur ger möjlighet att beskriva och skapa förståelse för de studerade fenomenen.
Den normativa kunskap som studien syftar till handlar om hur pro-totyper och prototypning passar in i olika situationer under system-utveckling.
2.5 Kunskapsstrategi
När det gäller begrepp och systemutvecklingsperspektiv är denna studie i första hand begreppsutvecklande och klassificerande. I un-dersökningen av systemutveckling i praktiken är den grundläggande kunskapsstrategin explorativ, med inslag av en komparativ strategi. De data som behandlas kommer i princip genomgående att vara av kvalitativ karaktär. Stor vikt läggs vid att utveckla förståelse, detta är särskilt viktigt då området är relativt okänt för mig, särskilt avseende den teoretiska och begreppsmässiga sidan.
2.6 Metodval
Studiens inriktning med framträdande explorativa inslag gör att nyansrikedom och djup i data är viktiga. Därför faller valet på att genomföra ett antal semistandardiserade intervjuer med mycket låg grad av standardisering. Den standardisering som förekommer är att utgångspunkten för intervjuerna är ett antal begrepp, samt frågan hur dessa begrepp kan relateras till varandra (se även nedan). I övrigt genomförs intervjuerna på ett fritt sätt med tonvikt på dialogutveck-lande frågor. (Se Lundahl & Skärvad 1999.)
Till att börja med genomförs intervjuer med experter med relevant kompetens för frågeställningarna. Data från denna del av studien bearbetas sedan för att kunna användas i dels intervjuer med verk-samma systemutvecklare, dels för att ge hållpunkter för analysen. Dessa intervjuer inriktas mer direkt på de begrepp jag kommit fram till att bearbeta, då jag särskilt är ute efter att få respons på dessa. I studiens andra fas genomförs intervjuer med praktiskt verksamma systemutvecklare. Intervjupersonerna väljs bland systemutvecklare som är verksamma inom olika typer av företag. De begrepp som jag särskilt valt att bearbeta kommer i dessa intervjuer att spela en min-dre roll, så att det praktiska arbetssättet med prototyper kan stå mer i förgrunden, liksom de begrepp som intervjupersonerna själva väljer att använda.
Utöver intervjuer med personer inom it-sektorn görs även en intervju med en konstnär som har stor erfarenhet av offentlig utsmyckning i form av till exempel statyer på allmän plats. Detta för att undersöka processerna i samband med offentlig utsmyckning, och se om erfa-renheter från detta område kan ge ytterligare infallsvinklar på temat prototyper i systemutveckling.
Se kapitel 4.1.4 för mer information om det praktiska genomförandet.
2.7 Reliabilitet och validitet
En nackdel med att utföra undersökningen med hjälp av ett fåtal intervjuer är att man riskerar att tillfälligheter får en avgörande bety-delse för utfallet, det vill säga en låg reliabilitet. Detta ska dock sättas i relation till undersökningens syfte. Det material som föreligger i studien lämpar sig inte för att uttala sig om frågor som hur stor andel av systemutvecklingsprojekt som använder agila arbetssätt i proto-typning. Däremot ger upplägget goda förutsättningar att uttala sig om några förekommande arbetssätt. (Se Lundahl & Skärvad 1999.) En relativt fri intervjuform som insamlingsmetod innebär att inter-vjupersonerna kan ställa frågor tillbaka till intervjuaren vid oklar-heter, och intervjuaren kan i sin tur ställa följdfrågor som klargör vad intervjupersonen avser med ett svar. Att ha ett längre samtal ger också möjlighet att lära känna intervjupersonen och skapa en samsyn kring de begrepp man använder i intervjusituationen. (Jämför Lun-dahl & Skärvad 1999.)
2.8 Metodkritik
Att låta studiens frågor växa fram och preciseras genom och under insamlingen av empirin är problematiskt med avseende på att kunna formulera tydliga hypoteser tidigt i projektet och därmed få möjlig-het att pröva dem. Inriktningen blir mer problemformulerande och orienterande, vilket passar väl för att ta fram en undersökningsplan inför en hypotesprövande studie. (Se Lundahl & Skärvad 1999.) En svårighet med studiens upplägg är risken att intervjuaren styr för mycket och hindrar intervjupersonerna att verkligen uttrycka sina tankar. Detta gäller såväl intervjusituationen som den efterföljande tolkningen.
För att i någon mån kunna möta de svårigheter som nämns ovan har ett brett urval av litteratur inom området studerats, och referenserna till andras tankar om prototyper är många.
En ytterligare svårighet är urvalet av intervjupersoner. Målsättning-en var här att få Målsättning-en bred bild av prototypbegreppet som det används i praktiska verksamheter inom området systemutveckling. Ett större antal intervjupersoner skulle kunna ha bidragit till en mer välför-ankrad bild. Samtidigt kan ett för stort antal intervjupersoner vara ett slöseri med resurser, då ytterligare intervjupersoner i allt högre utsträckning kommer att upprepa sådant som redan kommit fram. Man talar i detta sammanhang om en «mättnad» som ska inträda hos forskaren, när tillräckligt med information samlats in. Ett stort intervjumaterial riskerar även att bli allt för ohanterligt, och därmed vara till skada för en djupare analys. (Se Repstad 1999.)
3
Teori
För att skapa en förståelse av prototypers användning i systemut-veckling behövs det en översikt över olika användningsmöjligheter och synsätt, vilket detta kapitel syftar till att ge. Oklar användning av begrepp är en särskild svårighet inom området, varför detta tas upp i kapitlets början. Dessutom tas problemlösning och systemut-veckling upp för att ställa in prototyperna i ett tydligare teoretiskt sammanhang. Delar av kapitlet finns med för att ge en mer komplett bild av prototypområdet, och kommer inte att användas i analysen.
3.1 Begrepp
3.1.1 Prototyp
Det finns ett antal uppfattningar om vad en prototyp är för något inom systemutveckling. Jag ska till att börja med presentera några av dessa för att ge en bild av området.
Till att börja med har vi Nationalencyklopedins definition: prototy´p (av senlat. proto´typos ‹ursprunglig›, av li-kabetydande grek. prato´typos), originalmodell, som följande former baseras på. Inom industriell produkt-utveckling avses försöksmodell som är riktig i funktion, konstruktion och utseende men inte i tillverkningsme-tod. (Nationalencyklopedin 2007)
Att se prototypen som en originalmodell som följande former baseras på är ett möjligt synsätt även inom systemutveckling. När det gäller försöksmodellen skulle man inom systemutveckling snarare använda samma tillverkningsmetod som för den slutgiltiga produkten.
En mycket bred definition finner vi hos Houde och Hill: We define prototype as any representation of a design idea, regardless of medium. This includes a preexisting object when used to answer a design question. (Houde & Hill 1997, s. 3)
Författarna pekar på ett viktigt faktum, nämligen att man skapar en prototyp för att få svar på en fråga, en «design question», där «de-sign» ska tolkas i vid bemärkelse och omfatta såväl formgivning som
konstruktion. Att ha en så pass bred definition av prototypbegreppet kan dock bidra till missförstånd. Computer Swedens reporter An-ders Lotsson skrev följande i en krönika:
En prototyp är en fungerande provisorisk version av en produkt. Den kan vara ful som stryk, den kan ha ett rått-bo av sladdar baktill, den kan krångla var femte minut, men den ska vara gjord för att fungera. Prototyper byggs för teknisk testning, användartestning och demonstra-tion. På mässor och pressvisningar får man ofta se mo-deller av kommande produkter. De är snygga och pryd-liga, men de fungerar inte. Sådana attrapper kallas ibland för prototyper, men det är fel ord. På engelska kallas de för dummies eller mock-ups, men man kan lika gärna använda de svenska orden attrapp och modell. (Anders Lotsson 2001)
Genom att använda orden attrapp och modell för respektive före-teelse kan ordet prototyp reserveras för sådant som byggts för att fungera. Enligt Lotsson (personlig kommunikation 2007-04-12) får man dock vara försiktig med ordet modell; en modell kan vara såväl fungerande (modelljärnväg) som icke-fungerande (principskiss). Gulliksen och Göransson (2002) ansluter sig till att prototyper ska vara något som fungerar, och går till och med ett steg längre när de säger följande:
I brist på bättre ord eller standarder använder vi i denna bok begreppet prototyp som beteckning på ett system innan det är helt färdigutvecklat och prototyping som benämning på en teknik att ta fram prototyperna. (Gul-liksen & Göransson 2002, s. 242)
Med en bakgrund inom mjukvaruutvecklingsprojekt har några fors-kare kommit fram till följande beskrivning av vad prototypning är:
Prototyping is an approach based on an evolutionary
view of software development, affecting the development
process as a whole.
Prototyping involves producing early working versions (“prototypes”) of the future application system and ex-perimenting with them. (Lichter et al. 2004, s. 222)
3.1.2 Systemutveckling
I Nationalencyklopedin beskriver Nilsson (2007) inledningsvis sys-temutveckling med följande ord:
systemutveckling, aktivitet i vilken man systematiskt utreder förutsättningarna för att genom ett datorstött informationssystem (IS) förbättra verksamheten i ett fö-retag eller en organisation samt i överensstämmelse med resultatet utformar, konstruerar och inför IS i praktisk tillämpning.
Viktigt här är att processen börjar med att man utreder förutsätt-ningarna, vilket ger en mycket bred definition av systemutveckling. Systemutveckling innebär att man nyutvecklar eller vidareutvecklar ett informationssystem. Viktiga inslag i denna process är analys av verksamhet och informationssystem, utformning av såväl principiell som praktisk teknisk lösning samt realisering och implementering av lösningen. Målet är att informationssystemet ska lösa problem i verksamheten, men det gäller att vara uppmärksam på vilken typ av problem som en teknisk lösning kan lösa respektive inte lösa. (An-dersen 1994)
Inom användarcentrerad systemutveckling ser man gärna utveck-lingen ur perspektivet mentala modeller. Man har då att göra med designerns och användarens respektive konceptuella modell av syste-met. Ett viktigt problem är här hur designern uttrycker sig angående systemet så att designerns och användarens mentala modeller stäm-mer överens med varandra. Användarens modell skapas inte direkt från designerns modell, utan genom olika slags interaktion. (Gul-liksen & Göransson 2002)
3.1.3 Design och designer
Design och designer har något skilda betydelser i svenska och eng-elska, vilket kan leda till missförstånd. Därför tar jag med följande förklaring av hur det ligger till med orden:
design – konstruktion, formgivning, design. «Design» har en djupare innebörd på engelska än på svenska. «To design a computer» kan oftast översättas med «att kon-struera en dator». Svenska «designa» är vanligen
syno-nymt med «formge», alltså mer estetiskt än ingenjörs-mässigt. – I systemutveckling används «design» om den fas när man «gör upp ritningarna» till systemet, alltså fa-sen mellan kravanalys och implementering. (Computer Swedens ordlista 2007, sökord: «design»)
Jag använder i denna studie orden design och designer med en bred svensk/engelsk innebörd, i linje med hur orden används i mina svenskspråkiga källor.
3.1.4 Programmering
Begreppet programmering visar sig ha olika innebörder beroende på vem man frågar. Här följer två exempel.
I Nationalencyklopedin beskrivs programmering på följande sätt: programmering … i databehandlingssammanhang skri-vande av instruktioner för en dators arbete. (Nationalen-cyklopedin 2007)
Detta är ett synsätt som inte delas av Computer Swedens språk-webb:
programmering – att tänka ut, planera, framställa och testa datorprogram. Att «skriva kod» är alltså inte sam-ma sak som att programmera. När programmering görs med ingenjörsmässiga metoder talar man om program-utveckling eller systemprogram-utveckling. (Computer Swedens ordlista 2007, sökord: «programmering»)
I denna studie används termen programutveckling med innebörden utveckling av mjukvara genom olika steg; detta för att undvika den mindre tydliga termen programmering.
3.1.5 Problemlösning
Det lönar sig ofta att tänka igenom sådant som man annars tar för givet; därför behandlas här kort problemlösning som fenomen.
När vi ska lösa en uppgift där lösningen är svår att uppnå direkt använder vi vanligen någon form av problemlösning. Detta innebär att vi går igenom flera steg på vägen fram till lösningen. Två över-gripande steg kan vara att först förstå problemet, för att sedan söka möjliga riktningar som leder till en lösning. (Encyclopædia Britan-nica 2007)
Ovanstående kan låta självklart, men från pedagogiskt håll har det uppmärksammats att man är omedveten om detta inom undervis-ning i programmering. Studenterna ställs inför uppgiften att hitta en lösning till ett problem, istället för att först lära sig att identifiera problemet. Genom att först identifiera och sedan lösa problem ökar studenternas självförtroende och förmåga till problemlösning. (East-man 2003)
På 1950-talet togs en modell för problemlösning fram av matemati-kern Polya som kan sammanfattas i följande steg:
Beskriv och förstå problemet. •
Finn alternativ till lösning bland annat genom att fin-•
na likheter med andra problem (som redan är lösta). Välj ett lösningsalternativ och genomför det.
•
Jämför resultatet med det ursprungliga problemet. •
(Wiktorin 2003, s. 29)
För att lösa komplexa problem är vissa egenskaper viktiga, Mum-ford (1998) nämner särskilt skicklighet, kompetens och koordination. Cunningham (2002) beskriver problemlösning som en aktivitet där vi ägnar oss åt att iaktta, analysera och utforska.
3.2 Prototyper och prototypning
Vi har redan varit inne på att man använder prototyper för att få svar på en eller flera frågor (kapitel 3.1.1). Men att få svar på frågor innebär att man samlar eller utvecklar kunskap. Någon som uttryckt detta mycket tydligt är Kurt Schneider:
A prototype can be seen as just another representation for requirements and solution knowledge. (Schneider 1996, s. 522)
En fråga som uppstår här är hur denna kunskap tas till vara. Det finns en risk att kunskapen stannar hos den enskilde utvecklaren, vilket Schneider illustrerar på detta sätt (se figur 2):
Risken med att kunskapen är hårt knuten till enskilda utvecklare är att den kan gå förlorad till exempel om en utvecklare lämnar teamet. Förlorad kunskap kan till exempel leda till att man gör något som man redan provat i en prototyp och förkastat, men denna kunskap finns inte längre tillgänglig. Samtidigt är prototyper något som be-höver utvecklas snabbt, vilket innebär att begränsade resurser står till förfogande för att skapa dokumentation. En möjlig väg är att skapa ett system för att dokumentera prototyper och den återkoppling man får angående dessa. Ett sådant system måste vara effektivt att samla information i och underlätta navigering i den informationsrymd som skapas. (Schneider 1996)
För att få en tydligare bild av vad prototyper kan vara ska vi se när-mare på olika dimensioner och synsätt som man använder för att förstå prototyper.
Figur 2. Förhållandet mellan prototyp och utvecklare. (Schneider 1996, s. 523)
3.2.1 Användningssätt
Prototyper kan användas i olika faser av ett systemutvecklingspro-jekt, och har då olika roller. Tre grundläggande aktiviteter som kan utföras med stöd av prototyper är:
projektstart,
analys av verksamhetens behov,
design och realisering av systemet. (Lichter et al 1993)
I samband med projektstart kan det handla om att sälja in systemet hos beställare och användare, och även om att ha med visuell infor-mation om det framtida systemet i en kravspecifikation. Finns det särskilda tekniska svårigheter med ett system kan man göra en pro-totyp som visar att det går att få bukt med svårigheterna. (Ibid.) För att klargöra verksamhetens behov och systemets motsvarande funktionalitet används ofta prototyper av användargränssnittet. (Ibid.)
För att undersöka olika designer och sätt att realisera systemet kan prototyper användas. Dessa prototyper brukar vara för internt bruk. (Ibid.)
3.2.2 «Slit och släng» kontra evolutionär prototypning
Två olika arbetssätt som används inom prototypning är att använda prototyper som:
slängs när man fått svar på sina designfrågor i vid bemärkelse,
utvecklas vidare till en driftsversion av systemet.
Figur 3 visar hur dessa alternativ skiljer sig åt, med den första vari-anten till vänster och den andra till höger. I fallet med slit och släng sker en noggrann dokumentation av det man kommit fram till med hjälp av prototypen. I det andra fallet måste man bedöma om proto-typen går att göra tillräckligt effektiv för att användas i drift. I så fall lägger man till felhantering och annat som saknas i prototypen, men behövs i en driftsversion. (Andersen 1994)
Ett frågetecken med Andersens modell är om det verkligen inte be-hövs ett särskilt steg för dokumentation av vad prototypen visat när
Figur 3. En utvecklingsmodell för prototypning. (Andersen 1994, s. 412)
man väljer att låta prototypen bli en driftsversion (jämför Schneider 1996).
Man kan även rikta en kritik mot Andersens modell från ett annat håll: Andersen verkar utgå från att det i fallet med en prototyp som är avsedd att slängas handlar om att olika personer framställer proto-typ respektive driftsversion. Men att överlämna utvecklingen från ett team till ett annat förbrukar i sig resurser, och kan därför ses som att resurser kastas bort. Frågan är om överlämnandet tillför kundnytta till slut eller inte. (Jämför Poppendieck & Poppendieck 2003)
Ytterligare ett perspektiv på evolutionär prototypning är att man ska-par en kontinuerlig process för att anpassa ett system till förändrade villkor för verksamheten. Man ser inte systemet som något avslutat, utan system och utvecklingsprocess hör tätt samman. (Lichter et al 1993)
3.2.3 Presentationsprototyper: lo-fi och hi-fi
För att tidigt i ett projekt komma igång på ett bra sätt är det vanligt att man gör presentationsprototyper, som sedan slängs (Schneider 1996). Dessa kan karakteriseras ytterligare enligt nedan.
Man talar om hur «naturtrogen» en prototyp är. En låg nivå (lo-fi) på denna skala har till exempel handritade skisser på papper. Långt upp (hi-fi) kommer datorbaserade representationer av ett system, som omfattar systemets estetik och interaktion. (Bryan-Kinns & Hamil-ton 2002)
Jämför med hi-fi (förkortning av «high fidelity») när det gäller ste-reoanläggningar, där det innebär en hög grad av trohet mot original-ljudet.
3.2.4 Horisontella och vertikala prototyper
Prototyper motsvarar ofta delar av system, och då kan systemet «skä-ras» på olika sätt (se figur 4). En prototyp som går på djupet har en vertikal skärning, vilket innebär att samtliga skikt från använ-dargränssnitt till datalager finns med. Därmed speglas funktionerna inom en del av systemet. En förenklad variant av detta är ett scenario, som inte omfattar samtliga skikt. Skär man horisontellt kan man till exempel göra en prototyp för hela användargränssnittet, men inte ha någon funktionalitet bakom. (Gulliksen & Göransson 2002)
En horisontell prototyp kan även göras för till exempel datalagret. Man ska lägga märke till att det översta skiktet inte behöver vara just ett användargränssnitt, och att applikationer kan ha fler eller färre lager än de tre som tas upp här. (Lichter et al 1993)
Horisontella prototyper kan användas i systemutveckling för att un-derlätta parallell utveckling av olika delar av ett system. Till exempel kan man skapa en prototyp av datalagret som sett från systemets öv-riga delar är ett fungerande datalager med komplett gränssnitt, men som i själva verket bara svarar med data som lagts in fast i program-koden. (Se Evans 2004)
3.2.5 Utforskande och experimentella prototyper
En utforskande prototyp används när problemet som ska lösas är oklart. Det handlar såväl om systemets kontext på till exempel en arbetsplats som hur själva systemet ska se ut. Man betonar att prova olika designer och inte välja ett spår för tidigt. Utvecklarna får insikt i verksamheten och de problem som de anställda står inför. (Lichter et al 1993)
Experimentell prototypning fokuserar på den tekniska
implementatio-nen av något. Här handlar det mer om att prova olika lösningar och skapa ett system med hög användbarhet. (Ibid.)
Figur 4. Tre olika slags prototyper: vertikal, horisontell eller i form av ett scenario. (Figur efter Gulliksen & Göransson 2002, s. 245)
Data Logik Användargränssnitt Data Logik Användargränssnitt Data Logik Användargränssnitt
3.2.6 Funktioner, gränssnitt och implementation
Houde och Hill (1997) har beskrivit ett sätt att dela in prototyper utifrån hur de används. De dimensioner som de tar upp är följande (se även figur 5):
Role: vilken roll ett system ska spela (funktionalitet),
Look and feel: systemets utseende och beteende,
Implementation: hur man kan implementera en aspekt av syste-
met. (Houde & Hill 1997)
Systemets roll handlar om vilken nytta man har av det, vad systemet kan göra för användarna. Annorlunda uttryckt handlar det om vilka funktioner som systemet ska ha. Ett exempel kan vara skisser som visar olika aktiviteter som kan utföras med ett operativsystem. Pro-totyper av utseende och beteende används för att utvärdera de sin-nesintryck som man får när man använder det. I denna kategori finns både detaljerade bilder av hur systemet skulle kunna se ut, och klick-bara prototyper som uppvisar ett beteende. Implementationsproto-typer används för att bedöma om en teknisk lösning håller måttet, till exempel om en filmsnutt kan visas utan att bilden hackar. (Ibid.) De olika sätten att använda prototyper behöver inte användas i nå-gon viss ordning, utan detta beror på projektet. Är det kritiskt för framgång att ett program ska kunna visa upp rörliga figurer med god bildkvalitet på ordinära hemdatorer kanske man börjar med imple-mentationsprototyper för att undersöka om detta är genomförbart. (Se ibid.)
Look and feel Integration
Implementation
Role
Figur 5. Tre olika dimensioner för prototyper: roll, utseende och bete-ende samt implementation. (Figur efter Houde & Hill 1997, s. 6)
3.3 Systemutvecklingsmodeller
I en undersökning som publicerades 1996 (Bäumer et al) var följande en av de trender som man kunde iaktta:
Traditional life-cycle approaches are being replaced by evolutionary strategies in projects focused on building user-friendly systems. Prototyping is today an establis-hed part of these evolutionary strategies. (Bäumer et al 1996)
Här ser vi hur begreppen användarvänlig, evolutionära strategier och prototypning sammanförs. För att bättre förstå vad det handlar om ska vi se närmare på olika systemutvecklingsstrategier eller -model-ler.
Jag tar upp vattenfallsmodellen som ett exempel på en traditionell strategi inom systemutveckling, som kontrast till agil utveckling. Ci-tatet ovan och liknande utsagor gjorde mig intresserad av vilken roll användarcentrerad systemdesign har i sammanhanget, därför finns det även ett avsnitt om den.
3.3.1 Vattenfallsmodellen
Den modell för problemlösning som Polya har föreslagit (se kapitel 3.1.5) har inspirerat en fasindelning av systemutveckling enligt föl-jande: specifikation, analys, konstruktion, provning. (Wiktorin 2003)
Denna fasindelning är mycket vanlig och innebär en naturlig ord-ningsföljd mellan momenten, som fått beteckningen vattenfallsmo-dellen. Tidiga varianter på denna modell föreskrev att arbetet i en fas skulle vara klart innan man fortsatte till nästa fas. I praktiken brukar man behöva gå tillbaka till föregående fas på grund av brister som vi-sar sig. Det senare är det gängse arbetssättet idag. (Wiktorin 2003) En mer omfattande variant av vattenfallsmodellen är livscykelmo-dellen (se Figur 6). Viktiga punkter i detta synsätt är att användarna
ska analysera sig fram till sina önskemål, och att detta ska göras inn-an utformningen av systemet påbörjas. Analysfasen är särskilt viktig; om den utförs dåligt blir hela informationssystemet dåligt vad man än gör senare i projektet. Till exempel när problemställningarna för-ändras hela tiden kan livscykelmodellen vara mindre lämplig. Där-emot passar den väl för stabila verksamheter, till exempel när man flyttar över manuella rutiner till ett informationssystem. (Andersen 1994)
3.3.2 Agil utveckling
Inom agil utveckling finns det många olika metoder och angrepps-sätt med en gemensam kärna av värden som uttrycks i det agila ma-nifestet:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more. (Beck et al 2001a)
För-
ändrings-analys
Analys
Utform-ning Realise-ring menteringImple- ning och Förvalt-drift Avveck-ling Systemering Systemutveckling Livscykel Valda u tveck lingsåtgärd er Kravs pecifikatio n Realiserbar t info rmatio nssystem Färdig t info rmatio nssystem Infört infor matio nssystem Figur 6. Livscykelmodellen. (Figur efter Andersen 1994, s. 48)
Inom agil utveckling undviker man att ha ett långt avsnitt i början av projekt där man utförligt slår fast samtliga krav i detalj. Istället växer kraven fram och utvecklas under projektets gång. Om såväl kraven som den teknik som ska användas är väl kända och förstådda skulle ett mjukvaruprojekt kunna följa ett linjärt förlopp. Men i den ut-sträckning som det finns oklarheter kring krav eller teknik – och det brukar det finnas gott om – ökar projektets komplexitet, och ett an-nat arbetssätt behövs. Istället för att enbart staka ut en färdriktning i början av projektet måste denna kontinuerligt anpassas utifrån vad man upptäcker under arbetet. (Schwaber & Beedle 2002)
För att hantera krav på ett rationellt sätt utan att behöva frysa dem helt använder man inom den agila metoden Scrum något som kallas för time-boxing. Det innebär att man fryser kraven under en be-stämd tid, då utvecklarna får arbeta i fred. En enda person, exem-pelvis projektledaren eller produktansvarig, ansvarar för vad som ska utföras i nästa time-box. Den personen hanterar listan med krav och prioriterar mellan dessa. (Schwaber 2004)
Centralt för agil utveckling är att underlätta samverkan mellan kund/ beställare och utvecklare. (Wiktorin 2003)
Användare har lättare att förstå fungerande programvara än doku-ment som beskriver programvaran. Därför arbetar man inom agil utveckling med att skapa fungerande program tidigt och ofta i ett projekt. Man behöver också ta hänsyn till att förändringar hör till i mjukvaruutveckling: villkoren för en verksamhet förändras, teknik förändras över tid. Intressenternas förståelse av systemet förändras. Man behöver ha en projektplan, men samtidigt lämna ett spelrum för förändringar av denna. (Ambler 2002)
Det tillhör de grundläggande principerna inom agil utveckling att personer från verksamheten och utvecklare arbetar tillsammans dag-ligen genom hela projektet. (Beck et al 2001b)
3.3.3 Användarcentrerad systemdesign
Användarcentrerad systemdesign fokuserar på användare och an-vändbarhet under hela utvecklingsprocessen. Systemet utvecklas evolutionärt med den typ av iterationer som beskrivs i figur 7. Proto-typer används tidigt i projektet och under hela dess förlopp. Målet är
att visualisera och utvärdera designlösningar tillsammans med slut-användarna. (Gulliksen & Göransson 2002)
Inom användarcentrerad systemdesign rekommenderas att man bör-jar med prototyper i form av enkla pappersskisser och konceptuell design på hög nivå. Man lägger stor vikt vid att designförslagen ut-värderas mot mätbara användbarhetsmål som satts upp för projektet. (Ibid.)
En målsättning är att skapa en delad förståelse bland alla inblandade parter. Därför behövs en representation av designen som ger använ-darna en konkret bild av hur det är att använda systemet, samtidigt som den behöver vara effektiv för utvecklarna. (Ibid.)
Alla delar av systemet ska utvecklas parallellt, kontinuerligt och i ett sammanhang med varandra. Detta gäller allt från användargränssnitt till handböcker och arbetsmiljöaspekter. På så vis kan man uppnå en integrerad systemdesign. (Ibid.)
3.4 Att förstå systemutveckling
För att förstå prototypernas roll i systemutveckling behöver man också förstå systemutveckling. Därför ägnas följande kapitel åt frå-gor kring vad systemutveckling är för något.
3.4.1 Peter Naur
Vad är egentligen systemutveckling, vad går det ut på? I första hand kanske man tänker på det system som produceras, i form av specifi-kationer, dokumentation av olika slag samt programkod. Med detta
Analys av användarna, arbetsuppgifter och användningssammanhang
Designförslag med prototyper – i sig en iterativ process som beskriver det kreativa arbetets natur Utvärdering med
mätningar mot användbarhetsmål Återkoppling med förslag till förändringar
Användarfokus, mätbar användbarhet och iterationer
Figur 7. Grundelementen i en iterativ användarcentrerad process. (Figur efter Gulliksen & Göransson 2002, s. 109)
tänkesätt är systemutvecklarens uppgift främst att producera dessa olika artefakter. En person som lagt fram ett alternativ till detta syn-sätt på sådana frågeställningar är dansken Peter Naur, en förgrunds-figur inom dansk datalogi.
Naurs forskning har sin bakgrund i svårigheten att förklara vissa blem utifrån det Naur kallar för ett produktionsperspektiv på pro-gramutveckling; alltså att produktionen av vissa artefakter är centralt i programutvecklingsprocessen. Två typiska fenomen som kan belysa detta är de problem som hänger samman med att rätta programkod som innehåller fel, respektive att modifiera program. (Naur 1985) I detta sammanhang använder Naur begreppet programmering, men säger tydligt att han avser hela raden av aktiviteter från utformning på olika nivåer till implementation av mjukvara. Jag väljer här istäl-let att använda ordet programutveckling när jag refererar Naur, efter-som programmering enligt min mening lätt kan förknippas med att «skriva kod» i mer inskränkt bemärkelse. (Se Naur 1985 samt kapitel 3.1.4 i denna studie)
Naur ser programutveckling som att man får symbolmanipulering som kan utföras av ett datorprogram att överensstämma med en del och aspekt av något i den riktiga världen. Med dessa begrepp som bakgrund blir det tydligt att förändringar i den riktiga världen måste motsvaras av en ofrånkomlig aktivitet i programutvecklingen, näm-ligen att man modifierar program. (Naur 1985)
Att program behöver modifieras är alltså inte någon «extra» aktivitet utanför programutvecklingen, utan ingår som en normal del i denna. Därmed är det också tveksamt om man någonsin kan se programut-vecklingsprojekt som fullständigt avslutade.
Den huvudtes som Naur driver är att programutveckling i första hand sker i form av att programutvecklaren bygger upp en kunskap av ett särskilt slag. Denna kunskap är primär, medan till exempel varje form av dokumentation utgör en yttre sekundär produkt. Detta kan hjälpa oss att förstå varför det är så svårt att bygga ut befintliga program, även när dessa är väldokumenterade och byggda enligt sunda princi-per för programutveckling. (Naur 1985)
Utifrån ett produktionsperspektiv på programutveckling är det na-turligt att anta att man bör kunna modifiera eller utöka program till en låg kostnad. Detta skulle isåfall stå i motsättning till förändring
av andra komplicerade konstruktioner som till exempel byggnader, där rivning och nybyggnation ofta är mer ekonomiskt fördelaktigt än ombyggnation. Ser man programutveckling som en form av text-produktion – att datorprogram redigeras som en form av texter in-bjuder till det – är det naturligt att tänka att utökning av ett program handlar om skrivandet av ytterligare ett tämligen litet antal rader text (programkod). Men då tar man miste. Programutveckling hanterar i själva verket synnerligen komplicerade konstruktioner. (Naur 1985) En möjlig jämförelse för ett mindre utvecklingsprojekt skulle kunna vara en lärobok där olika kapitel skrivits av olika författare. Inför en ny upplaga låter man någon författare skriva till ett kapitel om till exempel ny teknik som kommit fram. Kanske behöver förfat-taren inte ens läsa resten av boken, och kostnaden inskränker sig till kostnaden för det nyskrivna kapitlet, som helt enkelt läggs till i bo-ken. Då stämmer ett rent produktionsperspektiv, och kostnaden för förändringen är låg. Men det kan också vara så att den nya tekniken har betydelse för innehållet i samtliga kapitel i boken, som plötsligt blivit föråldrade. Då står man inför valet att omarbeta hela boken från grunden eller att låta skriva en ny bok, där bägge alternativen är väsentligt dyrare än att bara lägga till ett kapitel. Skulle man trots att stora delar av boken blivit föråldrade välja att bara lägga till ett nytt kapitel blir resultatet en bok av lägre kvalitet, som inte längre uppfyl-ler sitt syfte lika väl. Upprepas detta fuppfyl-lera gånger blir boken allt mer osammanhängande och inkonsistent för varje gång.
Den kunskap som programutvecklare bygger upp utvecklas till ett slags teori som går väsentligt längre än till att endast ha kännedom om något. Det krävs insikter på en nivå som gör att man kan förklara hur en lösning svarar upp mot de problem eller behov som existerar i verksamheten samt varför man valt just detta sätt att lösa problemen. Dessutom ska insikten göra att man kan ge en konstruktiv respons på hur förändringar av lösningen kan stödja verksamheten på nya sätt när behovet uppstår. Uppfylls dessa kriterier kan man säga att utvecklaren har en teori om systemet och dess kontext. (Naur 1985) En forskare som anknyter till Peter Naur är Alistair Cockburn, som även är känd som författare med inriktning mot agil systemutveck-ling. Nedan följer några av hans kommentarer kring Naurs idéer. Den kunskap som utvecklas vid systemutveckling kan beskrivas som en form av tyst kunskap hos utvecklarna. Det rör sig om en förståelse
av å ena sidan det behov eller problem som finns i verksamheten, å andra sidan av hur detta kan tillfredsställas eller lösas. Dessutom tillkommer förståelsen av hur dessa bägge sidor svarar mot varan-dra. En samstämmighet mellan dessa båda sidor är nödvändig för att skapa it-system av god kvalitet. När en utvecklare kommer in senare hänger kvaliteten på hans arbete på att hans förståelse av det befint-liga systemet överensstämmer med förståelsen hos dem som byggt systemet. (Cockburn 2006)
3.4.2 Pelle Ehn
Pelle Ehn lyfter fram två utvecklingstendenser inom mjukvaruut-veckling:
en
teoretisk utveckling mot ett processorienterat humanistiskt pa-radigm,
en
teknisk utveckling mot kraftfulla miljöer för prototypning. (Ehn 1988)
Det nya teoretiska perspektivet handlar om att fokusera på lärande och kommunikation vid både användning och utveckling av mjuk-vara. Kvaliteten hos mjukvara bedöms i detta perspektiv inte enbart utifrån dess överensstämmelse med en kravspecifikation, utan man ser till dess relevans och ändamålsenlighet i praktiska användnings-situationer. Följden blir att mjukvaruutveckling inte kan ses som en rad faser ordnade i tiden där formella dokument förfinas allt mer för att slutligen mynna ut i ett system. Istället ser man den som en fortlöpande process där design, implementation och utvärdering sker i cykler i kontexten av den arbetsprocess där mjukvaran ska användas. Designartefakter som exempelvis prototyper används för att under-lätta kommunikation och samarbete, där man steg för steg kommer underfund med systemet. (Ibid.)
När det gäller de nya tekniska möjligheterna med prototyper ser Ehn många användningsområden. Det han ser som den centrala frågan är: innebär prototyperna att användarna får möjlighet att experimen-tera med olika prototyper, så att de kan samla erfarenhet som en grund för designkrav? (Ibid.)
Byggt på denna grund ser Ehn framför sig möjligheten till ökad kreativitet och ett större inslag av användardeltagande vid systemut-veckling. (Ibid.)
3.5 Systemutveckling och prototyper
3.5.1 Prototypning i verksamhetsutveckling
Prototyper kan användas i olika skeden av en cess. Dessutom uppkommer frågan om hur systemutvecklingspro-cessen relaterar till verksamhetsutvecklingsprosystemutvecklingspro-cessen, och vad proto-typer har för roll i sammanhanget.
Traditionellt sett är systemutvecklingsprocessen och verksamhetsut-vecklingsprocessen åtskilda företeelser, och prototypningen saknar då samband med verksamhetsutvecklingsprocessen (Gulliksen & Göransson 2002). Se figur 8.
När systemutvecklingen leder till mer konkreta resultat som proto-typer är det vanligt att verksamhetsprocesserna behöver modifieras påtagligt. Ett sätt att hantera detta är att arbeta med prototypning redan i samband med verksamhetsmodelleringen. Man tar då fram
Figur 8. Relationen mellan systemutveckling och utvecklingen av verksamhetsprocesser i verkliga livet. (Figur efter Gulliksen & Gö-ransson 2002, s. 299)
Verksamhetsutvecklings-process Systemutvecklingsprocess
Återkoppling?
Prototyping
Figur 9. Prototypning under hela verksamhetsutvecklingen för att tidigare kunna ta fram krav som är begripliga för användaren. (Fi-gur efter Gulliksen & Göransson 2002, s. 300)
Verksamhetsutvecklings-process Systemutvecklingsprocess
Återkoppling?
kraven med hjälp av prototyper, vilket förbättrar möjligheterna att utveckla ett system som passar verksamheten. (Gulliksen & Görans-son 2002) Se figur 9.
Även med en användarnära och konkret process med prototypning kvarstår att frysta kravspecifikationer under systemutvecklingen innebär klara nackdelar. I själva verket kan man använda prototyp-ning genom hela utvecklingsprocesserna, som därmed knyts närmare till varandra. (Gulliksen & Göransson 2002) Se figur 10.
Det skisserade arbetssättet ger fördelar i form av tidig upptäckt av fel i verksamhetsprocesserna, användardeltagande underlättas, iterativ design underlättas och utvärdering blir möjligt att genomföra tidigt i processen. (Gulliksen & Göransson 2002)
3.5.2 Agila prototyper
Den annorlunda processen vid agil utveckling leder till att tidiga prototyper under ett projekt minskar i intresse, eftersom den fas som ligger före själva systemutvecklingen är kort: man bygger fungerande system tidigt istället. (Se kapitel 3.3.2)
Istället för att modellera ett system i stor skala («Big Design Up Front») för att sedan utvärdera modellen och slutligen realisera den i programkod modellerar man mindre bitar i taget, och skapar både testkod och programkod för att se att det fungerar (Ambler 2002). Därmed modellerar man och skapar systemet i en integrerad process, vilket kan ses som en form av prototypning (se Gulliksen & Görans-son 2002 samt kapitel 3.1.1).
Figur 10. Tidig och kontinuerlig prototypning får produkten att «växa» till. (Figur efter Gulliksen & Göransson 2002, s. 301)
Verksamhetsutvecklings-process Systemutvecklingsprocess
3.5.3 Prototypernas roll
Det som tidigare sades om utforskande och experimentella proto-typer kan även uttryckas på andra sätt, och jag menar att Scott W. Ambler har gjort detta på ett intressant sätt när han tar upp olika användningsområden för prototyper, och då nämner:
som analysartefakt som ger möjlighet att utforska problemrym-
den tillsammans med intressenterna,
som designartefakt som ger möjlighet att utforska systemets lös-
ningsrymd. (Ambler 2004)
Genom att tala om problemrymd och lösningsrymd är Ambler inne på ett spår som vi känner igen från Peter Naur och även Alistair Cockburn (se kapitel 3.4.1). Men nu handlar det om just prototyper som ett hjälpmedel för att utveckla kunskap om problemrymden och lösningsrymden.
Här vill jag även tillfoga något. Med anknytning till Pelle Ehn (se kapitel 3.4.2) vill jag hävda att de krav som användare och andra in-tressenter ställer på ett system till stor del bygger på deras erfaren-heter. Den svårighet som uppstår är hur man ställer krav på något som man inte ännu har erfarenhet av! Där kan prototyper hjälpa till med att under projektets gång ge möjlighet att skapa relevanta erfarenheter. På så vis ökar möjligheterna för användare och andra intressenter att definiera problemet på ett adekvat sätt redan under systemutvecklingsprocessen.
Systemutvecklare står inför liknande problem när de utvecklar sys-tem med inslag som de saknar erfarenhet av. Här kan man på mot-svarande sätt skapa erfarenheter genom att arbeta med prototypning, och på så vis minska risken att designbeslut fattas på felaktiga grun-der.
En annan författare som är inne på ett liknande spår är Kurt Schnei-der, som ser prototyper som representation av kunskap (Schneider 1996).
I takt med att prototyperna utvecklas återger de allt mer kunskap om krav och lösningar, för att kunna vara till hjälp för att fånga kunska-per på nästa nivå.
3.6 En sammanfattande modell
3.6.1 Motivering av modellen
Utifrån det som lagts fram hittills i teorikapitlet har jag skapat en preliminär modell för prototyper i systemutveckling. Den beskrivs i text och figurer nedan.
Avsikten är lyfta fram väsentliga synpunkter på strukturering av pro-totypbegreppet utifrån de teorier som jag har tagit upp. Målsätt-ningen är att göra begrepp och deras relationer mer lättillgängliga. Detta uppnås dels genom att utgå från helt grundläggande begrepp, dels genom att en visuell representation av modellen tas fram. Just genom att fokus ligger på grundläggande begrepp ges utrymme att längre fram fylla på med detaljer, och tydligare se hur olika begrepp verkligen relaterar till varandra. Detta minskar risken att gå vilse i den stora mängd begrepp och angreppssätt som utvecklats inom om-rådet.
3.6.2 Preliminär begreppsmodell för prototypning
Systemutveckling har två grundläggande sidor, nämligen krav som ska omsättas i ett system. Om vi tar ett steg tillbaka finner vi två begrepp på ett mer grundläggande plan. Såväl krav som system här tätt samman med den praktiska verkligheten. Å andra sidan har vi de teorier som vi bygger upp kring denna verklighet. Ser vi detta sammanhang mer ur ett processperspektiv ger sig begreppen
pro-blemrymd och lösningsrymd, som vi stiftat bekantskap med tidigare.
Utifrån detta får vi följande sex begrepp som en ram för systemut-vecklingsprojekt:
Tabell 2: Ram för systemutvecklingsprojekt
teori problem lösning
praktik krav system
Genom att även ta hänsyn till att det finns en ordningsföljd i förlop-pet vid systemutveckling får vi följande första utkast till en modell för prototyper i systemutveckling (se figur 11):
ett arbetssätt där man tillåter att kraven förändras under projek-
tets gång,
det faktum att man ofta påbörjar utvecklingen med utgångspunkt
från en tidigare systemutvecklingsprocess (systemarv).
Det steg som verksamheten tar är att gå från ett behov som formu-leras som beställning eller krav till att ett it-system införs eller för-ändras utifrån detta. Systemutvecklingsprocessen tar i sin tur fasta på kravmängden och analyserar den i form av ett problem som ska lösas. Den andra sidan av systemutvecklingsprocessen är att man utfors-kar lösningsmöjligheterna, från rent konceptuella sådana och ned till konkreta lösningar som kan implementeras i det färdiga it-systemet. Detta beskrivs i modellen som två nivåer, som jag betecknat som praktik och teorier.
Nu är det dock uppenbart att det viktigaste saknas i modellen: be-greppet prototyp. Utifrån det som sagts i detta kapitel vill jag
fram-problem lösning
krav system
teorier
praktik
hålla att prototypning är ett mångfasetterat arbetssätt, som kan passa in på många ställen i modellen. Därmed får man tänka sig begreppet prototyp som något rörligt som kan finnas på många ställen i model-len samtidigt.
Ofta är det en person som tar fram prototypen, och någon, till exem-pel en användare, som provar och kommenterar den. När en designer tar fram en prototyp för eget bruk kan man även se detta som att designern växlar mellan två olika roller, där man kan se det som att designern även är användare i det fallet. De begrepp som vi nu tillför modellen är: designer prototyp användare
Därmed har vi nått fram till följande modell (se figur 12):
problem lösning krav system prototyp användare designer teorier praktik
Denna preliminära modell följde med in i arbetet med empirin. Ef-ter att ha gjort två inledande inEf-tervjuer med fokus på teorin (se nästa kapitel) försökte jag göra modellen tydligare genom att förändra be-greppen något:
verksamhet
är tydligare än praktik,
begreppsstrukturer
är ett alternativ till teorier,
problemrymd
är tydligare än bara problem,
lösningsrymd
är tydligare än bara lösning,
informationsbehov
är tydligare än bara krav,
it-system
är tydligare än bara system,
jag insåg vikten av att ha med både substantivet prototyp och
verbet prototypning,
beroende på vem man talar med kan begreppen designer respek-
tive utvecklare passa in bättre,
förutom användare finns även övriga
intressenter.
Därmed är vi framme vid en bild (se figur 13, nästa sida) av den teo-retiska modell som jag hade som grund för resterande intervjuer (se nästa kapitel).
prototyp(ning) problemrymd lösningsrymd informationsbehov it-system begreppsstrukturer verksamhet användare intressent designer utvecklare
4 Empiri
Kapitlet presenterar utdrag ur intervjuer samt kortare sammanfatt-ningar av intervjuerna.
4.1 Upplägg för intervjuerna
4.1.1 Preliminär teoretisk modell
Som grund för intervjuerna har jag använt en preliminär teoretisk modell baserad på litteraturstudier. Se teoridelen för ytterligare de-taljer (kapitel 3.6) och bakgrund (hela kapitel 3).
4.1.2 Intervjuernas ställning i uppsatsen
Intervjuerna utgör vid sidan av teorin uppsatsens kärna. Att försö-ka sammanfatta intervjuernas innehåll låter sig inte göras utan att mycket går förlorat. Därför presenteras intervjuerna innehåll i form av utdrag. För att markera deras vikt i uppsatsen har dessa utdrag placerats direkt i empirikapitlet och inte i ett appendix. Detta kan också ses som en uppmaning till läsaren att även läsa dessa sidor! För att skapa en bättre överblick över intervjumaterialet har trots svårigheterna sammanfattningar av dem lagts till i slutet av kapitlet. 4.1.3 Urval av intervjupersoner
Intervjupersonerna har valts ut med tanke på att ge en bred bild av prototypanvändning inom systemutveckling idag. Såväl produktut-veckling av olika slag som it-konsulttjänster finns representerade. Såväl arbete på server- som klientsidan finns med.
Ett fåmansföretag hade tackat ja till att delta, men föll bort på grund av den höga arbetsbelastning som rådde på företaget under perio-den.
4.1.4 Praktiskt genomförande
I de två första intervjuerna, med Lars Degerstedt respektive med Arne Jönsson, användes den preliminära modellen som ett underlag för att gemensamt utforska området prototyper i systemutveckling. Detta ledde till en mindre bearbetning av modellen, samt uppslag som jag kommer att ta upp i analysen.
