...

Prototyper i systemutveckling Agila och traditionella angreppssätt Prototyping in Systems Development

by user

on
Category: Documents
5

views

Report

Comments

Transcript

Prototyper i systemutveckling Agila och traditionella angreppssätt Prototyping in Systems Development
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
Institutionen för ekonomisk och industriell utveckling
Prototyper
i systemutveckling
– agila och traditionella angreppssätt
Linköpings universitet
Institutionen för ekonomisk och
industriell utveckling (IEI)
kandidatUppsats
Anders Nawroth
[email protected]
Handledare: Tommy Wedlund
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 systemutveckling, 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 systemutveckling. 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 systemutvecklingsprojekt i praktiken. Utifrån detta material presenteras en vidareutveckling 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 prototyper i riktning mot att utföra prototypning i det ordinarie utvecklingsspåret samt att hämta in regelbunden återkoppling på prototyper från användare och andra intressenter under hela systemutvecklingsprojektets gång. Sådana arbetssätt visade sig också förekomma
inom den praktiska systemutvecklingen.
Innehåll
1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Intresseområde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Frågeställningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Avgränsning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Målgrupp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Referenshantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Disposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1
2.2
2.3
2.4
Inledande anmärkning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Förförståelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Kunskapsläge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Kunskapsbehov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1Kunskapskarakterisering . . . . . . . . . . . . . . . . . . . . . . . . . 7
Kunskapsstrategi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Metodval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Reliabilitet och validitet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Metodkritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5
2.6
2.7
2.8
3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Begrepp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2Systemutveckling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.3Design och designer . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.4Programmering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.5Problemlösning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Prototyper och prototypning . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1Användningssätt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2«Slit och släng» kontra evolutionär prototypning . . . . . 17
3.2.3Presentationsprototyper: lo-fi och hi-fi . . . . . . . . . . . . . 19
3.2.4Horisontella och vertikala prototyper . . . . . . . . . . . . . . 19
3.2.5Utforskande och experimentella prototyper . . . . . . . . . 20
3.2.6Funktioner, gränssnitt och implementation . . . . . . . . . 21
3.3 Systemutvecklingsmodeller . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.1Vattenfallsmodellen . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.2Agil utveckling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.3Användarcentrerad systemdesign . . . . . . . . . . . . . . . . . 24
3.4 Att förstå systemutveckling . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.1Peter Naur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.2Pelle Ehn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 Systemutveckling och prototyper . . . . . . . . . . . . . . . . . . . . . 29
3.5.1Prototypning i verksamhetsutveckling . . . . . . . . . . . . . 29
3.5.2Agila prototyper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.3Prototypernas roll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6 En sammanfattande modell . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6.1Motivering av modellen . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6.2Preliminär begreppsmodell för prototypning . . . . . . . . 32
4 Empiri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1 Upplägg för intervjuerna . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.1Preliminär teoretisk modell . . . . . . . . . . . . . . . . . . . . . . 37
4.1.2Intervjuernas ställning i uppsatsen . . . . . . . . . . . . . . . . 37
4.1.3Urval av intervjupersoner . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.4Praktiskt genomförande . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.5Återgivningen av intervjuerna . . . . . . . . . . . . . . . . . . . . 38
4.2 Intervjuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.1Intervju med Lars Degerstedt . . . . . . . . . . . . . . . . . . . . 39
4.2.2Intervju med Arne Jönsson . . . . . . . . . . . . . . . . . . . . . . 47
4.2.3Intervju med T. Nilsson och A. Larsson . . . . . . . . . . . . 50
4.2.4Intervju med Mårten Herberthson . . . . . . . . . . . . . . . . 59
4.2.5Intervju med Tomas Volavka . . . . . . . . . . . . . . . . . . . . 65
4.2.6Intervju med Bo Olls . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.2.7Intervju med Karl-Göran Andersson . . . . . . . . . . . . . . 75
4.2.8Intervju med Michael Garrido . . . . . . . . . . . . . . . . . . . 82
4.2.9Intervju med Peter Grew . . . . . . . . . . . . . . . . . . . . . . . 88
4.3 Sammanfattning av empiri . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.3.1Sammanfattning av intervjuer inriktade på teori . . . . . 91
4.3.2Sammanfattning av intervjuer inriktade på praktisk
systemutveckling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.3.3Sammanfattning 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.2Vidareutveckling av den teoretiska modellen . . . . . . . . 99
5.2 Agil och traditionell systemutveckling . . . . . . . . . . . . . . . . 103
5.3 Prototyper och systemutveckling i praktiken . . . . . . . . . . . 105
5.3.1Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.3.2Grä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
10Länktips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
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
Där inget annat anges rör det sig om egna figurer. Tillstånd att använda fotografier har inhämtats i förekommande fall.
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 beteende 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 inklusive anteckningar under intervjun med Lars Degerstedt. . . . . . . 46
Figur 15. Den tredje iterationen av den teoretiska modellen. . . . . 100
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.
Foto: Bo Olls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
1
Inledning
Detta kapitel beskriver uppsatsens bakgrund, syfte och frågeställningar.
1.1
Bakgrund
Under 1980-talet var prototypning ett område som drog mycket intresse 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 utvecklingen 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ändargränssnitt.
Det handlar också om vilka tekniska möjligheter som står till förfogande. Jag har själv varit med om webbens utveckling från primitiva 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 kunskapsprojektering enligt Goldkuhls Kunskapande (1998).
1.2
Syfte
Syftet med denna studie är att bidra till en ökad förståelse av prototyper och prototypning. Särskild vikt läggs vid prototypning sedd i
– 1 –
kontexten av systemutvecklingsprojekt, och hur prototypning eventuellt 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 utvecklingsarbete i stort. Detta utgör en sida av prototypens omgivning.
Ofta finns en annan sida, med användare, beställare och övriga intressenter. 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 systemutvecklarens perspektiv. Att även bearbeta användarperspektivet utförligt
– 2 –
systemutvecklare
utvecklingsmodell
verktyg
prototyp
övriga intressenter
beställare
användare
Figur 1. Avgränsning av vad denna uppsats behandlar.
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. Ytterligare 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 systemutveckling 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.
– 3 –
1.7
Referenshantering
Referenshanteringen följer i stort sett den «Guide till Harvardsystemet» 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 fotnoter.
1.8
Disposition
Uppsatsen är indelad i delar som följer på varandra i en logisk ordning:
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. Empirikapitlet 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 intervjumaterialet är mångfasetterat och rikligt. För att kunna göra materialet
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 begrepp 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.
– 4 –
2
Metod
Detta kapitel presenterar förförståelse, kunskapsbehov och de metodval 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änvisas 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 prototypning 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 personer 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.
– 5 –
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 programmeringssprå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 prototypning som innehåller värdefull kunskap. Bland annat tar den upp
begreppet prototypning i samband med experimentell systemutveckling.
I sin bok The Object Primer (2004) lägger författaren Scott W. Ambler fram en lättviktsmetod för objektorienterad systemutveckling.
Den har även några intressanta sidor om prototypning av användargränssnitt.
Artikeln What do Prototypes Prototype? (Houde & Hill 1997) visar på
ett sätt att kategorisera prototyper utifrån vilka aspekter av ett system 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 tillsammans (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 systemutvecklingsarbetet.
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.
– 6 –
2.4 Kunskapsbehov
Hur relaterar viktiga begrepp som hör samman med prototyputveckling tillvarandra? Exempel på sådana begrepp är it-system, systemutveckling, 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ättviktsperspektiv 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ättre 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
Relation mellan begrepp
Kunskapskaraktär
Kategoriell och klassificerande kunskap
Systemutvecklingsperspektiv Kategoriell och klassificerande kunskap
Dagens systemutveckling
Deskriptiv kunskap, förståelseinriktad 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 strukturering 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.
– 7 –
Den normativa kunskap som studien syftar till handlar om hur prototyper och prototypning passar in i olika situationer under systemutveckling.
2.5 Kunskapsstrategi
När det gäller begrepp och systemutvecklingsperspektiv är denna
studie i första hand begreppsutvecklande och klassificerande. I undersö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å dialogutvecklande 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 verksamma 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 mindre 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.
– 8 –
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 erfarenheter 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 betydelse 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 prototypning. 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 intervjupersonerna kan ställa frågor tillbaka till intervjuaren vid oklarheter, 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 Lundahl & 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öjlighet 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.
– 9 –
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ättningen var här att få 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örankrad 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.)
– 10 –
3
Teori
För att skapa en förståelse av prototypers användning i systemutveckling 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 systemutveckling 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 likabetydande grek. prato´typos), originalmodell, som
följande former baseras på. Inom industriell produktutveckling avses försöksmodell som är riktig i funktion,
konstruktion och utseende men inte i tillverkningsmetod. (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 «design» ska tolkas i vid bemärkelse och omfatta såväl formgivning som
– 11 –
konstruktion. Att ha en så pass bred definition av prototypbegreppet
kan dock bidra till missförstånd. Computer Swedens reporter Anders 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åttbo 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 demonstration. På mässor och pressvisningar får man ofta se modeller av kommande produkter. De är snygga och prydliga, 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öreteelse 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. (Gulliksen & Göransson 2002, s. 242)
Med en bakgrund inom mjukvaruutvecklingsprojekt har några forskare 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 experimenting with them. (Lichter et al. 2004, s. 222)
– 12 –
3.1.2 Systemutveckling
I Nationalencyklopedin beskriver Nilsson (2007) inledningsvis systemutveckling 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ättningarna, 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. (Andersen 1994)
Inom användarcentrerad systemutveckling ser man gärna utvecklingen ur perspektivet mentala modeller. Man har då att göra med
designerns och användarens respektive konceptuella modell av systemet. Ett viktigt problem är här hur designern uttrycker sig angående
systemet så att designerns och användarens mentala modeller stämmer överens med varandra. Användarens modell skapas inte direkt
från designerns modell, utan genom olika slags interaktion. (Gulliksen & Göransson 2002)
3.1.3 Design och designer
Design och designer har något skilda betydelser i svenska och engelska, 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 konstruera en dator». Svenska «designa» är vanligen syno– 13 –
nymt med «formge», alltså mer estetiskt än ingenjörsmässigt. – I systemutveckling används «design» om den
fas när man «gör upp ritningarna» till systemet, alltså fasen 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 skrivande av instruktioner för en dators arbete. (Nationalencyklopedin 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 samma sak som att programmera. När programmering görs
med ingenjörsmässiga metoder talar man om programutveckling eller systemutveckling. (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.
– 14 –
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å övergripande 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 Britannica 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 undervisning 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. (Eastman 2003)
På 1950-talet togs en modell för problemlösning fram av matematikern 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, Mumford (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.
– 15 –
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):
Figur 2. Förhållandet mellan prototyp och utvecklare. (Schneider
1996, s. 523)
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 behö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ärmare på olika dimensioner och synsätt som man använder för att
förstå prototyper.
– 16 –
3.2.1 Användningssätt
Prototyper kan användas i olika faser av ett systemutvecklingsprojekt, 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 information om det framtida systemet i en kravspecifikation. Finns det
särskilda tekniska svårigheter med ett system kan man göra en prototyp 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 varianten 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 prototypen 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 behövs ett särskilt steg för dokumentation av vad prototypen visat när
– 17 –
Figur 3. En utvecklingsmodell för prototypning. (Andersen 1994, s.
412)
– 18 –
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 prototyp 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 skapar 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 & Hamilton 2002)
Jämför med hi-fi (förkortning av «high fidelity») när det gäller stereoanläggningar, där det innebär en hög grad av trohet mot originalljudet.
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ändargrä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)
– 19 –
Vertikal
Horisontell
Scenario
Användargränssnitt
Användargränssnitt
Användargränssnitt
Logik
Logik
Logik
Data
Data
Data
Figur 4. Tre olika slags prototyper: vertikal, horisontell eller i form av
ett scenario. (Figur efter Gulliksen & Göransson 2002, s. 245)
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 underlätta parallell utveckling av olika delar av ett system. Till exempel
kan man skapa en prototyp av datalagret som sett från systemets övriga delar är ett fungerande datalager med komplett gränssnitt, men
som i själva verket bara svarar med data som lagts in fast i programkoden. (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 implementationen av något. Här handlar det mer om att prova olika lösningar och
skapa ett system med hög användbarhet. (Ibid.)
– 20 –
Role
Integration
Implementation
Look and feel
Figur 5. Tre olika dimensioner för prototyper: roll, utseende och beteende samt implementation. (Figur efter Houde & Hill 1997, s. 6)
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. Prototyper av utseende och beteende används för att utvärdera de sinnesintryck 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 klickbara prototyper som uppvisar ett beteende. Implementationsprototyper 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 implementationsprototyper för att undersöka om detta är genomförbart.
(Se ibid.)
– 21 –
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 established 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 -modeller.
Jag tar upp vattenfallsmodellen som ett exempel på en traditionell
strategi inom systemutveckling, som kontrast till agil utveckling. Citatet 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öljande:
specifikation,
analys,
konstruktion,
provning. (Wiktorin 2003)
Denna fasindelning är mycket vanlig och innebär en naturlig ordningsföljd mellan momenten, som fått beteckningen vattenfallsmodellen. 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 visar sig. Det senare är det gängse arbetssättet idag. (Wiktorin 2003)
En mer omfattande variant av vattenfallsmodellen är livscykelmodellen (se Figur 6). Viktiga punkter i detta synsätt är att användarna
– 22 –
Livscykel
Systemutveckling
Systemering
Förändringsanalys
Analys
Val
da
utv
e
Utformning
Realisering
ImpleFörvalt- Avveckmentering ning och
ling
drift
Inf
Fär
Rea
ör t
dig
lise
spe
t
info
r
info
bar
cifi
rm
ckl
kat
t in
r
m
atio
ing
ion
for
atio
såt
nss
m
n
a
gär
ssy
yst
tio
ste
der
em
nss
m
yst
em
Kra
v
Figur 6. Livscykelmodellen. (Figur efter Andersen 1994, s. 48)
ska analysera sig fram till sina önskemål, och att detta ska göras innan 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äremot 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 angreppssätt med en gemensam kärna av värden som uttrycks i det agila manifestet:
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)
– 23 –
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 utsträckning som det finns oklarheter kring krav eller teknik – och det
brukar det finnas gott om – ökar projektets komplexitet, och ett annat 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 bestämd tid, då utvecklarna får arbeta i fred. En enda person, exempelvis 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 dokument 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 dagligen genom hela projektet. (Beck et al 2001b)
3.3.3 Användarcentrerad systemdesign
Användarcentrerad systemdesign fokuserar på användare och användbarhet under hela utvecklingsprocessen. Systemet utvecklas
evolutionärt med den typ av iterationer som beskrivs i figur 7. Prototyper används tidigt i projektet och under hela dess förlopp. Målet är
– 24 –
Användarfokus, mätbar användbarhet och iterationer
Återkoppling
med förslag till
förändringar
Analys av användarna,
arbetsuppgifter och
användningssammanhang
Utvärdering med
mätningar mot
användbarhetsmål
Designförslag med
prototyper – i sig en iterativ
process som beskriver det
kreativa arbetets natur
Figur 7. Grundelementen i en iterativ användarcentrerad process.
(Figur efter Gulliksen & Göransson 2002, s. 109)
att visualisera och utvärdera designlösningar tillsammans med slutanvändarna. (Gulliksen & Göransson 2002)
Inom användarcentrerad systemdesign rekommenderas att man börjar med prototyper i form av enkla pappersskisser och konceptuell
design på hög nivå. Man lägger stor vikt vid att designförslagen utvä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ändarna 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 specifikationer, dokumentation av olika slag samt programkod. Med detta
– 25 –
tänkesätt är systemutvecklarens uppgift främst att producera dessa
olika artefakter. En person som lagt fram ett alternativ till detta synsätt på sådana frågeställningar är dansken Peter Naur, en förgrundsfigur inom dansk datalogi.
Naurs forskning har sin bakgrund i svårigheten att förklara vissa problem utifrån det Naur kallar för ett produktionsperspektiv på programutveckling; 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ället att använda ordet programutveckling när jag refererar Naur, eftersom 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ämligen att man modifierar program. (Naur 1985)
tt program behöver modifieras är alltså inte någon «extra» aktivitet
A
utanför programutvecklingen, utan ingår som en normal del i denna.
Därmed är det också tveksamt om man någonsin kan se programutvecklingsprojekt 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 principer för programutveckling. (Naur 1985)
Utifrån ett produktionsperspektiv på programutveckling är det naturligt 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
– 26 –
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 textproduktion – att datorprogram redigeras som en form av texter inbjuder 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örfattaren 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 boken. 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 uppfyller sitt syfte lika väl. Upprepas detta flera 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 systemutveckling. 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
– 27 –
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 varandra. 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 befintliga 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 mjukvaruutveckling:
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 mjukvara. 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ändningssituationer. 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 underlä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 experimentera 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 systemutveckling. (Ibid.)
– 28 –
3.5 Systemutveckling och prototyper
3.5.1 Prototypning i verksamhetsutveckling
Prototyper kan användas i olika skeden av en systemutvecklingsprocess. Dessutom uppkommer frågan om hur systemutvecklingsprocessen relaterar till verksamhetsutvecklingsprocessen, och vad prototyper har för roll i sammanhanget.
Traditionellt sett är systemutvecklingsprocessen och verksamhetsutvecklingsprocessen åtskilda företeelser, och prototypningen saknar
då samband med verksamhetsutvecklingsprocessen (Gulliksen &
Göransson 2002). Se figur 8.
Återkoppling?
Verksamhetsutvecklingsprocess
Systemutvecklingsprocess
Prototyping
Figur 8. Relationen mellan systemutveckling och utvecklingen av
verksamhetsprocesser i verkliga livet. (Figur efter Gulliksen & Göransson 2002, s. 299)
När systemutvecklingen leder till mer konkreta resultat som prototyper ä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
Återkoppling?
Verksamhetsutvecklingsprocess
Systemutvecklingsprocess
Prototyping
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 –
kraven med hjälp av prototyper, vilket förbättrar möjligheterna att
utveckla ett system som passar verksamheten. (Gulliksen & Göransson 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 prototypning genom hela utvecklingsprocesserna, som därmed knyts närmare
till varandra. (Gulliksen & Göransson 2002) Se figur 10.
Verksamhetsutvecklingsprocess
Systemutvecklingsprocess
Prototyping
Figur 10. Tidig och kontinuerlig prototypning får produkten att
«växa» till. (Figur efter Gulliksen & Göransson 2002, s. 301)
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öransson 2002 samt kapitel 3.1.1).
– 30 –
3.5.3 Prototypernas roll
Det som tidigare sades om utforskande och experimentella prototyper 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 intressenter ställer på ett system till stor del bygger på deras erfarenheter. 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 system med inslag som de saknar erfarenhet av. Här kan man på motsvarande sätt skapa erfarenheter genom att arbeta med prototypning,
och på så vis minska risken att designbeslut fattas på felaktiga grunder.
En annan författare som är inne på ett liknande spår är Kurt Schneider, 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 kunskaper på nästa nivå.
– 31 –
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 prototypbegreppet utifrån de teorier som jag har tagit upp. Målsättningen ä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 områ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 problemrymd och lösningsrymd, som vi stiftat bekantskap med tidigare.
Utifrån detta får vi följande sex begrepp som en ram för systemutvecklingsprojekt:
Tabell 2: Ram för systemutvecklingsprojekt
teori
praktik
problem
krav
lösning
system
Genom att även ta hänsyn till att det finns en ordningsföljd i förloppet vid systemutveckling får vi följande första utkast till en modell
för prototyper i systemutveckling (se figur 11):
Att cirkeln sluter sig kan symbolisera två olika saker:
– 32 –
problem
krav
teorier
praktik
lösning
system
Figur 11. Utkast till modell för prototyper i systemutveckling.
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 formuleras 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 utforskar 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: begreppet prototyp. Utifrån det som sagts i detta kapitel vill jag fram– 33 –
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 modellen samtidigt.
Ofta är det en person som tar fram prototypen, och någon, till exempel 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
teorier
designer
prototyp
användare
krav
praktik
system
Figur 12. Preliminär modell för prototyper i systemutveckling.
– 34 –
Denna preliminära modell följde med in i arbetet med empirin. Efter att ha gjort två inledande intervjuer med fokus på teorin (se nästa
kapitel) försökte jag göra modellen tydligare genom att förändra begreppen 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 teoretiska modell som jag hade som grund för resterande intervjuer (se
nästa kapitel).
– 35 –
problemrymd
begreppsstrukturer
lösningsrymd
designer
utvecklare
prototyp(ning)
användare
intressent
informationsbehov
verksamhet
it-system
Figur 13. Den andra iterationen av begreppsmodellen.
– 36 –
4
Empiri
Kapitlet presenterar utdrag ur intervjuer samt kortare sammanfattningar 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 detaljer (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 produktutveckling 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 perioden.
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.
– 37 –
I de följande intervjuerna har jag främst använt modellen som ett
stöd för mig själv. Med hjälp av den strukturerade jag samtalen under
genomförandet. Beroende på situationen tids- och innehållsmässigt
har jag även tagit upp aspekter av modellen mer direkt mot slutet av
intervjuerna.
Då syftet med studien snarare är att se på olika angreppssätt för prototypning som används idag än att jämföra företag har betoningen
varit på den intervjuades egna erfarenheter, inte på företagets «policy». Detta för att undvika att intervjupersonen återger något han
hört eller läst istället för sina egna erfarenheter. Man kan därmed
inte utan vidare dra slutsatser om företagen utifrån materialet.
Intervjun med två personer från Responsive Development Technologies AB intar en särställning. De sysslar inte direkt med systemutveckling, utan de beskriver sin verksamhet enligt följande:
Våra kunder utvecklar system och produkter baserade på
programvara. Vi utvecklar deras utveckling! (Responsive
2007)
Det som gjorde Responsive intressanta för mig var deras inriktning
på agila metoder. Företaget är medlem i organisationer som Agile
Alliance, Agile Project Leadership Network och DSDM Consortium. (Responsive 2007)
Förutom att intervjua systemutvecklare har jag även intervjuat en
konstnär med erfarenhet av utsmyckning i offentliga miljöer. Tanken
med detta är att ge möjligheter att se om och hur liknande fenomen
uppträder inom konstområdet, och därmed kunna få andra perspektiv och bilder med sig in i arbetet med frågeställningarna inom itområdet.
Resterande intervjuer är gjorda med verksamma systemutvecklare,
med syftet att ta reda på hur de arbetar med och ser på prototyper
och prototypning.
Intervjuernas längd varierade från 45 minuter till närmare två timmar. Samtliga intervjuer genomfördes under våren 2007.
4.1.5 Återgivningen av intervjuerna
Intervjuerna återges i form av utdrag. Dessa utdrag har endast redigerats för att ge en läsbar text och minskat antal upprepningar. Detta
– 38 –
är vad Svenska språknämnden (2000) kallar för redigerad direkt anföring.
Utdragen har gjorts med tanke på att i någorlunda koncentrerad
form samla uttalanden som är av intresse för denna studies frågeställningar. Mellanrubrikerna är insatta i efterhand för att underlätta
navigeringen i texterna. Innehållet i intervjuerna skiljer sig mycket,
och mellanrubrikerna skiljer sig därmed också mycket.
Personerna i intervjusituationen särskiljs med hjälp av sina initialer.
När vi pekat på någon skiss eller modell under intervjun har jag lagt
till kommentarer inom hakparenteser för att göra texten begriplig
för läsaren.
Att endast utdrag ur intervjuerna återges inom ramen för uppsatsen
har flera skäl. Bland annat skulle uppsatsens omfång nästan fördubblas om man lägger till intervjuerna i oavkortat skick! Detta skulle
däremot inte tillföra någon betydande mängd information av intresse
för läsaren, och därmed togs intervjuerna inte med i sin helhet. Det
är också svårt att motivera den stora arbetsinsatsen som skulle krävas
för att bearbeta hela materialet så att det ger en stilistiskt godtagbar
text.
4.2 Intervjuer
4.2.1 Intervju med Lars Degerstedt
Intervjun genomfördes 29 mars på Linköpings universitet. Lars Degerstedt har doktorerat i datavetenskap och undervisar och forskar
vid Institutionen för datavetenskap, Linköpings universitet. Till hösten är han med och startar det nya kandidatprogrammet i Innovativ
programmering vid Linköpings universitet. Nedan följer utdrag ur
intervjun.
Problemrymd och lösningsrymd
LD: Där finns det ju en fundamental matematisk skillnad
mellan problemrymden och lösningsrymden. Och det
här det stora kreativa steget sker. Det är här det spännande sker när du går från problem till lösning. Och här
finns ingen automatik alls. Det är här människan gör sin
stora arbetsinsats, då man bygger system. Samtidigt som
man då bygger upp förståelse kring problemet så hittar
– 39 –
man också en lösning. Eller ibland är det så att man också kan förstå problemet i förväg och sen hitta en lösning
efteråt. Det är ju lite olika det där, om det är stora och
komplicerade problem, så måste man oftast upptäcka
lösningen och problemet ihop. Det är väl en del av Naurs
tanke, att man när man programmerar ett system så förstår man också problemet man utgick från.
Att utesluta lösningar
LD: I och med att du utesluter en lösning så har du oftast lärt dig något mer om problemen, något som du inte
hade tänkt på. Du hade antagligen en problembeskrivning som inte tog upp … något man måste ta hänsyn till.
Därför var lösningen fel. När jag har insett det, då kan jag
ta med mig den där erfarenheten tillbaks till problembeskrivningen och säga att allt jag har sagt i problembeskrivningen var rätt, men det var en observation som var
kritisk, och som jag inte hade fått med tidigare.
Vattenfallsmodellen
LD: Det är många idag som jobbar med vattenfallsmodellen på vissa sätt. Man gör en kravspec först och sen
implementerar man. Det ställer krav på den som ska använda den här processen att man måste lära sig att ställa
kraven i förväg, innan man börjar realisera, det vill säga
att det är svårare i någon mening. Och det löser man oftast på företag genom att man har Senior Developers som
har jobbat med det här i 20 år och en sådan person kan
faktiskt ge en kravspec på förhand för så duktig är han
på just den här typen av system. För han har gjort 200
sådana system, och de ser ungefär likadana ut allihop.
Men när det blir mer explorativt, när det explorativa och
innovativa inslaget ökar, då blir det svårare att jobba vattenfallsmässigt.
Iterativt arbete kontra vattenfallsmodellen
LD: Att iterera mycket kostar tid. Det är dyrt att iterera.
Det är väldigt effektivt att jobba enligt vattenfallsmodellen, om man bara gör rätt. Gör man fel blir det istället
– 40 –
oftast väldigt dyrt. Det betyder i princip att projektet havererar, och du måste börja om igen. Medan en iterativ
metod, med kortare iterationer, är mycket mer robust.
Men den har en overhead i det här itererandet. Till viss
del gör man om saker för varje varv. Med vattenfallsmodellen hade jag gjort det en gång för alla. Man lever i det
gamla industriella tänkandet tror jag, det ska vara effektivt. Men sen blir kvaliteten sämre ibland.
Prototyper
LD: Det finns olika synsätt. Frågar du Alan Cooper skulle
han sätta prototypen väldigt nära det här med krav och
problem. Säger du prototyp till en mer programmerarorienterad person från den agila metodiken, då tror jag
att man hellre skulle säga att prototypen är den första lösningen. Prototypen är skissen på lösningen och har ingenting med problemet att göra. Problemet är kravspecen,
det är en kravinsamling. Men när det går till prototyp,
det är just när vi tar steget över från problem till lösning.
Och här vi får vi också problem för att man diskuterar
lite förbi varandra.
Kompetens
LD: En dimension som jag tycker är viktig i Naurs synsätt är kompetens, det är en väldigt viktig aspekt. Och
då menar jag kompetensen hos de som ska göra det här
systemet, kompetensen hos de som ska bygga systemet
i någon mening, antingen som en övergripande designer eller som en konkret programmerare och så vidare.
Alltså hur ser ditt team ut, vad har du för team? Du har
ett team och nu ska du få teamet att fungera. Och det här
är på något sätt ett självorganiserande team. Och då kan
du inte komma och smaska på och säga att nu ska vi göra
prototyper som är problembaserade här, om du har mest
Perlprogrammerare. För de vill ha en lösningsorienterad
prototyp, de vill ha nånting som hjälper dem.
– 41 –
Prototyper inom agil metodik
LD: Finns det överhuvudtaget prototyper i agil metodik?
Det är mer tveksamt tycker jag om man kan tala om det.
Agilt tror jag skulle säga så här: vi visade dem det riktiga
systemet direkt, det är så här det ser ut idag. Vi håller
på med ett forskningsnära projekt tillsammans med ett
företag. Då började jag prata prototyp med dem, och då
slår de ju bakut allihop. De vill inte ha någon prototyp.
De har inte råd att hålla på med prototyper. De vill ha en
färdig produkt på en gång. Allting vi gör måste gå rakt
in i en färdig produkt, och det tror jag är väldigt vanligt.
Det är alltså få förunnat att få hålla på med prototyper
när man jobbar i företag som jobbar ganska agilt. Så det
är därför man säger att den agila metodiken är som gjord
för småföretag, till stor del. Företag som har en stor organisation, som Ericsson, kan ju ha en hel avdelning med
HCI-experter som gör prototyper. Men har företaget 20
personer totalt så har du inte råd att ha en person som
håller på att göra prototyper på saker och ting.
LD: Man kan också tänka sig att frågan är om ska man
ha en prototyp eller inte. Vad har man råd med, om man
nu ser det som en kostnad. Allting kostar ju. Men du får
alltid någonting tillbaks också. Om man säger att man
lär sig genom att bygga saker, ja då skulle man kunna
använda det som ett argument för att det är ett bra sätt att
lära sig, att lära sig genom att experimentera.
LD: Man har en fas som är innan lösningen är tillräckligt
bra. Innan man har en lösning, så har man en gråzon
som är att man håller på att hitta lösningen. Det är den
kreativa processen, och där skulle man möjligen kunna
säga att man gör en viss nivå av prototyping. Men man
skulle kunna kalla det något annat, man skulle också
bara kunna säga att det är det här som är programmering. Det är ju problemlösning. Men prototyping skulle
kunna vara ett bra ord när den är mer explorativ.
– 42 –
Agil metodik, prototypning och theory building
LD: Vad det handlar om, som jag ser det, är att skapa ett
självlärande team, som hela tiden kompetensutvecklas
under tiden som man jobbar. Och det är det som är det
centrala. Det är nästan viktigare än det man gör, för att
då kan man se det som en konsekvens. Blir du riktigt bra
på nånting, då gör du bra saker. Så det viktigaste det är att
hålla folk bra på det de gör.
LD: Om din metod inte är rolig så har du ett problem.
Då kommer den inte funka i praktiken, i det moderna
industriella klimatet. Det kanske funkade en gång i tiden
då man gick på pliktkänsla, men idag är det få som kan
jobba baserat på plikt. Därför är innovativitet så viktigt.
Så där är det ett skifte i perspektiv på vad som är viktigt.
Därför måste det vara roligt, för när det är roligt då gör vi
kreativa saker. Är det inte roligt så är vi inte kreativa.
LD: Och där tycker jag Peter Naur har den här insikten
om att när man bygger ett system så händer det något
inte bara i systemet, det händer något inte bara i dokumentationen – alltså dokumentationen står inte för sig
själv och kommer aldrig att göra det. Det som har hänt
har hänt inne i huvudet på dem som har byggt systemet.
Det är det fundamentala som har hänt. De här personerna har byggt upp en teori om hur det här problemet och
de här lösningen fungerar ihop. Och den teorin har vi i
huvudet, och så finns den då avbildad nere i koden, men
bara partiellt. Troligen så har vi en massa insikter som
inte finns dokumenterade någonstans för att det hinner
man inte så att säga, och det kanske inte skulle gå heller
att dokumentera på den nivån. Det skulle också bli väldigt oläsligt, det skulle bli väldigt tjocka böcker. Så där
har man då människan istället. Så det blir ju ett perspektiv på, om man tar in prototyping i bilden då, om man
har den synen på vad det är vi ska stödja. Är prototypen
bra eller inte? Ja, det är ju bra om det stödjer att man lär
sig, alltså att man får bra theory buildning. Och är det
theory building-stödjande då får du antagligen bra cost-
– 43 –
benefit-balans där. Men om det inte är theory building
på ett bra sätt så är det bortkastad tid.
Prototyper och kompetensutveckling
LD: Du måste jobba med de verktyg som du sen ska använda i projektet. Det ska vara relevanta saker, så vi ska
till exempel använda Lucene, en sökmotor för Java, i det
här projektet. Då skulle jag kunna ha som ett prototypprojekt: gör något häpnadsväckande med Lucene! Det är
jättekul och så gör jag min favorit, hemsida, website, någonting som inte alls har med projektet att göra, men jag
blir en hejare på Lucene. Sen tar jag den kompetensen
och så flyttar jag över den till det här projektet, och helt
plötsligt blir det superbra på en gång i det riktiga projektet. Där finns det ju en spännande koppling mellan
prototyping och kompetensutveckling tycker jag.
Detaljerade gränssnittsprototyper och kravspecar som hinder
LD: De som får ett sådant material som utgångspunkt får
en väldigt tråkig uppgift. Och i den här dubbla meningen
som Naur säger, dels att dokumentation kommunicerar
dåligt, den kommunicerar men det är oftast partiellt. Du
får oftast frågetecken, vad menar de med det här ordet,
vad menar de med den här meningen? Eller en bild – vad
menar de med den här bilden? Hela tiden kommer du att
stöta på detta, och även om man går till källan så kanske
det visar sig att «Aha, det hade jag inte tänkt på!» Och då
är det ju nån som har gett sig in och tyckt saker utan att
ge hela svaret. Och sen ska du ta över som sagt. … Det
är en väldigt bra fråga egentligen, alltså både som hinder
och möjlighet. Också det om man gör prototyper som
inte passar, och får man då en prototyp, någonting som
någon annan tyckte att det var jättekul att göra och fick
leva ut sin konstnärliga sida, någon som gillar att måla
och så vidare. Och så ger du den till en Perlprogrammerare. Det är ju en förolämpning i två steg. Dels är det
tråkigt, dels är det som att säga «Hej, jag förstår inte dig.
Så jag förstår inte vad du behöver.» Det är det det signalerar. Det signalerar att den som har gjort prototypen har
– 44 –
ingen aning om vad den här programmeraren behöver
för att kunna utvecklas. Man har gett helt fel saker, och
det är ju väldigt vanligt i det här kriget, som man säger,
mellan utvecklingsavdelningen och andra avdelningar.
Agil och traditionell utveckling
LD: En skillnad mellan agilt och traditionellt är att i agila
företag är ju oftast alla programmerare. Man har alltså
bara en sorts människor, yrkesrollsmässigt. Så man har
en ganska rund kompetensprofil. Sen kan man ha olika
specialiteter, men man har ändå en kärna där alla delar
samma värden. Sen kan de välja olika inriktning på den
här programmerarkompetensen, men det är ett medvetet
val. Många andra har mer traditionella approacher; då
har man väldigt olika sorters människor, med olika kompetens, sub-kompetenser, så man har lång utbildning och
har specialiserat sig på något, och sedan ska de här människorna försöka samarbeta med varandra. Och då blir
det ett kommunikationsproblem. … Prototypa eller inte,
det kanske inte spelar någon roll hur bra prototyp du gör
för att de här människorna kommer alltid ha problem att
kommunicera med varandra för att de har för olika erfarenheter. Den ena kommer hela tiden ge postit-lappar
som lösningar, och den andra kommer att säga att jag vill
inte ha postit-lappar. Och sen kommer man inte vidare.
Prototyper och kostnader
LD: Kanske är det så att de som vill ha mycket prototyper
oftast är problemorienterade individer. Medan lösningsorienterade individer vill ha minimalt med prototyper.
… Den ena gillar det och vill dra ut modellerna och göra
komplicerade saker, för det kostar ingenting på papper.
Medan den som bygger sakerna, för den kostar varje sak
flera veckors arbete, så att varje sak som ska in i verksamheten avväger man väldigt noga. Är det värt att ta steget?
Ska vi verkligen göra en prototyp i det här projektet? Det
skulle vara en stor fråga för en lösningsorienterad individ då, medan för en problemorienterad individ så kan
det vara «ja, jag kan gärna göra en prototyp». … Frågan
– 45 –
kompetens
krea
problem
tiv process
teorier
?
prototype
dokument
?
designer
lösning
?
handling
prototyping
prototyp
användare
krav
praktik
system
stakeholder
intressent
Figur 14. Den ursprungliga versionen av begreppsmodellen inklusive
anteckningar under intervjun med Lars Degerstedt.
är då om det är så att det finns en tredje väg här så man
kan få med på något sätt att man inte har en prototyp i
traditionell mening. Men man gör en prototyping. Om
vi tar Highsmith med det innovativa synsättet på utveckling: Där kan man se att man ständigt experimenterar när
man utvecklar ett system. Och det skulle man ju kunna
kalla för prototyping, eller i alla fall något besläktat.
Experimentell utveckling
LD: Man kanske inte har något som heter prototyp egentligen, alltså det begreppet blir inte så centralt, utan efter den här experimentella fasen så får man ett, kanske
partiellt, men fungerande system. Och Highsmith säger
då att det viktiga är att metodiken stödjer experimentellt
arbete. Så i den meningen kan man ju säga att den agila
metodiken stödjer prototyping. Men däremot så använder man inte begreppet prototype så mycket. Han har
hoppat över det mellansteget.
– 46 –
LD: En annan intressant sak om man jobbar experimentellt är att man ju måste inse att man kan inte göra designer «up front» längre. Man vet inte vart projektet kommer att ta vägen. Det är dessutom så att man kan inte
lägga fasen i början ens, för att varje dag under projektets
gång kommer man att vara experimentell. Man börjar
experimentellt, man kommer att sluta experimentellt.
Men det som blir viktigt då, och där kopplar det lite till
lean production, det är att man måste ändå ha en förutsägbarhet i att processen måste generera bra saker. Det
får inte vara så att man misslyckas. Begreppet misslyckas
får inte finnas så att säga, utan det måste vara förutsägbart att den här processen kommer att spotta ur sig bra
saker i ett jämnt tempo. Men exakt vilka de här sakerna
är, det är det vi inte vet. Vi vet att vi har en bra process,
och det här det ska vara roligt, det ska vara kreativt och
så vidare.
4.2.2 Intervju med Arne Jönsson
Intervjun genomfördes 12 april på Linköpings universitet. Arne
Jönsson är professor vid Natural Language Processing Laboratory
vid Institutionen för datavetenskap, Linköpings universitet. Nedan
följer utdrag ur intervjun.
Prototyper som verktyg
AJ: Jag skulle mycket väl kunna tänka mig att designern/
utvecklaren tillsammans med intressenterna diskuterar
beställningen kring en prototyp. Jag tänker mig gärna
en lo-fi prototyp, en pappersprototypsliknande sak. Den
tror jag skulle kunna fungera som ett verktyg för beställningen. Jag ser prototypen väldigt mycket som ett
verktyg. När den blir hi-fi prototyp, det är svårt att säga
egentligen. När det gäller problemrymden och lösningsrymden, så handlar det ju någonstans om att förstå problemet. Och det menar jag att en prototyp skulle kunna
hjälpa till med. I min begreppsvärld så blir det då svårt
för sen övergår lo-fi prototypen till något annat, beroende på problemet blir det antingen till en hi-fi prototyp
– 47 –
eller, om man tänker agilt, till en första prototyp av det
som ska bli det fungerande systemet.
AJ: Prototypingen finns med som en väldigt väsentlig del
här i övergången från problem- till lösningsrymd. Och
här skulle jag nog vilja börja blanda in användare. … Jag
menar har du ett stort projekt med mycket folk och du
ska göra nånting väldigt stort och väldigt komplicerat, då
kan du mycket väl ha en designgrupp som börjar designa
beteendet och börjar designa en första hi-fi prototyp när
de har förstått problemrymden. Och sen så ska den hifi prototypen realiseras. Det är en syn på stora projekt
som jag har. Och det är en syn som har växt fram; den
går någonstans stick i stäv med en del av det där som
användbarhetsexperter pratar om att vi skulle vara med
tidigt i projektet, och inte komma in och rätta till felen i
efterhand.
Olika användningar av prototyper
AJ: Det är två syner, som beror på projektstorleken, tror
jag, och naturligtvis karaktären hos projektet. Säg att du
ska utveckla en interaktiv webbplats av avancerat slag.
Du kan köpa och sälja bilar, eller boka hotell eller något
sådant. Så du ska utveckla något ganska avancerat, som
går ut och söker i databaser. Du skulle misstänka att användarna har en väldigt stor betydelse i inledningsfasen
också. Så att man får så att säga designen av interaktionen. Så att man får en förståelse för de tjänster som man
vill använda. Så att man inte börjar att utveckla saker som
inte kommer till att användas, eller som inte är intressanta eller som har en annan prioritet. Och där tror jag
att användarna är inblandade. Men om du istället tänker
att du ska utveckla en växel för mobiltelefoni som ska
skötas av en operatör som ska kunna se hur hårt belastade masterna är och så vidare, då skulle jag kunna tänka
mig att man inte behöver ha användarnas aspekter med
lika tydligt, alltså de som ska köra systemet sen, utan då
måste beställarnas krav komma in lite tydligare, de som
begriper hur masterna kommunicerar med varandra och
allt sådant. … Och den kravspecen kan å andra sidan
– 48 –
växa fram tillsammans med intressenterna utifrån en
prototyp. Men användbarhetsaspekterna på prototypen
behöver inte vara lika väsentliga. Men för att beställaren
ska förstå sitt problem, vilket de inte säkert gör, då de kan
ha en vag bild av vad det hela går ut på, kan en prototyp
hjälpa till. Men inte en prototyp i syfte att förstå hur man
använder systemet, utan i syfte att förstå vilket problem
som finns när de ska designa systemet. … Det måste vara
ett skäl till att prototyper och prototyping blir besvärligt
som begrepp, att de används i så många olika typer av
projekt.
Problem med prototyper
AJ: En fallgrop skulle naturligtvis då kunna vara att man
fokuserar för mycket på de problem som för närvarande
ligger för handen, och inte ser till den helhet som man
skulle kunna ha. Om vi går in i någonting så skulle du
kunna riskera att ägna för mycket tid åt funktioner som
kanske inte ger störst genomslag på den slutliga produkten. … Och det kan ju också finnas en risk för att du missar funktioner, som du inte har tänkt på. Därför att det
inte finns en stor beställareundersökning.
Olika slags prototyper
AN: Det finns ju något man kallar implementationsprototyper. Det är två personer från Apple som har skrivit om
tre kategorier av prototyper i slutet på 90-talet. Man talar
även om designprototyper och funktionsprototyper.
AJ: Så funktionsprototyper skulle vara det som ligger
nära agil utveckling. Och designprototyp är det med lofi, hi-fi. Och sen så finns där alltså då implementationsprototyper.
Betatestning
AJ: Lite kritiskt menar man ju att man gör det för att man
inte vill betala för testningen. Men mot det kan man
säga att det är ju så komplext och diversifierat idag att
det skulle inte gå att fånga alla möjliga olika användare,
– 49 –
och alla möjliga olika maskinvaruplattformar. Det skulle
inte bara fördyra, det skulle nästintill vara omöjligt också
därför att det finns oändligt många användare och det
finns oändligt många sätt att konfigurera datorer på.
4.2.3 Intervju med T. Nilsson och A. Larsson
Intervjun genomfördes 17 april på Linköpings flygplatsrestaurang.
Bägge intervjupersonerna är verksamma inom Responsive Development Technologies AB, ett företag i Linköping. Thomas Nilsson är
CTO och Agile Mentor, med en bakgrund som civilingenjör i datateknik. Han har erfarenhet som utvecklare, systemarkitekt och ansvarig
för utvecklingsverktyg och metoder i ett stort antal projekt i många
olika företag. Andreas Larsson är CIO och Senior Agile Consultant.
Han har civilingenjörsexamen i datateknik. Andreas har arbetat med
utveckling och systemdesign i både produktmiljö och kundanpassningsprojekt, it-strategier, projektledning, utredningar/utvärderingar
av teknik och system. Nedan följer utdrag ur intervjun.
Prototypning eller inte
TN: En av de viktigaste aspekterna av utveckling är att
man får nånting, att man får nån nytta av den. Och en av
de saker som jag ömmar för är att man har täta cykler,
det vill säga att man har feedback mellan användare och
så. Så det kan man ju använda prototyper till: att så att
säga skaffa sig information om vad användarna tycker.
Min erfarenhet är att det är ofta så att prototyper får ett
liv för sig själva, där man lägger ner för mycket energi på
att bygga prototypen för att verifiera nåt som man nästan
kunde gjort i produkten, det riktiga systemet som man
sen levererar. Och mycket av de moderna utvecklingsmetoderna säger ju egentligen att ja, det är bättre att bygga
systemet och faktiskt få en konkret återkoppling på hur
det beter sig, än att göra en prototyp. Bara så där lite kort
så skulle väl jag kunna tycka att det är okej att göra prototyper men de måste vara mycket begränsade i insats. I
extremprogrammeringen pratar man ju om spikes, alltså
ett snabbskott, utväxt på …
AL: … ett testskott för att se om det här är en hållbar idé,
som man inte måste göra nån form av programmering
– 50 –
eller prototyputveckling för, man kanske bara ritar upp
nånting egentligen för att diskutera «är det här användbart eller inte».
Prototyparbete
TN: Och det kan väl jag också konstatera i ett antal projekt som jag har varit med i att när man tänker sig att
göra prototyper så fastnar fokus på prototypen istället för
på produkten. Det gäller ju när prototypen är så att säga
likadan som produkten man tänkte producera. Det finns
ju andra sätt att göra prototyper, till exempel matematiska
modeller eller så att säga andra typer av prototyper som
inte är likadana som produkten. Och pratar vi programvaruprodukter, applikationer, gör man då en applikation
som en prototyp så skulle jag nog säga att det är lite bortkastat, för att hårdra det. Däremot att vi har prototyper
för användargränssnittet, för att modellera upp det bara
på nåt sätt, i powerpoint eller vad som helst.
AL: Det kan ju vara så att utvecklingsteamet har två idéer
eller inriktningar på till exempel användargränssnittet:
endera kan vi gå den här vägen eller så kan vi gå den här
vägen. För att få en bra dialog kring det så behöver man
visa lite grand vilka fördelarna och nackdelarna är med
de olika idéerna. Då kan man ju ha prototyper. Men om
vi går tillbaks till ren systemfunktionalitet då, och inte
bara användargränssnittet utan prototyper av systemet
så kan man tänka sig i vissa lägen att man kan bygga en
prototyp. Ta bildbehandling som exempel, där kan man
utveckla en viss sorts algoritm i Matlab eller något annat
högnivåverktyg, där själva beräkningen eller själva idén
bakom det man ska bildbehandla fram går att göra ganska fort. Men den slutgiltiga implementationen måste
man sen sitta och optimera beroende på vilken processor man ska köra och så vidare. Algoritmdesignen kan
man då prototypa fram medan implementationen för det
som ska användas i till exempel en röntgenkamera eller
någonting sånt skulle kunna ta flera månader, innan man
kan implementera på den korrekta hårdvaran och så vidare. Det kan vara en typ av prototyparbete också.
– 51 –
Vad är en prototyp?
AL: Jag tror att det här vilken benämning man använder
och vad prototyp betyder är ganska domänberoende. Om
du pratar web-databasapplikationer, då kommer prototypsbegreppet bara att handla om användargränssnitt,
möjligtvis att man gör några HTML-saker bara för att inte
ha nån koppling till nåt riktigt system bakom sig. Om
du pratar prototyper i samband med att du tar fram radarsystem, eller en radar, en apparat som ska sitta i ett
flygplan, då kommer prototypen att vara den första apparat som fungerar men som inte är byggd för serieproduktion. Den är kanske lite för tung, den har för stort
kraftaggregat, och den är producerad på ett manuellt sätt
och inte på ett automatiserat sätt. Då kallar man det för
en prototyp. Det kanske finns prototyper som inte ens
får flyga omkring, utan bara får sitta i en simulerad omgivning, men som ändå har korrekta processorer, det är
korrekta interface och så vidare till omvärlden på den.
Där har du ju ett prototypbegrepp som skiljer sig ganska
mycket.
TN: Jag skulle vilja tänka mig prototyper som sådant man
gör bara för ett specifikt användningsområde, som inte
är rätlinjig till den riktiga användningen.
Förhållandet mellan prototyp och produkt
AL: Om man tänker sig att det här handlade om någonting, säg en såg, då kanske du kan visa hur den ser ut, du
kanske till och med kan känna hur den känns i handen,
men det går inte att såga med den. Då är det ingen som
kan sälja den som den ser ut. Men anledningen till att
kunden vill göra nånting som är mjukvarubaserat, det är
ju, du vet att det faktiskt fungerar, till stora delar. Det är
ju en egenskap hos mjukvara, som finns där. När du har
utvecklat nåt som fungerar så går det att använda direkt.
Det finns inte något produktionssteg, som vi ju har pratat om. Det räcker med att kopiera över det så går det att
använda det till just det det fungerar till just nu. Men en
såg som inte har vassa tänder, den går inte att använda.
– 52 –
Och generellt så är det här problemet, eller ett problem
och en möjlighet, något som man måste kunna hantera
när man gör produkter som innehåller mycket mjukvara;
möjligheten att använda nånting som inte är 100 % färdigt enligt någon viss spec eller enligt ett visst önskemål.
Det räcker med att du gör 30 % av den funktionaliteten
så är det fortfarande användbart. Var går gränsen mellan
vad som är prototyp och vad som är nånting som jag kan
använda fast inte till allt jag skulle vilja använda det till
egentligen? Mjukvaruprodukter har ju den egenskapen
att det finns ingen gräns där.
AL: Då kan det ju behövas att man har lite disciplin inom
ett företag som gör att man kan använda sig av prototyputveckling eller demonstratorer eller vad du vill kalla det
för, som då inte är produktfärdiga. För de mjukvaruprodukter eller mjukvarubaserade system eller produkter
som finns idag har två syften. Det ena är att de ska lösa en
uppgift, de ska funka för nånting, och så ska de i alla förekommande fall vara grund till fortsatt utveckling. Det
finns inget system som byggs idag som man inte tänker
bygga vidare på, eller vill ha möjligheten att bygga vidare
på. Och det är det som gör att det inte är okej att fulhacka
in nånting längre. För det är inte så att man jobbar fram
till den 19 maj och sen är det klart, utan vi jobbar fram
och sen så börjar du att använda dig av det, och kommer
med all säkerhet att fortsätta att göra mer funktioner och
bredda produkten, bygga vidare på den och så vidare. Så
om man inte gör produkter så att de är både funktionsdugliga och en bra bas för att bygga vidare på har du bara
löst halva ditt problem. Och där är det många som fastnar, som bara har gjort den ena delen. Det är alltid den
ena sidan av någon konstig anledning.
TN: Det är ingen fara om du säger att din konkurrent har
kommit med en produkt, så kommer du med en prototyp illa kvickt.
AL: Men sen är frågan, bara för att du har varit i deras
monter och sett på den, vet du då om att de har en produkt eller kan det vara så att de bara har en prototyp de
– 53 –
också? Mycket av det vi jobbar med handlar ju om att
man ska jobba på ett sånt sätt att man får fram prototyper
och produkter hand i hand. Att man har ett arbetssätt
för systemutvecklingen som ser till att man inte glömmer
bort det här, den kompletta produkten.
AN: Det finns ju det här att man inte fulhackar utan att
man bygger nånting bra men använder det för att visa
upp också längs vägen.
TN: Den modellen tror vi mest på. Det vill säga att man
faktiskt gör äkta produktutveckling i sitt produktspår
men man börjar inte sälja den förrän man fått upp tillräckligt mycket funktionalitet. För varje sånt litet steg är
så att säga färdigt ur produktperspektiv, eller produktfärdigt eller vad vi ska kalla det för. Och för varje sånt litet
funktionellt delsteg så kan man ju visa upp sig. …
AL: Om man ska jobba på det här sättet som vi tycker att
man borde jobba på, så utvecklar man funktion för funktion genom hela systemet. Om du har ett system som kan
exportera till olika filformat till exempel så tycker vi att
man ska lägga till ett filformat i taget, medan en säljare
som ska åka på en mässa kanske hellre vill kunna klicka
på knappen, exportera och så finns det sju filformat, och
så är det bara det ena som funkar, och eftersom han demonstrerar så vet han vilket han ska välja. Det finns ju
olika behov där också då.
TN: Men det kanske är mycket det det handlar om att om
man vill göra en prototyp så måste det på nåt sätt synas
att det är en prototyp. Så ser produkten förvillande lik ut
då kommer ju alla att lura sig, för då kommer de att säga
«ja men den finns ju där, det är väl bara att sälja nu». Om
man däremot har sju val men sex av dem är liksom utsuddade, eller nåt annat, en varningstriangel på dem eller
något sånt, då finns det ju ändå nåt att hålla i och säga «ja
men den här aspekten är inte färdigutvecklad». Det är
lite det som en tillverkningsprototyp gör. …
– 54 –
Gränssnitt som ser «färdiga» ut
TN: Ett intressant experiment vore ju helt enkelt ungefär
det som jag sa. Det vill säga man har en enkel switch, och
switchar om från XP-look till Windows 3.11 eller något
sånt, det är ju lite mera fyrkantigt, utan rundade hörn
och så, och liksom gadgets i övrigt av enklare sorten. Vad
skulle det få för psykologisk effekt på användarna?
AL: Jag tror nästan det skulle räcka med att man gjorde
det svart-vitt. Självklart, det här är inte på riktigt. Det
skulle man nog kunna använda, man skulle komma en
bit på vägen. … Som du ser på Windows XP innan du
ska stänga av till exempel, så tonar den över lite till grått.
Då ser man ju också att det här är någonting som är på
gång att hända. Det här är utanför normal användning.
Så det kanske inte fungerar definitivt så som det ska. Jag
har aldrig sett det användas i prototypsammanhang.
Dokumentation av återkoppling
AL: Och är det så att det finns krav som säger att den här
designen vill vi av någon viss anledning ha här, då är det
inte bara ett prestandabeslut utan då är det ju faktiskt då
ett krav på någonting. Och sen om, man brukar ju kalla
det för designbegränsningar, krav- och designbegränsningar, den här funktionen ska ni ha och vi vill att ni ska
göra det på det här sättet. Så när kunden har en åsikt om
att det ska göras på det här sättet, … att det ska fungera
på Windows XP för att det är det som används inom den
här branschen till exempel, eller Macintosh. … Så är det
ju så att en del av resultatet från prototyparbetet borde
komma in i kravbilden så som designbegränsningar, tror
jag. De som man är väldigt noga med att man inte får
råka plocka bort senare på det här sättet, men om du sen
byter ut en lista mot ett flervals-, alltså du byter en komponent, det har förmodligen liten betydelse. Men om du
kan göra drag and drop på en sak, det kan ha väldigt stor
betydelse för de som använder den.
TN: Jag tänkte på det här du sa om att dokumentera designbeslut på grund av prototyper. Det hänger väl egent– 55 –
ligen ihop med det som du anförde som är syftet med
en prototyp nämligen den här kunskapsinsamlingen. Så
man borde ju, om vi nu har diskuterat prototyper som
försteg till vår produkt ganska mycket här nu ett tag, så
det andra spåret är ju när man försöker fokusera på kunskapsinhämtningen. Och ett sätt att betrakta det är ju att
den typen av prototyper, vilket jag tycker är de riktiga
prototyperna, blir ett litet projekt. Det vill säga att man
gör det här för ett visst syfte, man genomför det, man gör
en analys och någon slutsats. Och där borde ju det här
finns på något sätt då. Att bara liksom slänga det där och
sen så gå vidare känns ju som att då har man slängt bort
ett helt miniprojekt. …
TN: Alltså de här prototyperna jag tror vi pratar om är till
för utforskning, inte för kunskapsinhämtning, vilket är
en av skillnaderna i syfte också. Okej, det är klart att det
är kunskap. Men det är ju någonting som vi inte visste.
Det fanns ingen som visste, ingen som har dokumenterat
hur den potentiella användaren tror att vår produkt betedde sig. Det visste vi inte.
TN: Det finns ju ett sätt att hantera det här och det är
att man ser till, till exempel om det är ett team som gör
gränssnitt och tar beslut där, och sen har du ett annat
team som ska bygga. Då har du en person som följer med
över, och åtminstone träffas ibland med de som ska utveckla det, för att det är så svårt att fånga det här i dokumentation. … Då gäller det ju att man har någon kvar
också ett år senare när man ska bygga vidare.
Spikes i eXtreme Programming
TN: Nej, just det. Men vad jag tänker på är just att om
man sitter i ett större projekt där man vet att vi behöver
veta hur våra användare beter sig, att då sätta igång fyra
människor som ska jobba med prototyper, för att ta reda
på det när vi inte ens vet vad vår produkt ska göra, det
blir liksom fel. Utan det måste vara att ja, vi har tänkt
ut att den här funktionen måste vi ha nu, fast vi vet inte
riktigt hur den ska vara designad, eller hur interaktionen
– 56 –
med användarna ska se ut, eller om de behöver de här
attributen eller inte. Då gör vi en prototyp för det. Och
då kan vi återmata precis det här in i vår design och i det
här steget. Och det är därför jag gillar XP:s modell med
spikes, för de utgår från att vi faktiskt skulle implementera en user story i vår produkt. I det syftet gör vi något
sådant för att ta reda på hur var det här då, gick det här?
AL: XP skiljer ju då på såna här spikes. Det är verkligen
throwaway-principen. … jämfört med att det är helt okej
att bygga en funktion i nästa iteration för systemet, för att
se om det här var något att ha. Det är också okej att göra,
men då gör man den på riktigt, då är det testfall som gäller. Då ska den releasas tillsammans med allt det andra,
dokumenteras tillsammans med det andra och så vidare.
Men det är helt ok att prova sig fram i produkten också,
medan då de här spikes-grejerna det är riktigt throwaway så att säga. Så där skiljer man ju ganska snyggt åt på
det som verkligen är det som man kallar för spike, de har
ett eget ord för det till och med.
Prototyper i DSDM
AL: DSDM pratar ju mer om prototyper faktiskt. De kommer ju från prototyping, alltså de har ju rekommenderat
prototyparbete mycket. De är på väg bort lite grand ifrån
det. De hade väl planer, alltså det var väl mycket prototyp
i början, eftersom det har hållit på ett bra tag med DSDM
så var ju prototyper ganska hett när de satte igång.
TN: De kommer ifrån RAD-miljön också då, från Rapid
Application Development.
AN: Jag har undrat över det för när jag har läst om DSDM
så får jag olika bilder, men det är sån utveckling som har
skett då att man tonar ner den sidan.
AL: Vi var på en konferens i London i höstas, och ordföranden i DSDM pratade lite där. Och han fick just frågan
om prototyper: det här med prototyper kändes 80-tal var
det någon som tyckte. DSDM är ganska tungt på prototyping i sin processbeskrivning. Då sa han just det att där
– 57 –
är det någonting som vi håller på att tona ner lite. Vi försöker arbeta med språket för att skilja kanske på prototyp
och att visa upp produkten tidigt. De hade väl hamnat i
det här problemet med vad som är en prototyp och vad
som är tidig återmatning. Och i deras fall hade det nästan
alltid handlat om tidig återmatning.
AL: Och sen just att det kommer från den tiden när det
här var väldigt hett. Då försökte man kanske applicera
det på lite fler ställen än vad man så här i efterhand finner
är lämpligt.
Kravhantering och utvecklingsmodell
AL: Att man designar för mycket i onödan för att du kanske får en massa krav, eller en massa behov som kunden
har. Sen sätter du dig och skriver use-cases i två år. Du
kanske jobbar med den här kravbilden för att designa,
arkitekturera ditt system så att det har allting som kunden har sagt. Det här kastar ju de ihop på tre veckor. Sen
sitter du i ett bra tag. Och sen så har du då designat ett
system som det kommer ta åtminstone ett år att bygga.
Och sen, när du kommer att mata tillbaks nånting, ja för
det första så är den informationen som de gav dig från
början inaktuell sen länge på många punkter, ogenomtänkt på många ställen, dåligt beskriven, dåligt förklarad
och så vidare. … Inkonsistent mot sig själv och så vidare.
Och visst, då kan vi ju stå där och skrika att ni fick vad ni
beställde, men då får vi inga fler uppdrag från den kunden. Eller också kan vi säga, kom hit och prata i några
dar om de här funktionerna som vi tillsammans kommer
överens om är de mest intressanta. Så pratar vi mycket
om dem och sen så implementerar vi de mest centrala
funktionerna och så visar vi dem. Så att man snurrar hela
den här rundan. Man snurrar inte bara här [lösningsrymd och problemrymd], utan det här ska med, och det
där ska med [behov och system]. … Om du bara gör det
här [lösningsrymd och problemrymd], då riskerar du att
du bygger en funktionstillväxt inkrementellt. Men du får
ingen feedback för du tar inte hand om anledningen till
att du ville göra den här funktionsstegen, det var att nå– 58 –
gon skulle titta på det och säga är det här bra eller är det
här dåligt. Gör du bara den här loopen [lösningsrymd
och problemrymd], då tappar du det.
4.2.4 Intervju med Mårten Herberthson
Intervjun genomfördes 17 april hos Lawson i Linköping. Mårten
Herberthson arbetar som domänarkitekt och projektarkitekt hos
Lawson. Nedan följer utdrag ur intervjun.
Prototypning och design
MH: Min erfarenhet av prototyper är den att jag upplever att den faktiska användningen av prototyper och
hur man kanske förväntas använda prototyper i utvecklingsarbetet inte riktigt stämmer överens. Ofta kan man
ju till exempel tänka att man först ska göra en design,
man kanske gör en prototyp som hjälper en att göra en
design eller validera designen och så vidare. Och sedan
kanske man till och med förväntas kasta en prototyp. …
Men min erfarenhet är mer att man gör inte en design, i
den bemärkelsen att man gör det på ett papper först. Det
kanske man gör väldigt schematiskt, så att man får en
mer konceptuell design, på ett väldigt övergripande plan.
Men så fort man kommer ner till detaljfrågor sätter man
sig helt enkelt ner och kodar en prototyp. Och det vävs
samman med designarbetet, så att designen och prototypen går parallellt.
MH: Angående det här med att kasta prototypen och börja om: Jag har varit med om det några enstaka gånger,
men då är det mer beroende på att man helt enkelt under
prototypfasen insett att man är helt fel ute. … Däremot
om man upplever att det här har funkat ganska bra, då
utvecklas prototypen helt enkelt till att bli den slutgiltiga
produkten.
Happy days
MH: Ofta är det så att om jag ansvarar för att ta fram
en ny produkt försöker jag göra det vi kallar ett happy
days-scenario. Det är en konstig term egentligen. Det är
– 59 –
Kruchten som för länge sedan var på besök här och lärde
oss hur man gör UML-diagram. Nu använder vi inte UMLdiagram så mycket, men en idé som han hade när det
gällde prototyping var väldig användbar tycker vi. Låt oss
säga att du ska ta fram en produkt där till exempel performance är det centrala. Då gör man en prototyp där det
första målet med prototypen är att få ett komplett flöde,
även om flödet har massor av brister. Den kanske inte
har felhantering, den har inte specialhantering för något
udda fall, utan bara det enklaste flödet som ändå är det
som applikationen oftast gör. Och det är det som kallas
happy days-scenario: Allt går bra, och det finns inget behov av felloggning. Det finns inget behov av sådana saker. Och tanken är då att man så snabbt som möjligt får
upp det här happy days-scenariot, att man så snabbt som
möjligt kan börja mäta på saker som ger den här designen tillräckligt bra performance. För det var det som var
det viktiga för mig i det fallet. Och man kan helt plötsligt
börja göra lite mer problematiserade tester, och vartefter
man då får mätvärden på det här kan man använda dessa
i arbetet. Om jag måste gör en omdesign någonstans, så
kan jag direkt få feedback, om den här omdesignen innebär att performance ändrades antingen negativt eller förbättrades.
MH: Ganska tidigt försöker vi göra en prototyp som, även
om det är väldigt tunt, går hela vägen igenom. Applikationen gör vad den ska. Målet med det är ju att så tidigt
som möjligt upptäcka allvarliga brister i sin design. Här
ser man ju också igen hur prototypandet och designandet vävs samman i någon mening. … Jag utvecklar program på serversidan. … Om man däremot arbetar mer
på klientsidan, då kan det ju finnas behov av att göra prototyper av lite andra skäl. Man kanske vill göra en prototyp för att visa för kunden hur det kommer att se ut.
Man kanske vill mäta användarinteraktioner och sådana
saker. … För mig handlar det mer om performance, skalbarhet, att koden löser funktionaliteten som den ska.
– 60 –
Designprocessen
MH: Jag har lärt mig av ren erfarenhet att om man sitter
för länge och designar på papper, så är det bortkastad tid,
för det visar sig alltid att när man väl börjar koda att det
kommer saker som man inte har tänkt på. Så det gäller
att designa på papper, när syftet med pappret är till exempel att skaffa sig en samsyn i projektet om vad det är
vi ska göra. Så att man måste ha en whiteboard eller ett
papper där man bollar idéer och får en gemensam bild av
det är det här vi vill göra. Men när alla är överens om vad
som ska göras, då är det bättre att börja koda och hitta
problem. Det kanske dyker upp specifika problem som
man går tillbaks till och börjar designa på papper. …
MH: Jag har ibland jobbat i projekt där man försöker följa
till exempel RUP-processen. Det sägs ju alltid när man
klagar på RUP, att RUP är helt konfigurerbart, att det är
fel på din konfiguration om du tycker att processen är
dålig. Men jag håller inte riktigt med, för att i alla fall
i den normala tolkningen av RUP har man olika roller
som gör olika saker. Jag har varit med i situationer där
jag har rollen som arkitekt eller designer i ett projekt, sedan så kanske vi har en nyanställd person där jag också
har ansvar för att vara hans mentor. Rent projektmässigt
är jag arkitekt kanske, och jag förväntas göra designer.
Sedan på ett helt annat plan så är jag dessutom mentor
för en person som jag ska försöka lära upp. Och då enligt
RUP så är det så att jag kanske ska göra en design, och
sen ska jag sätta den i näven på den här personen, och
han ska kanske implementera den. Men det strider mot
min fundamentala målsättning när jag är mentor. Om
jag gör allt tankearbete och sen sätter en färdig lösning
i näven på honom och han bara ska stansa ner det så att
säga, då kommer han inte att lära sig någonting. Så jag
anser att det är mycket så att varje individ så att säga får
hantera hela cykeln: här har vi ett problem, både designa
lösningen och implementera den. Hela den här cykeln
med att göra testkod och ta fram en design, det får han
då lösa för då kan jag få honom att utvecklas. Så att här
pågår det ju saker i olika skalor så att säga. Det finns en
– 61 –
liten sak, en större sak, och hela systemet kanske. Så att
arkitekten kanske mer ansvarar för designen av att hela
systemet hänger ihop, men inte designen ner på detaljnivå i varje läge.
AN: Det är ju en allmän fråga inom utveckling att det sitter en person och gör en väldigt detaljerad specifikation,
och sen lämnar över till någon annan som «stansar koden» så att säga. Det är ju ett upplägg som förespråkas.
MH: Ja, och jag är totalt emot det, därför att jag anser
att för personerna som sitter och bara kodar ser man ju
inte till att de utvecklas maximalt så att de är så nyttiga
som möjligt för företaget. Den enda situation där jag kan
tänka mig att det där är relevant, det är om man har en
outsourcingsituation med Indien till exempel. Man måste göra en väldigt exakt design och sen skicka till någon
som kodar. Men inte ens då tycker jag att det är bra för
att min erfarenhet, rätt eller fel, är trots allt att enda sättet
att få designen att bli korrekt, det är att göra en prototyp.
Så om jag har gjort en prototyp, då är frågan varför ska
jag skicka den till Indien, jag kan lika gärna göra klart det
sista själv. Enda skälet till att … man ska lägga ner väldigt
mycket tid på att designen ska bli korrekt innan man ska
börja koda, det är … frågan om hur dyrt det är att korrigera fel senare i processen. Jag förstår mycket väl att
om NASA skickar iväg en satellit som är svår att reparera i
efterhand så måste man tänka efter mycket i förväg. Men
när man tar fram mjukvara så kan man göra tester innan
man skeppar den till kund, och man kan till och med
rätta buggar efter leverans. Det påverkar lite grand vad
som är mest kostnadseffektivt så att säga.
MH: När jag leder ett projekt som arkitekt är jag väldigt
fokuserad på risker. Jag försöker alltid attackera det som
är störst risk först. Och då kommer man in på det här
med kostnaden för att göra en rättning. Låt säga att rättningen är att i user-interfacet så har vi felstavat ett ord,
det är relativt enkelt och relativt billigt att fixa. Men låt
säga att designen på servern är fel, vi valde en stateful
model istället för en stateless model, och helt plötsligt kan
– 62 –
vi inte skala ut till många samtidiga användare. Det är ju
en jättestor kostnad. Det krävs antagligen en total redesign. Så att det är ju en stor risk då. Om jag upplever att
det är en stor risk att skalbarheten inte blir tillräckligt
bra, då kommer jag genast börja mäta på det så tidigt
som möjligt. Så prototypen syftar då till att ta bort de här
stora sakerna, som blir väldigt, väldigt dyrt att korrigera
sedan.
MH: Vi har ju ständigt behovet av att alla våra applikationer måste gå att internationalisera. Det är ett ganska
komplext område. Det är komplext att förstå problembilden som vi har, och att se till att det fungerar. Men å
andra sidan, när man väl har tagit sig över den tröskeln,
då kan man gå ganska mycket på rutin. Man har en lösning som fungerar sedan tidigare och den kan man ta
med sig.
Utvärdering
AN: Brukar det vara så att det är nån annan som utvärderar ens prototyper, eller utvärderar man dem själv?
MH: Man kan väl säga att det är både och i den bemärkelsen att man utvärderar själv först … Och sedan går
det vidare till ens projektmedlemmar. Men det är nog
inte någon formell granskning. Ibland förekommer det
att vi gör en formell granskning, men då kan det vara ett
specifikt syfte med det. Vi har det inte som ett obligatoriskt steg, men det händer att vi gör det, men då beror
det ofta på att vi har ett specifikt behov, att det funnits ett
problem. … Vi har formella granskningssteg, fast det har
inte så mycket med prototyperna att göra, utan mer med
när produkten närmar sig leverans. Då är det ju formella
tester och det är acceptanstester av kunder och så vidare.
Men vi har inte formella sådana steg under själva prototypandet.
Dokumentation av prototypning och designval
MH: Vi dokumenterar vissa val, men skälet är kanske ibland så att säga lite mer tråkiga skäl än goda skäl. Om
– 63 –
vi står inför ett val, och till slut så har vi en lång tankeverksamhet kring det. Det kanske finns en grupp inom
organisationen som förespråkar det ena valet, en annan
grupp som förespråkar det andra valet. … Och sedan så
har man någon form av brainstorming omkring det här,
och någonstans så leder det fram till någon form av beslut: Vi går på det spåret. Då kan det rent av vara att man
gör så för att slippa trassel. För den här gruppen som inte
tyckte att beslutet var bra, de kommer hela tiden att ifrågasätta: «Varför gjorde ni det här valet?» Då är det av ren
erfarenhet bra att dokumentera hur man gjorde det där
valet. … Men annars har vi ganska lite dokumentation
… i och för sig, implementerade testfall är ju i någon
mening en form av dokumentation. Och sedan har vi ju
också ofta dokumentation på övergripande design för att
man kanske hamnar i olika möten, man måste ändå visa
en PowerPoint-presentation som förklarar vad som kommer att ske. Så på den nivån finns det ju alltid lite material. Sedan, ju närmare man kommer färdig produkt, desto
mer formell dokumentation uppstår. Det blir ju då dokumentation för hur man installerar det, hur konfigurerar
man, hur använder man det och sådana saker. Så att visst
dokumenterar vi, men man kan säga att ju tidigare man
är i cykeln, desto mindre formellt är det, och ju närmare
man kommer slutet desto mer formellt är det.
AN: Jag tänker på att det här är ju någon slags kunskapsutveckling, man utvecklar kunskap kring det man ska
bygga. Och risken blir ju då att man upptäcker någonting med en prototyp, och därför väljer man ett nytt spår.
Men om inte det är dokumenterat, då kan det ju hända
att man ännu längre fram börjar böka med det här och
tycker att så här borde man ha gjort. Och så gör man om
det från ett spår som du kanske varit inne på, men som
inte fungerade. – Man utvecklar kunskap i samband med
prototypandet, men tar man tillvara på den?
MH: Det där är ett problem. Jag vet ju i vår grupp till exempel, vi har ju individer som till exempel har varit med
om att driftsätta sådana här applikationsservrar hos kunden. Och nu när vi implementerar en ny, vi håller precis
– 64 –
på med en ny version av den här, så bland de möjliga lösningarna så plockar de rent automatiskt vissa lösningar
som de av erfarenhet vet fungerar ute hos kund. För att
de vet att den där lösningen kan se jättebra ut på ytan,
men vi vet att vissa kunder i Sverige kör på det sättet och
det blir inte bra. Och det är ju en jätteviktig kunskap som
den personen besitter, men den är inte dokumenterad.
Och inte ens efter att han har gjort valet så dokumenterar
han ner varför, utan för honom är det bara en självklarhet.
4.2.5 Intervju med Tomas Volavka
Intervjun genomfördes 13 april hos WM-data i Norrköping. Tomas
arbetar som senior konsult.
Specifikationer
TV: Som jag sa förut har jag inte jobbat på WM-data så
länge och jag har inte deltagit i själva prototypandet än
så länge här. … Däremot har jag varit med om det genom andra företag som jag varit anställd vid, där man
haft en uttalad metod för hur man ska gå tillväga. Då
ingick bland annat själva prototypningen ganska klart
i processen eftersom man i det fallet sålde tjänsten till
fast pris. Då vill man avgränsa sig så mycket som möjligt.
Då gjorde man det bland annat med hjälp av att bygga
en prototyp, innan man gick igång med den fullständiga
implementationen. I det fallet var det ju ett viktigt steg.
Personligen så anser jag att just när man bygger nya applikationer eller nya gränssnitt, så är att bygga en prototyp
ett ganska bra hjälpmedel, för då kan man stämma av
just interaktionen med användaren och även integration
med andra system på ett helt annat sätt än när man bara
skriver specifikation och designdokument.
TV: I en specifikation kanske det kommer med ett blad
som visar gränssnittet, «så här ska det se ut», men det är
inte samma känsla som att sitta med en prototyp där man
kanske i alla fall hjälpligt kan klicka men kanske inte all
funktionalitet finns, men det utseendemässiga gränssnittet finns och då får men en helt annan känsla. Det är un– 65 –
gefär som att sätta sig och köra bil. Du kan få en broschyr
för bilen men det är ju inte samma sak som att sätta sig
ner och köra.
Försäljningsfas
TV: De gånger jag har varit med om har man delat upp i
faser och man har någon typ av försäljningsfas där man
diskuterar med kunden vad det är vad men vill få fram
och lämna ett kostnadsförslag. En prototyp kan vi bygga
eller generera. Vi har jobbat tajt med kunden i ungefär en
vecka där man interaktivt jobbar med applikationsdesignen alltså själva gränssnittet, användargränssnittet och
dess funktionalitet. Man specificerar vilka funktioner
som ska ingå. Även om man kanske inte presenterar själva prototypen så visste man att i den färdiga produkten
ska de här funktionerna ingå och de ska åskådliggöras
med de här gränssnitten. Och då har man i stort sett en
försäljningsfas och så har man ett själva prototypbyggandet. I det fallet kallar vi det för rapid solution workshop.
Utifrån det kunde man räkna på i stort sett vad det skulle
kosta att ta fram hela produkten, hela applikationen. …
Kommunikation kring prototyper
AN: Brukar det vara svårt att få kunden att förstå var prototypen handlar om? Får man feedback på rätt saker?
TV: Jag tror att så länge man är involverad i en ganska
interaktiv process tajt med kunden så att man kanske
inte sitter och tar fram bilderna på skärmen, alltså i en
utvecklingsmiljö, utan man sitter oftast med whiteboard
och ritar och tar sedan fram förslag. Och nästa gång man
träffas kan man diskutera och eventuellt kanske provköra saker och ting då. Då får man bra respons. Då tror
jag att de förstår. Däremot är det svårare att förstå att nu
har vi gjort en prototyp och nu ska vi bygga applikationen. Då kanske vi inte använder samma verktyg och då
kanske man måste göra om vissa delar av koden. Då kan
vissa kanske kunder ha lite svårt att förstå det där. Varför
måste vi skriva om det här en gång till? Eftersom det blir
en annan prislapp då. Idag väljer man verktyg som man
– 66 –
vill använda även i fortsättningen. Det underlättar naturligtvis. Idag kan det handla om webbsidor, det är mycket
enklare då. Det går ju även att skapa stilen med hjälp av
olika mallar. …
Att återanvända kod
TV: Om det fanns något specialfall för någon funktion
som man byggde in i prototypen som kunde återanvändas senare till själva koden för funktionalitet, det går ju
att använda, men jag tror i stor utsträckning ska man nog
undvika det. Prototypkoden är oftast inte bra strukturerad och dokumenterad. För det har man inte tid med då.
…
Dokumentation
TV: Man skriver anteckningar oftast, och även kunden
fick ju läsa anteckningarna så att vi hela tiden hade samma resonemang. … Problemet är oftast det att när man
jobbar tajt med kunden så jobbar man med en mindre
grupp med människor. Sedan kanske applikationen ska
komma ut i hela företaget också, och alla har inte samma
åsikt så där brukar man få annan feedback sedan när det
ska in i produktionen naturligtvis.
Samverkan i senare faser
TV: I fall där jag varit med så satt men mer på kammaren
och byggde och hade avstämningsmöten. Det har man
ju alltid med kunden. Man berättar hur långt man har
kommit och presenterar saker och ting. Men oftast när
man kommit ifrån prototypen och beskrivit själva prototypen. Till exempel designdokument, för det måste vara
en överenskommelse om att det här ska vi verkligen göra.
Själva prototypen kan ju utgöra en delmängd av det och
dokumentationen. Så får man stämma av vartefter. …
AN: Visar man upp systemet på något sätt vid den här
punkten eller hur gör man på mötena?
TV: Det är nog längre fram i utvecklingsfasen tror jag. Eftersom första delen oftast innebär att man inte har något
– 67 –
och visa egentligen. … Naturligtvis ingår det ju vartefter
en testfas, där kunden måste vara involverad. …
AN: Men det är inte så vanligt då att kunden är involverad
i mitten av projektet, utan det är i början och i slutet?
TV: Ja, det blir ju så. Naturligtvis kan det hänga ihop med
om det finns så att säga beröringspunkter med deras övriga system, då är kunden självklart involverad på ett annat sätt. Om man till exempel ska integrera med deras
nuvarande databaser eller nånting sådant. Då måste man
veta att det fungerar.
Man har ju oftast en projektledargrupp som kunden naturligtvis deltar i. Det är ju mest för att stämma av att
saker och ting flyter på enligt planen, och inte så mycket
för att förändra själva applikationen. Jag menar det skulle
ju inte hålla om kunden skulle vara inne och peta och så
halvvägs. … Risken finns att det kommer nya människor
och då blir det nya åsikter och så att försöker man att, ja,
i så fall göra förändringar efter att man levererat en viss
nivå.
Sammanhang över faser
AN: Är det samma personer som brukar göra prototypen
som sen gör systemet eller är det ofta olika?
Man har en blandning av personer som är involverade,
typ arkitekt och systemutvecklare. … Sen har man säkert
någon person som bär integrationen och kan beskriva
deras miljö. Det hänger ju fullständigt på vad det är för
applikationer naturligtvis. Men oftast är de här personerna involverade även i utvecklingen. På ett eller annat sätt
är de egentligen experter i det läget, för resten av gruppen som ska utveckla. Eftersom de varit med i den förberedande fasen och kanske fått lära sig om kunden och
deras affärsidé och vad applikationen egentligen ska leda
till. … För att egentligen ska det vara som en röd tråd för
annars tappar man ju kunskap mellan faserna.
– 68 –
Pappersprototyper
AN: Brukar ni använda pappersprototyper?
TV: Jo, det gör man i säljfasen. … I de första delarna blir
det oftast att rita kanske enkla varianter med bara ramar
och var ska saker finnas och vilken funktionalitet som
ska vara med. …
4.2.6 Intervju med Bo Olls
Intervjun genomfördes 19 april hemma hos mig. Bo Olls är konstnär
och skulptör med lång erfarenhet av projektledning, utredning, utställningar, utsmyckningar och gestaltningsuppdrag inom statlig, regional, kommunal och privat verksamhet. Han är nu verksam bland
annat som projektledare för Visioner vid Vatten, som arbetar med
konstnärliga gestaltningar längs och i trakterna kring Göta Kanal –
Östergötlands största sammanhängande konstprojekt. Vid intervjun
närvarade även Bibbi Nawroth, konstnär och gift med författaren till
denna uppsats. Nedan följer utdrag ur intervjun.
Olika arbetssätt
BO: Det finns ju ensamvargar som går från ax till limpa
på väldigt kort tid. Och som också tror att det är en bra
modell att göra det. Det kan bero på bristande erfarenhet. Det kan bero på bristande intresse för uppdraget.
Det kan bero på att det i regel finns en ekonomi i de här
uppdragen som inte finns i andra sammanhang inom
konstområdet, därför att här arbetar man ju ändå på en
typ utav marknad som har med verkligheten att göra och
inte med den ideella världen. Utan det finns i regel ett
förhållande till en beställare eller till en grupp av något
slag som är med i de här processerna. …
Beställarkompetens och långsiktighet
BO: Jag har jobbat som informatör på just det här området för att bereda väg för den här sortens arbeten, och
inte alltid då åt mig själv utan för att slussa in rätt sorts
konstnär i en sådan process. Därför att det är en del utav
problematiken med det här. Det beror ju på att det måste
finnas kunniga beställare och såna är det inte så gott om,
– 69 –
utan de har väldigt luddiga idéer om hur man hanterar
såna här modeller. Och då finns det väldigt olika behov
utav att tydliggöra för dem själva också vad det är de ska
göra eller vill göra för nånting.
BO: Konstområdet har den svagheten och fördelen att
folk har väldigt stor respekt ibland och väldigt liten respekt ofta för området. När man kommer just till de här
situationerna då hamnar folk lätt i bryderi. Och när de offentliga strukturerna är starka, till exempel när kommun,
landsting och stat har haft organisationer för det här, och
det är ju det från 60-talet ungefär; när man byggde upp
kulturnämnder, då byggde man in strategier för hur samhället skulle utvecklas, då har det också funnit möjlighet
att samla på sig erfarenhet i de här avseendena. Men när
samhället sadlar ner den delen, och det börjar man göra
på 80-talet, då försvinner också kunskapsnivåerna, även
i den privata sektorn. … då hamnar man i ett läge där
tycke- och smakfrågor av privat karaktär är det som styr.
Och det är en väldigt trång modell eftersom de offentliga
modellerna ofta bär iväg över väldigt lång tid. Mycket
saker finns kvar i de här sammanhangen i upp till tio,
femton, tjugo, fyrtio eller hundra år. Och därför gäller
det att, både när man planerar för det här och genomför
det, tänka på vad det är dels som man sätter dit, men
också att tänka i materialiteter, att tänka i hållbarheter.
Att tänka i system som ska tåla förändringar över tid. Jag
antar att det har beröringspunkter även med ditt arbete
eftersom det finns besvärliga sätt att göra det, som ingen
annan sen kan gå in i. Och det finns sätt att göra det som
gör det enkelt att lösa problematiker som ligger en bit
framåt i tid.
Offentliga miljöer
BO: Det är ofta mer komplicerat än det ser ut. Man tycker
ju att jaha, nu ska det stå ett konstverk där, och så ska
man hitta en konstnär som ska ställa det där, och konstigare än så behöver det ju inte vara. Men det är mera
komplicerat än så.
– 70 –
BO: Du ska försöka argumentera för konstverket, och du
måste på olika sätt sälja in det i förhållande till brukare.
Det är en väsentlig skillnad att jobba med konst i ett äldreboende än om du jobbar till exempel som projektledare
med konst ute på stan. Därför att det blir två olika, helt
olika, väsensskilda sätt att förhålla sig. På ett äldreboende till exempel där människor inte kan undvika konsten,
utan måste vara i den, har du skäl att ta större hänsyn i
den offentligheten, än vad du har om du jobbar ute på
stan. Därför att där kan folk välja att gå ett kvarter nedanför om de tycker att det ser alldeles förfärligt ut. Där
finns också en toleranstrappa som är större därför att
den refererar och relaterar till väldigt många andra saker
i staden som neutraliserar delar utav den här situationen
som kan dyka upp. Och ändå blir väldigt många kontroversiella just därför att man bryter ett mönster som har
funnits, man ställer dit nånting annat som kanske inte
direkt förväntas finnas där, och man möter den relation
som människor har till en plats där man i sin värld har
placerat alla saker redan. Så bryts det mönstret och då
kommer det in ett moment som väcker ibland intresse,
ibland aggressivitet, ibland oro, ibland andra sådana affekter.
Projektprocessen
BO: … i regel gör man ju så … att man skriver ett program
innan man sätter igång, och det försöker man då skriva
så pass luddigt så det finns möjligheter att i praktiken
göra förändringar, utan att bryta mönstret för mycket
från programmet. Programmet är i regel allmänt hållet,
men handlar om hur man förankrar det här i förhållande
till brukare och beställare. …
BO: Det sker ju olika anpassningar efter olika förutsättningar. I somras så reste vi en nio meter hög skulptur ute
i Roxen. Ungefär en sex–sjuhundra meter ut från Bergs
slussar. … Och en bit ut i Roxen då så är det en stenpir
som är kanske 100 meter lång och sen är bara lite bredare än köksbordet här, och består av stenbumlingar. …
Det är alltså nio meter hög krysställd skulptur av perfo– 71 –
Bild 1. «Dubbelgångare» av konstnären Kent Karlsson. Foto: Bo Olls.
rerat stål. Den väger fem ton och är nio meter hög. När
man står på stranden så ser den ut som den är så här
liten därför att den har evigheten bakom sig så att säga.
Det finns inget annat än vattnet att relatera till storleksmässigt. Men när man kommer nära så är den oerhört
stor! Och det där är alltid en svårighet, plus att står du på
marknivå så ser den ut på ett sätt. Står du upp på slusstrappan har du höjd och ser den från ett annat perspektiv. Så här handlar det om att prova vilka skalor som en
sådan sak ska ha till exempel, att prova vindstyrkan för
hållbarhetens skull. Man ska prova hur tung den får vara
i förhållande till om de här stenarna åker ner i gyttjan
utav tyngden på skulpturen. Det här är en lång process
utav successiva ändringar och förändringar som sker un– 72 –
Bild 2. «Dubbelgångare» av konstnären Kent Karlsson. Foto: Bo Olls.
der förprocessen. Och då tar en sån här process från de
första skisserna till verklighet ungefär ett år. Och det är
en rätt så bra cykel att arbeta i. Det har också lite att göra
med hur väderlek och årstider ser ut om man jobbar ute
på platser där det inte finns någon förkunskap om saker. Det är skillnad om du är i stadsrum. Då finns ju el
framdraget någonstans i närheten. Det finns en vetskap
om hur man tar sig dit, inte minst. I det här fallet fick vi
ju då hyra in till exempel ingenjörstrupperna från Eksjö
som kom med en stridsvagnsponton. … Man tror varje
gång att man lär sig nånting utav gången innan. Men det
är alltid nya komplikationer i en sån här process, plus att
man blandar in ett par hundra människor på olika sätt,
allt från entreprenörer till tillfälliga hantverkare som ska
komma dit och svetsa i tre timmar. Så finns det inget att
– 73 –
svetsa. Så får de vänta. … Men man kan inte styra alla
processer när man gör sådant här en enda gång.
Kommunikation
BO: Ute på den här vågbrytaren till exempel så skickade
vi ut en grävmaskinist och ett antal personer som skulle
gjuta fundament, lyfta undan stenar, gräva sig ner till vattennivån och gjuta fundament som den här korsställde
gubben skulle stå på. Och det fanns ju då specificerade
ritningar för hur de här skulle se ut, som ingår i förarbetet. … De hade ju sina ritningar och det sista jag frågade
var «är ni säkra på var läget är?» «Jajamensan, inga problem, du kan åka hem.» Halvtvå på dagen då så … kände
jag mig inte riktigt trygg. Så jag ringde till en fiskare och
frågade om han kunde skjutsa ut mig till vågbrytaren.
… När jag kommer ut dit så står fundamenten fel. …
Så de fick ju hämta grävmaskinen igen och köra ut den
igen, och gräva upp alltihopa. … Det händer alltid någonting i den här processen. Därför att överföringarna
utav information kan man aldrig lita på att det har skett
på det sätt som jag har tänkt, utan de har tänkt på 100
olika sätt. … Det här sker ofta i de processer som finns
runt om i stan. Det stöter jag på väldigt ofta till exempel
att nån har beställt ett jobb och sen låter man utförarna
göra den sista monteringen eller det sista arbetet. Men
de vet ju inte ett dugg! De har ju inga förhandskunskaper
av det här. … Och då får man mängder utav sådana här
felupplägg, som beror på att man inte har varit tillräckligt
tydlig, och framförallt att man inte har varit med i processen. Danska arkitekter till exempel kräver att finnas
med under hela processerna, från de stora sakerna och
ner till småspiken. Just därför att de vet att varje avsteg
från en sådan modell innebär att någon annan bestämmer någonting som får effekter på slutprodukten.
BO: Man anlitar ju ofta hantverkare. Och då är det ju
också såna där överföringsproblematiker där man kanske inte ens själv får utföra det som ska göras. … Det du
inte får göra själv, det blir väldigt svårt att styra om det
vill sig illa. Och väldigt ofta så har du ju oerhört många
– 74 –
led som ska fungera. Och det där stöter de flesta konstnärer på och blir chockade av, till exempel när de ska göra
en väggmålning någonstans. Och sedan efter att de gjort
den och kommer dit efter 14 dagar så har någon typ satt
upp ett brandskåp mitt i! Därför att den som sätter upp
brandskåpet lägger ju ingen som helst estetisk aspekt på
var det ska sitta, utan de sätter ju det där det är enklast.
«Oj, där sätter vi den, pang.» Och då blir ju konstnärer
sårade och tror att det är en demonstration mot själva
konstverket. Men i regel är det ju inte det, utan det är
mycket enklare. Alltså, det var enklast att sätta den där,
och då gör de det. Allting kan hända i de här processerna
där man blandar in människor som inte är informerade
eller uppdaterade på vad som händer, eller vad som ska
hända.
Förankring
BO: … Och när man ska göra ett konstverk där det bor
60 bofasta så ställer det helt andra krav, än om du gör
någonting i Linköping eller Norrköping. Och då är det
ett förankringsarbete som du måste starta från början,
där kan du inte komma på halva resan och säga att nu
ska ni få en skulptur här, som ni ska vara tacksamma för!
Utan där måste man försöka att beskriva hela processen,
och även om man gör det så är det ju inte säkert att du
får någon positiv effekt utav det, för att du vet inte vad
du möter.
4.2.7 Intervju med Karl-Göran Andersson
Intervjun genomfördes 18 april hos Prevas AB i Linköping. Prevas
utvecklar inbyggda system. Karl-Göran arbetar som konsultchef och
har stor erfarenhet som konsult. Nedan följer utdrag ur intervjun.
System: hårdvara och mjukvara
KGA: Jag tycker inte att det egentligen har så stor betydelse om man pratat prototyper i hårdvara eller i mjukvara.
Prototyp är för mig en funktion som ska realiseras. Vi gör
ju ofta så när vi gör systemarbete att man tar reda på vad
produkten har för behov. Och sedan bryter man ner de
– 75 –
här behoven. Vissa saker kanske måste ligga i hårdvara, i
alla fall i vår bransch har man realtidskrav, medan vissa
hamnar i mjukvara. … För mig är en prototyp ett system,
någon funktion av nåt slag. Som kan vara hårdvara, även
med mjukvara har vi någon form av hårdvara. Jag menar
nånstans har du ju alltid en hårdvara. Så att även om du
ska leverera ett programpaket så ska det antingen köras
på en PC eller något i linjesystem, eller i våra fall så kanske det är en inbyggd burk med någon liten specialprocessor där den här programvaran snurrar. Så att det är ett
system du levererar. Prototyper … ibland är det ju attrapper mer, en demonstrator så att säga, nånting man vill
visa upp på en mässa, och då måste man snabbt sy ihop
någonting. Jag gjorde bland annat en gång en utredning
åt ett företag i Stockholm som höll på med en bilradar.
… De hade byggt upp ett rack-baserat system som stod i
baksätet, det fyllde hela baksätet på bilen. Och så hade de
radarn där fram, i fronten på bilen. Det fungerade ju alldeles utmärkt det här systemet. De var med på en mässa
och visade upp det här och blev best in show och allting.
Men det är ju alltså inte överhuvudtaget möjligt, alltså
hela det här racket kostade ju kanske närmare 100 000.
… Och då är frågan, är det där en prototyp, eller vad är
det för någonting. Men jag såg det mer som en demonstrator. … Alltså det var ju en prototyp tyckte de. Men jag
såg det mer som en demonstrator som låg mil ifrån att bli
en riktig produkt.
Behövs prototyper?
KGA: Och det brukade komma diskussioner, ska vi gå
direkt på det riktiga systemet – nu var det väldigt låg
volym, volymen kanske är på tio enheter, det är max, det
är dem som man ska ta fram, av speciella konstiga försvarsprodukter. Då brukar man diskutera om man ska gå
direkt på produkten, eller om man ska ta fram en prototyp först. Och då brukar cheferna tycka att en prototyp
innebär en massa extra kostnader. Jag brukar alltid, nästan alltid, föreslå att man går på prototyp först, faktiskt.
Någonting, kanske en demonstrator, nånting som man
– 76 –
kan utveckla på innan man är färdig med den riktiga
produktutvecklingen. … Vi har en bild av hur det ska se
ut, men den är inte färdig till 100 %, och det är ju därför
man tar fram en prototyp för att man ska kunna se hur
den riktiga produkten ska se ute sedan. Alltså man tar
fram en massa jättefina underlag, och sedan visar det sig
att så här kunde vi inte göra! Det ska ändras. Man ska
göra om underlagen, med allt vad det kostar. Det är alltså
inga lätta ändringssvängar då, för då ska man använda
ändringshantering, och det ska godkännas ett ärende.
Det ska ju vara speciella möten då. Så ska det diskuteras:
ska vi göra ändringen, ska den införas? Det är en process
som tar väldigt lång tid. Arbetar man med en prototyp
då är det mer hantverk. Då fixar man och donar själv
utan att fråga någon i princip.
KGA: I en högvolymprodukt använder man nästan alltid prototyper. För att där måste man ju trimma, för att
den ska bli så produktionsanpassad som möjligt. Så man
måste ju kanske köra ett antal vändor med en produkt
innan man säger att den är färdig för marknaden. Exempelvis en mobiltelefon. Den första mobiltelefonen som
man får upp hit till Flextronics, det är ett kort som är
ungefär 40×40 cm, med bara en massa kretsar på, men
den fungerar som en mobiltelefon. Och den kan man ju
använda och börja utveckla mjukvara på, och börja testa
funktionerna. Och sen fortsätter de ju nere i Lund och
trycker in allt det här då i den lilla telefonen.
Arbetssätt
KGA: Om man bestämmer sig för att ta fram en prototyp, och börjar jobba på det sättet, så ska arbetssättet inte
skilja sig när det gäller så att säga projektmodeller eller
såna saker eller kanske. Men man behöver kanske inte
vara riktigt lika hård på dokumentationen. I princip ska
man ju följa de modeller som man kört normalt sett. När
man har tagit fram en prototyp, eller om man kallar det
en demonstrator eller vad man vill kalla den, hur mycket
ska man använda den där sen, när man sen kör igång
projektet? Där råder det ju väldigt delade meningar. För
– 77 –
en del tycker ju att vi har ju tagit fram så mycket när vi
har tagit fram prototypen, så vi kan ju ta nästan allting då
och kan spara tid, vi kan återanvända och sen kör vi på
det. Det är ju en skola, några som tycker så. Några andra
tycker att, nej men det vi har i prototypen det slänger vi.
Det tog vi fram när vi gjorde prototypen. Nu ska vi använda erfarenheterna från prototyparbetet, men vi börjar på ruta noll.
KGA: Jag vet att Siemens-Elema, som jag jobbat ihop med
i Stockholm, de körde enligt den modellen. Man gjorde
en tidplan där man tidsatte tiden för att ta fram en prototyp. Sedan satte man tidplan för att utveckla den riktiga
produkten. Och då, genom sina erfarenheter av gamla
projekt, kunde man säga att i och med att vi tar fram
en prototyp så kommer vi att vara så här mycket snabbare sedan när vi jobbar med produkten eftersom då har
man ju säkert utrett de här svåra sakerna också, alltså de
som man inte var säker på hur man ska göra, eller hur
eller var de ska implementeras. Om man tänker sig vissa
komplicerade algoritmberäkningar eller någon modellberäkning eller sådant, kan man givetvis använda dem
om man har tagit fram dem i prototyparbetet. Men det
är inte så att man tror att man gjort halva produkten när
man gjort prototypen, och bara fortsätter och gör färdigt.
… När man fått fram tillräckligt mycket som säger att
idéerna håller – marknaden finns, det här kommer bli
ekonomiskt försvarbart – då går man in i själva produktarbetet, och då börjar man om. Då är det förbjudet att
använda gammal kod i princip. Sen tror jag ju inte att
det var riktigt så i praktiken, men det var så man gick ut
och sade.
KGA: Prototypen utvärderas och den visas ju för kunder,
och den är en fungerande prototyp. Den kanske inte har
alla funktioner, men den har tillräcklig många funktioner för att kunna säga att det här kommer vi ro i hamn.
– 78 –
Projektmodell och tidplan
KGA: Egentligen blir prototyputvecklingen ett litet projekt i sig, som bedrivs enligt konstens regler. Och sen när
man startar riktiga produkten så är det ju samma projektstyrningsmodell. Man kanske gör en viss adaption av
projektmodellen för prototyparbetet, där man bestämmer sig för att vid prototypen så hoppar vi över de här
och de här dokumenten som normalt sett ingår i projektmodellen. Och då struntar man i dem, och man har speciella begränsningar för att snabba upp processen. Halva
jobbet är att få fram en prototyp ganska snabbt, och idag
när man har en väldigt kort tid tills produkten måste
vara ute på marknaden. … Tittar man på mobiltelefoner
så är det helt avgörande när telefonerna kommer ut på
marknaden. … Det där är ju ett väldigt speciellt sätt att
arbeta i den situationen, för att där är ju tidplanen helig.
Det är den ju inte för alla produkter som finns, överallt
i världen, men man har ju gått åt det hållet att tidplaner
blir viktigare. … Om det kanske är vissa saker som till
och med är på forskningsstadiet så räknar vi kanske med
att det här kommer ut om två år ungefär. Och då bygger
man ju många prototyper under vägen. Det blir ju inte
bara en prototyp, utan man tar fram en prototyp, som
sedan leder till nästa prototyp, och nästa prototyp …
KGA: Det blir ju en förstudie kan man säga, som leder
fram till någon form av prototyp, som har bestämt omfattningen av produkten, hur mycket den ska kosta, och
sedan bestämmer man kanske att vi kör inte det projektet. … Oftast vill man ju ta det beslutet tidigare genom
att egentligen bara göra en utredning eller något sådant,
men det är inte säkert att man kan det. Man kanske vill
köra på med prototyp och testa idéer mot underlag och
sådant. Det är ju komplext det här.
Problem med prototyper
KGA: Det som är mest farligt är att det blir missförstånd
angående vad det är man levererar. Det blev det i ett fall
för något år. Vi sa att det här är en prototyp, med de bris– 79 –
ter den har. En prototyp har alltid brister, funktioner eller buggar så att den hänger sig. Och sedan så hade vi en
kund som var intresserad av det här. Och vi var väl sugna
på att ge ut den tidigt och hade inte städat upp i all kod,
och det här var då en mjukvaruprodukt, ingen hårdvara.
Kunden fick den, och den kunden lade ju något annat i
begreppet prototyp och trodde att det var något färdigt.
De var nog beredda på att den skulle ha vissa brister,
men de hade ju satt ribban på en annan höjd än vad vi
hade gjort. De var vana vid att prototypvaror ändå var
en fungerande enhet till nästan 99 %, en förserieprodukt
så att säga som kanske bara hade några små brister. Men
vi hade ju sagt att det här är en prototyp, och att den har
många brister. Och då blev det missförstånd där. Kunden
fick den och tyckte att de skulle göra en utvärdering av
den. Men den hade ju så mycket brister, så de tyckte att
de inte ens kunde göra en utvärdering av den. … Ingenting fungerade ju! … Jag tror inte att man kan vara nog
tydlig mot kunden faktiskt, om man skickar ut en väldigt tidig prototyp. Så det är väldigt viktigt att man har
en bra relation till den kunden, att man känner kunden.
… Man kanske har ett samarbete med någon kund. De
används just som förtestare, och de vet vad det handlar
om, de känner oss. I det här fallet var det en helt ny kund,
som inte kände oss. Och då blev det missförstånd om vad
man menade med prototyp.
KGA: Jag ser nog mer prototypen som något internt för
projektet, ett sätt att tidigt få någonting att så att säga
testa idéerna på. Däremot så är det ju inte alls säkert att
det behövs en prototyp. Säg att du har en produkt som
du är ganska familjär med, och sen ska du bara in med
nya funktioner. Då förekommer inte prototyptänket,
utan prototyp handlar ju ofta om när det är en relativt
ny produkt.
Användningsområden
KGA: Vi använder ju ofta begreppet demonstrator. Alltså någonting som man tar fram för att demonstrera för
kund, men inte att skicka ut till kunden. Man tar hit kun– 80 –
den, kanske visar någonting. Och som jag sade så beror
det ju på vad det är för typ av produkt. … Prototypen gör
man för att testa att idéerna håller, och för att om det är
en komplicerad produkt så är det ju för att projektet har
nytta av prototypen, och man hoppas att prototypen ska
hinna fram mycket tidigare än produkten, så att man kan
gå igång och börja utveckla, och testa tankar och idéer på
prototypen. Och prototypen har, som jag ser det, bara en
viss livslängd.
KGA: Om man tänker sig man har en projektledare för
prototypen, så vill man nog gärna att projektledaren följer med in i projektet, och även kanske de som har gjort
någon form utav systemtänk. Sedan vill man säkert ha in
nytt folk också, så att man inte kör fast. Men man måste
ha med sig några personer med översikt över projektet.
KGA: Många start-up-företag som kanske några har tankar och idéer, kanske tar fram en demonstrator eller en
prototyp för att visa marknaden. I andra fall … tar man
fram en prototyp, för att man är nästan till 99,9 % säker på att man kommer att köra den vidare till projekt.
Det handlar mer om att det kanske är vissa saker som
man måste utreda i prototyparbetet och där är det mer
att ta fram någonting inåt så att säga. Man kanske inte så
mycket visar mot kunden, utan har för sig själv för att se
om något går att realisera. Och många hävdar ju att om
man tar fram en prototyp, så blir den totala utvecklingstiden kortare. Fast många chefer blir ju jättenervösa, för
att man tycker att det tar lång tid innan man kommer
fram till nånting färdigt.
Mjukvara
KGA: Vi har ju det i vår process, att vi alltid tar fram dokument innan du får skriva en enda kodrad. För när du
skriver dokumentet så konstruerar du. Att skriva dokument är att konstruera. För du kan inte skriva en specifikation om du inte tänker igenom hur det ska fungera.
… I prototyparbete gäller att det måste vara mycket mer
brainstorming och sådant också.
– 81 –
4.2.8 Intervju med Michael Garrido
Intervjun genomfördes 23 april hos Gaia AB i Norrköping. Gaia
sysslar med informationslösningar, it-projekt och verksamhetsutveckling med särskild kompetens inom detaljhandelsområdet. Michael Garrido arbetar som utvecklingsledare. Nedan följer utdrag ur
intervjun.
Användningsområden och arbetssätt
MG: Vi jobbar ganska mycket med prototypframställning,
eller egentligen även med attrappframställning om man
uttrycker det så. Ofta har man en grundidé som man då
skissar mer än att man bygger den från scratch. Och i
olika utvecklingsdelar så använder man prototyper ganska ivrigt just för att lyfta ut en del av problemställningen
och kunna se på något med lite andra ögon än om det
kanske finns i ett befintligt stort system. Så ibland kan
det vara bra att lyfta ut det och göra en prototyp av den
anledningen eller göra en prototyp för att testa gränssnittet och kanske testa det även mot kund också.
MG: Man kanske har åstadkommit vissa funktioner och
så andra delar av det kanske är så att det mest ser ut. Allting fungerar inte alltid i den prototypen utan man kanske vill visa till en viss del hur vi hade tänkt att det skulle
fungera. … Och sen hur mycket som är attrapper eller
hur mycket som är program skiljer sig åt, meningen är att
man ska få en visuell känsla för hur programmet fungerar. Så där kan det vara en liten gråzon angående hur
mycket som är ren bild och hur mycket som är program.
Vi försöker hitta en mix däremellan för att få en rimlig
kostnad för att ändå ta fram prototypen. Och vissa prototyper tar man fram och så blir de ingenting, man bara
kastar bort dem i stort sett. Man kanske använder vissa
klasser och sånt.
AN: Men ni gör dem i en programmeringsmiljö?
MG: Det gör vi. Ofta gör man det för att testa ett koncept
eller för att se om det håller eller fungerar och det kan ju
även vara ur prestandasynvinkel. Så kanske vi vill trycka
– 82 –
in data i det där gränssnittet som det normalt sett inte
håller för, för att testa prestandan och för att se att det
verkligen fungerar. Även om man normalt sett vet att det
är 10–15 rader som ligger här och de borde vi kunna visa
på det här sättet men vad händer? Tar det två minuter att
öppna den här sidan eller fönstret eller vad det nu råkar
vara för någonting, om man trycker på lite mer data, som
ändå är inom rimligheternas gränser så att säga.
Återkoppling
MG: Om det är någon större del så kanske man har en
referensgrupp som man lägger ut den lilla prototypen på.
Så att man försöker visa upp någonting relativt tidigt för
att kunna få respons tillbaka. Men det måste ändå finnas en viss funktionalitet i det för att de användarna ska
kunna ta till sig det och tycka någonting om det. För om
det bara är bilder som man kanske kan klicka på så ger
det inte någonting. Utan det måste nästan hända lite för
att de ska kunna se att, ja, det här är verkligt, det här ska
jag kunna ta ställning till.
MG: Oftast när man har en prototyp så vill man få spontan feedback på den också. Oftast är det bra att sitta tillsammans med kunden. Eller med de personer som kör
den, för det ger också en viss signal om det är bra eller
dåligt. Medvetet eller omedvetet så beter man sig ändå på
ett visst sätt. Eller man tycker att något kanske fungerar
dåligt. «Jag brukar göra så här», eller «ja, men då kan du
kanske göra så där istället», så får man mer dialog i det.
Att bara skicka ut en prototyp och säga «testkör den här»
blir sällan så mycket värt att det är värt att lägga tiden på
den på det sättet.
MG: Vi får inte alltid prototypfeedbacken direkt ifrån
den användare som gjort kommentaren, utan det kanske
samlas ihop av någon. Men oftast försöker man ha en
ganska nära dialog där. Annars är det lätt att tappa något
ganska viktigt spår där, som gör att man tappar i användarbarhet till exempel. Man skriver alltid ned vad som
fungerar bra och vad som fungerar dåligt. Och oftast går
– 83 –
man igenom det på nästa projektmöte: «Det här måste vi
kanske ändra på. Med deras data ser det här jättekonstigt
ut så vi måste kanske ändra på någonting utifrån de förutsättningarna.»
Produkt eller kundanpassat
MG: Själv jobbar jag ju med produktutveckling så det
ställer ju kanske lite speciella krav, olika kunder ser ju
det här på lite olika sätt och olika typer av kunder har
lite olika behov så att det gör ju också att man får tänka
lite annorlunda när man utvecklar systemet. Så produkttänket måste ge en annan infallsvinkel än att bara göra
ett kundanpassat case, som är lite mer förlåtande ur användbarhetssynvinkel. Men om du har en produkt som
du vill få ut till ett visst antal användare på en mängd
olika företag med olika verksamhet, kanske inom samma
område men ändå där de jobbar på olika sätt, så kräver
det lite mer så att säga av tankearbetet och prototyparbetet. Det är inte bara att göra något som någon tycker
om, utan det måste fungera mer generellt och vara mer
anpassat till standarder eller hur det beter sig mot andra
program och så vidare.
MG: Vi har ingen prototypavdelning som sitter och jobbar
enbart med prototyper, vi är ju totalt kanske 40 personer
på utvecklingsavdelningen och det är ju inte så mycket
att det lönar sig att ha en egen prototypavdelning som
enbart jobbar med det. Men däremot har vi ganska bra
överhörning mellan projekt där vi försöker se designapproacher eller användbarhetfördelar som vi försöker utnyttja i flera projekt. … Det är utvecklaren som sitter och
gör prototyperna också för att de ska få en bra förståelse
hur det ska fungera. Det blir ju också en naturlig brygga
mellan användare och utvecklare. Att man så att säga får
en samsyn, att man förstår vad det är man vill utföra för
någonting. För annars kanske det kan vara lite svårt att
enbart beskriva i ord utan man måste åtminstone ha bilder men gärna i vissa fall då prototyper också.
– 84 –
Risker med prototyper
MG: De få riskerna då man prototypar ett helt system är
vanligtvis att beställaren kan inbilla sig att det antagligen
nästan är klart. Det är väl den enda risken som man kan
se. Där försöker man vara ganska tydlig på att poängtera
att det är en prototyp som ser ut som att den fungerar
och den beter sig nästan som den är tänkt att fungera
men att man ska förstå att det finns ett antal saker till
som vi behöver göra för att det ska vara ett produktionsmässigt system som vi kan leverera med vettig kvalitet
och så vidare. Det har inte varit någon problem hitintills.
Andra typer av problem som kan tänkas uppstå är att när
man utvecklar prototypen så har man nästan utvecklat
funktionen, prototypen blir lite för stor för att det ska
vara ekonomiskt försvarbart. Det är väl en annan risk
som finns, att den blir ett för stort eget djur. Om man
inte drar strecket i tid och säger okej vi ska titta på just
den här delen av det vi utvecklar, och de här och de här
delarna som också ligger kring den här prototypen fast
det inte var det som var syftet. …
Återanvändning av kod från prototyper
MG: Jag försöker max återanvända vissa delar, annars försöker man revidera koden lite grand när man går från
prototypsteget till produktionssteget. Dels för att man
antagligen har gjort massa småfula saker som man inte
borde göra i det verkliga programmet. Så att man lyfter
de delar man är väldigt nöjd med och resten kastar man.
Men i vissa fall har vi återanvänt hela prototypsteget också. Då har man haft den ambitionen att det ska bli nästan
så bra, då lyfter man in det och kör en kodrevision på det
och ser att det följer den standard som man tänker sig,
och sen så ser man att det fungerar. Och i vissa fall har
vi byggt programidéer som bara är till för demonstration, men som inte har blivit funktioner i systemet än så
länge.
– 85 –
Utformning
AN: Det ni visar upp för kund, brukar det ha det utseende
fullt ut som den färdiga produkten ska ha?
MG: Ja, så nära som möjligt i alla fall när det gäller kunddelar, för ibland kan det vara små detaljer som gör hela
skillnaden. Det ska verkligen se ut och bete sig som programmet borde göra, det är viktigt i kundprototyper. …
När man tittar på interna prototyper så behöver det inte
se rätt ut, utan då kan det kan vara lite yxigare i sin utformning.
Utvecklingsmodell
MG: Dels så har man en tidig attrapp kan man säga. Man
ritar upp. Så här borde det kunna se ut, så här borde det
kunna fungera och sen jobbar man lite kring det och sen
försöker man ha några nedslag under utvecklingsfaserna
där man stämmer av. … När vi börjar närma oss slutfaserna så släpper vi oftast iväg olika betaversioner kan man
kalla det för, som de kan testa och känna på lite. Vi har
flera nedslag under utvecklingens gång också. Vi jobbar
i block om funktionalitet, ganska små fokuserade block
där man kanske lägger ned omkring 250 timmar. Sen har
man en funktionalitet som är färdig för leverans, den
kanske inte är paketerad och kanske inte fixerad. Och i
det läget kan ju kunden titta på den funktionaliteten och
se om det fungerar, och sen har man kanske flera såna
utvecklingsblock inför en leverans. Men i varje sådant
utvecklingsblock är tanken att det ska vara levererbart i
det läget. Och sen så har vi även ett slutblock egentligen
där man kan hantera förändringar och vara lite flexibel i
sin hantering. Men det beror ju på lite också. Ibland har
man ett fastprisuppdrag, då ska det göras på det här sättet och då blir det lite fyrkantigare hantering. Men om
man har en mer blockuppdelad process och säger att vi
ska lägga så mycket tid och göra den här funktionaliteten
och dela in det på det här sättet, och att man även får
med lite tid för att hantera förändringar från start. Så har
man möjligheterna att samla lite inför slutleveransen och
– 86 –
göra lite finjusteringar eller vissa funktionsförändringar
inom projektets ramar.
Kravspecifikationer
MG: Vi försöker ha en ganska bred kunskapsbas så att det
är inte så att det är några som alltid sitter med kravspecandet. … Varje utvecklare som sitter i ett team kan få
ansvaret att jobba med sin kravspec-del. … Vi försöker
göra så att alla utvecklare är delaktiga i hela processen
och inte bara att «nu ska du göra den här grejen, den ska
se ut så här och fungera så här». Det blir inte så kreativt och så schysst för den som utvecklar. Vi vill hellre att
man ska få en större helhet. För då tror jag också att man
kan göra ett mycket bättre jobb. Och den utvecklaren
kan också utvecklas … få en bättre personlig utveckling,
och även komma med bättre förslag om att vi borde göra
så här istället. För att den personen som utvecklar det
då också har verksamhetskunskapen om hur det borde
fungera eller hur man jobbar med det. Det är inte så att
projektledaren kommer med ett stort dokument och slår
i huvudet på utvecklingsavdelningen och säger «gör det
här». För det fungerar inte riktigt tror jag. Det går säkert
att göra och det går säkert att göra på hyggligt rätt tid
men det får inte den verksamhetsmässiga sluteffekt som
man vill ha tror jag.
MG: De kravspecar vi har innehåller mycket visuellt, alltså hur man vill att det ska se ut. Eller en idé om hur det
ska se ut, och ibland vill man ju då ta det ett snäpp till och
då se till att det blir en prototyp också. Så att vissa delar
försöker man kanske prototypa men vi försöker vara väldigt visuella i hur vi upplever att det borde funka. För då
får man också den verksamhetsmässiga dialogen …
Prototyper och kunskapsutveckling
MG: Och har man en prototyp så har man en lite större
frihet att använda andra angreppssätt. Man kanske använder nåt annat designmönster i just här fallet för att se
om funkar det här bättre. … Då kan man utifrån prototypen diskutera om det blir bra eller dåligt. Och då är det
– 87 –
en mer intern prototyp men det ger ju också de utvecklare som är med och gör prototypen ny kunskap.
4.2.9 Intervju med Peter Grew
Intervjun genomfördes 23 april hos Lawson i Linköping. Peter Grew
arbetar som arkitekt i användargränssnitt- och användbarhetsteamet.
Utdrag ur intervjun återges nedan.
Utseende och beteende
PG: Syftet med den här klienten när vi tog fram den var
flerfaldigt från början. Först att göra någonting som ger
ett enhetligt utseende på flera olika back-end system. Det
ska upplevas som en applikation fast det egentligen är
flera skilda applikationer som kommer från olika bolag.
Sedan ska det också ha samma utseende och känsla oavsett om du kör Windows XP eller Windows Vista. Och för
att få fram själva målbilden för den här applikationen så
anlitade vi ganska tidigt – det är nog två år sen – Frogdesign, som då fick i uppgift att göra det här. De är väl ett av
de större, mer välrenommerade industridesignföretagen
här i världen och har hållit på sedan slutet av sextiotalet.
De har gjort mycket åt Apple. De har gjort NeXT-datorn
och Steve Jobs telefoner. De har två divisioner. En är elektronisk design och en är mer traditionell industridesign
där de designer telefoner och hushållsapparater och sådant. De har även varit inblandade och designat Windows XP och Windows Vista och sådana saker. Så där har
vi något intressant.
PG: Ganska tidigt så gjorde de körbara prototyper av
själva gränssnittet i Macromedia [Director], så att man
fick en känsla för hur det skulle se ut och hur det skulle
kännas att köra det, och vilka beteenden det hade. Om
man tänker att man ska göra ett användargränssnitt så
kan man ju göra det på papper. Man kan göra en ren grafisk layout så att säga, men det är ju bara en liten del. För
det som egentligen är svårt att få fram, det är ju själva beteendet, hur det ska bete sig när man kör; interaktionen
med användaren. Och det lyckas de väl hyfsat med i sina
tidiga prototyper. Och då var väl den så att säga en stor
– 88 –
del av kravbilden in i projektet vi drog igång då. … Ganska tidigt så gjorde vi en prototyp som liknade den första
prototypen från Frogdesign. Och sen så blir det lite iterationer mellan att prototypa fram så att det ser ungefär
ut som det ska, och sedan får man backa och titta på hur
kan vi göra ett lite bättre ramverk för den här klienten.
Och så backar man lite och gör om själva botten, det här
ramverket, och sen så kanske Frog har gjort ytterligare
lite grafisk prototyp med nya beteenden och så där, och
sedan går man tillbaks då. Så det blir lite iterationer fram
och tillbaks där: du utvecklar ramverk kontra utseende
och beteende.
PG: För ett år sen, strax före förra sommaren så hade vi
en ganska bra sådan prototyp, som fungerade ganska likt
den första prototypen som Frogdesing levererade. Ungefär samtidigt blev den här företagssammanslagningen
med Lawson i USA klar. Och då kom de in med sina produkter. Så då har vi ett team där som skulle använda sig
av vårt ramverk för att bygga in sig i samma klient då. Då
hade vi vår andra applikationsutveckling i samma värld.
Användbarhet
AN: Hur är det med användbarhet, när och hur kommer
det in?
PG: I det här projektet så körde vi det ganska tidigt. Redan när Frog byggde sin första prototyp, så hade de ju
användbarhetsaspekter med där och testade den här prototypen på kunder, några utvalda kunder då. Och sen har
vi kört med jämna intervaller. Man har bjudit in kunder, affärsutvecklare som fått köra systemet och man har
granskat och de har fått utvärdera på de här synpunkterna. Och nu i mars hade vi en stor konferens i USA där
vi bjöd in nästan tretusen deltagare bland våra kunder.
Då hade vi ett labb öppet där de var välkomna in för att
testköra och lämna synpunkter. Det känns bra, för det
ger mycket att få de synpunkterna. Jag har varit med i
projekt tidigare, där en massa tekniker sitter och bygger
– 89 –
saker och det blir ju inte bra. Det blir ju «av tekniker för
tekniker» om man säger så.
PG: Ju tidigare man kan få in de där synpunkterna, desto
lättare är det att få till ett bra ramverk också, som har
stöd för de här sakerna, så att man inte behöver spetta in
det i nästa version, på ett mindre bra sätt.
Visioner och begränsningar
PG: Vi har tagit fram målbilden av prototypen, och den
har varit oerhört visionär. Det har så att säga lagt ribban oerhört högt upp, och sedan har vi försökt sträva
mot den målbilden. Men sen blir det ju så att olika affärssystem i bakgrunden har vissa begränsningar som
gör att det inte är möjligt att realisera allt det man skulle
vilja. Då har man fått stryka vissa saker. Men vi har ända
eftersträvat att lägga ribban så högt som möjligt, så att
man inte börjar med att kontrollera vad är det för begränsningar, sedan så designar man systemet utifrån vad
som man tror är möljigt i gamla världar. Då når man inte
längre så att säga. Men sedan är tanken att framtida applikationer vi bygger, att då ska man sitta på den där höga
ribban där man inte har de där begränsningarna med sig
i ryggsäcken.
Funktionsbibliotek
PG: Frog bygger det här första funktionsbiblioteket med
stilar i designsystemet, och då på slutet hade vi veckomöten där vi så att säga rapporterade våra fel. Eftersom vi
satt och testade deras stilar så hittade vi mycket buggar.
Då fick vi rapportera tillbaks om detta. Sedan har vi fortsatt att underhålla funktionalitetsbiblioteket.
Förstudie
PG: Först körde vi ett användbarhetsprojekt under en tid
där vi hade några från UI-teamet och någon användbarhetskille som var med och tittade på våra gamla system,
våra gamla användargränssnitt, och försökte se hur kan
man göra det här bättre, vad är det som brister när man
– 90 –
sitter och kör, vad är det användaren upplever som jobbigt? Och så gjorde de en rapport på det, och sen tog
man in Frogdesign här, och de tog del av den här rapporten och de var själva ute och intervjuade alla våra
utvecklare och kunder för att se vad man skulle kunna
tänka sig att förbättra. Så gjorde de en liten prototyp på
den här tunna klienten vi har, för att visa att så här skulle
det kunna se ut, om man bara fokuserar på att bygga om
den tunna klienten då. Det blev ett ganska stort lyft redan där. Det förändrade utseendet och lite av beteendet
på den befintliga applikationen. Och sedan tror jag att
det beslutet kom att vi skulle försöka satsa på en helt ny
klienttyp för att kunna hantera flera olika system, i och
med att vi har gått samman med Lawson och vi kommer förmodligen att gå samman med flera bolag. Då blir
det att man ackumulerar olika affärssystem. Då tog de ju
med sig erfarenheten från de här två tidigare projekten,
plus att de försökte vara visionärer då och tänka hur man
skulle kunna arbeta i framtiden.
4.3 Sammanfattning av empiri
4.3.1 Sammanfattning av intervjuer inriktade på teori
Lars Degerstedt
Lars Degerstedt betonade hur samspelet mellan att utforska problemrymd respektive lösningsrymd innebär en kreativ process, som
är särskilt viktig då det finns ett stort explorativt och innovativt inslag
i systemutvecklingen. Då fungerar det dåligt att analysera problemet
och ta fram lösningen i separata steg. Han menade att ur agil synvinkel är prototypen den första lösningen eller en skiss på lösningen.
Alternativt kan man tala om att man visar upp ett system under utveckling istället för att tala om prototyper. Innan man har en lösning
skulle man också kunna tala om att man utför prototypning när man
arbetar för att hitta en lösning. Ett sätt att uttrycka skillnaden mellan agila metoder och mer traditionella är att de traditionella arbetar
mer med prototyper i form av dokument, medan man i agil utveckling betonar prototypning som en kunskapsutvecklande process. Det
gäller såväl kunskap om det aktuella systemet som att bygga upp en
kompetens på sikt.
– 91 –
Dokumentation kommunicerar dåligt och kan inte står för sig själv
eftersom det viktigaste sker i huvudet på utvecklarna. Källkod och
dokumentation är sekundära i förhållande till den teori om problem
och lösning som utvecklarna bygger upp.
Arne Jönsson
Enligt Arne Jönsson kan lo-fi prototyper vara ett verktyg när man
arbetar med att utforma beställningen. Sedan kan man fortsätta
med hi-fi prototyper eller mer agilt med en prototyp som ska bli det
fungerande systemet, beroende på problemets art. Prototyperna kan
hjälpa beställaren att bättre förstå det problem som systemet som ska
utvecklas ska lösa. De framtida användarna kan man gärna ta in när
prototypningen kommit en bit på vägen, likaså användbarhetsexperter. När de kommer in beror mycket på om systemet vänder sig till
en bredare allmänhet eller inte. Man ska också komma ihåg att en
stor undersökning bland framtida användare inte kan ersättas med
en prototyp.
En spontan idé som dök upp under intervjun var att utifrån den
indelning som görs av Houde & Hill (1997) förbinda funktionsprototyper med samspelet mellan problem och lösning, medan designprototyper har mer med problemsidan att göra, och implementationsprototyper mer med lösningssidan.
T. Nilsson och A. Larsson
Prototyper kan vara ett sätt samla information om vad användarna
tycker. Det finns dock en risk att prototyparbetet växer för mycket i
omfattning, och omfattar sådant som lika gärna kunde verifierats i
det riktiga systemet istället. I samband med prototyper nämner man
särskilt «spikes» i eXtreme Programming som ett möjligt arbetssätt,
där man snabbt bygger något för att få svar på en fråga, och sedan
kastar bort prototypen.
Ska prototyper vara meningsfulla bör sättet att ta fram dem skilja sig
från den vanliga systemutvecklingen, inte ligga i rak linje med denna.
Istället bör prototypningen vara ett eget miniprojekt, till exempel när
man skissar ett användargränssnitt i ett ritprogram. Andra sätt att
använda prototyper är för jämföra alternativa förslag eller för att testa
enskilda aspekter, till exempel en algoritm.
– 92 –
På grund av svårigheten att i dokumentform fånga kunskapen som
utvecklas i samband med en prototyp är det viktigt att någon som
varit med där följer med till det team som ska bygga, om det är skilda
team. Motsvarande gäller om man ska arbeta vidare med något som
varit vilande.
Beroende på område kan prototyp innebära allt från enbart användargränssnitt till en första fungerande version av något. En svårighet
med mjukvara är att man saknar en produktionsfas, mjukvaror kopieras istället. Bygger man en fungerande prototyp går den i princip
att använda direkt, när tillräckligt mycket funktionalitet har implementerats. Detta ställer krav på disciplin i projekt, så att man inte
använder prototypkod av låg kvalitet i den riktiga produkten, särskilt
eftersom koden blir basen för fortsatt utveckling av produkten.
Den modell som framhålls är att man arbetar i sitt riktiga produktspår hela tiden, och visar upp produkten vid olika punkter längs vägen.
Man lägger till funktion för funktion. Det är särskilt viktigt att man
utför «hela varvet» i varje iteration, så att något med produktkvalitet
kan presenteras och generera återmatning inför nästa arbetscykel.
Inom DSDM har man tidigare talat mycket om prototyper, men skiljer
numera noggrannare mellan prototyper och tidig återmatning, vilket
det mestadels handlat om när man tidigare talat om prototyper.
4.3.2 Sammanfattning av intervjuer inriktade på praktisk
systemutveckling
Mårten Herberthson
En design är något som man kan rita upp på ett övergripande plan,
men sedan kodar man en prototyp när man kommer till detaljfrågorna. Designarbetet och prototypningen går parallellt och vävs samman. Normalt utvecklas prototypen till den färdiga produkten, men
kastas om man ser att man valt helt fel spår.
Happy days-scenario är ett arbetssätt, där man skapar en prototyp
med enklast möjliga kompletta flöde genom applikationen. På denna
prototyp kan man mäta till exempel om designen ger tillräcklig prestanda och skalbarhet för funktionaliteten. Därmed kan allvarliga
brister i designen upptäckas, samt att mätvärden kan användas som
en referens vid omdesigner i den fortsatta utvecklingen. Man ser till
att tidigt mäta sådant som innebär en stor risk för projektet; genom
– 93 –
en prototyp kan detta komma igång mycket tidigt. Detta är särskilt
viktigt när man gör något nytt som man inte har erfarenhet av.
Designar man för länge på papper blir det bortkastad tid, för när man
börjar koda kommer det saker man inte tänkt på. Däremot är design
på whiteboard bra när man ska skapa samsyn i ett projekt. För att få
en design att bli bra behöver man göra en prototyp, och då är steget
till att göra den till färdig produkt inte så stort. Arbetar man med
projekt där sena korrigeringar är särskilt dyra ökar relevansen av att
göra en detaljerad design på papper först.
En svårighet med designval är att de inte dokumenteras för att de
framstår som självklara för den som gjort valet. Därmed blir valet
starkt knutet till den personen.
Tomas Volavka
Att bygga en prototyp kan vara ett bra hjälpmedel för att stämma av
interaktion med användaren och integration med andra system på
ett annat sätt än när man bara skriver dokument. Det är som skillnaden mellan att prova att köra en bil och att läsa en broschyr om den,
man får en helt annan känsla.
När man tar fram användargränssnitt och funktionalitet kan man
använda en prototyp antingen internt eller för att visa upp för kunden. Detta kan vara en del av en försäljningsfas. Arbetar man tätt
tillsammans med kunden brukar det gå att få bra respons på prototyper. Däremot har de svårare att förstå skillnaden mellan prototyp
och färdig applikation.
För att prototyparbetet ska gå tillräckligt snabbt är det man producerar inte så väl genomarbetat, och man undviker att använda prototypkod i den riktiga applikationen.
Efter den inledande fasen utvecklas systemet utifrån de krav som
man kommit överens om, och kunden blir mer involverad igen när
man kommer till testfasen. Vid integration mot befintliga system blir
det mer kontakt med kunden under utvecklingen.
De som varit med i den förberedande fasen blir ett slags experter
för resten av gruppen som ska utveckla systemet, för att inte tappa
kunskap mellan faserna.
– 94 –
Karl-Göran Andersson
En prototyp innebär att en funktion realiseras. När något snabbt ska
skapas för att visas upp på en mässa till exempel handlar det snarare
om en attrapp. En prototyp är något som ligger närmare den färdiga
produkten.
Man kan använda prototyper för att få en mer fullständig bild av den
riktiga produkten. Att ändra i underlag är dyrbart, genom att prototypa först kan man reducera behovet av ändringar. Prototyper av
hårdvara kan användas för att kunna påbörja mjukvaruutvecklingen
tidigare.
Prototyparbete är ett sätt att kontrollera om idéerna håller. Det man
tar tillvara på från prototyparbetet är erfarenheterna, källkod återanvänds inte, i princip. Undantag är speciella algoritmer och liknande
som man tagit fram under prototyparbetet.
Använder man ny och oprövad teknik kan arbetssättet bli att man gör
ett antal olika prototyper innan den egentliga produktutvecklingen
kan börja. Gör man något som man redan är familjär med kanske
det inte behövs någon prototyp alls. Den som varit projektledare för
prototyparbetet bör följa med in i det riktiga projektet.
Det kan finnas mycket varierande förväntningar på hur nära den
slutgiltiga produkten en prototyp ligger i sin funktionalitet, vilket ger
utrymme för missförstånd. För något som ska visas upp för kunden
används begreppet demonstrator. Den skickar man inte till kunden,
utan man är själv med och demonstrerar den.
Michael Garrido
Prototyperna innehåller en mix av sådant som visar gränssnittet och
sådant som har en funktionalitet bakom också. Prototyperna görs i
en programmeringsmiljö. Det behövs en viss funktionalitet för att
användarna ska kunna ta det till sig och ge bra respons. Ofta sitter
man tillsammans med kunden, då märker man hur det fungerar och
får en bättre dialog. Att skicka ut en prototyp ger inte så mycket. Man
använder även prototyper för att kunde prestandatesta lösningar. Det
kan också vara ett sätt att prova ett annat angreppssätt än man brukar
använda. Produktutveckling ställer större krav på prototyparbetet än
kundanpassade fall.
– 95 –
Det är samma utvecklare som gör prototyper som gör det riktiga
systemet, för att utvecklaren ska få en bra förståelse för sammanhanget. Prototyper är också en naturlig brygga mellan användare och
utvecklare. Det skapar en samsyn som kan vara svår att åstadkomma
med beskrivningar i ord och även bild.
En svårighet är att få kunden att förstå att trots att prototypen ser ut
att fungera så är det mycket kvar att göra innan systemet är produktionsmässigt. Ett annat problem är att man lägger för mycket resurser
på en prototyp, genom att tillföra närliggande delar som egentligen
inte ingick i syftet.
Sådant som innehåller bra lösningar lyfts via en kodrevision in i det
riktiga utvecklingsspåret, medan resten kastas. Har man haft den
ambitionen från början kan det också gå att behålla hela koden (som
då går igenom en revision).
Ett arbetssätt man använder är att skapa block av funktionalitet i
små block om omkring 250 timmar. Då kan kunden ta del av hur
systemet ser ut när ett sådant block avslutats. Efter flera sådana block
har man ett slutblock där förändringar kan hanteras.
Peter Grew
I projektet gjordes tidigt körbara prototyper med multimediaverktyg,
för att ge en känsla av hur det skulle vara att köra systemet. I ett användargränssnitt på papper saknas interaktionen med användaren.
Den tidigare prototypen följdes snabbt upp med en liknande prototyp, men byggd i den tekniska målmiljön. Det gjordes flera iterationer på detta sätt, där utseende och beteende utvecklades växelvis
med det ramverk som man skulle ta fram. Med jämna intervall har
utvalda kunder provat det system som utvecklades. I slutet av projektet har man gått ut bredare till fler kunder. Tar man inte in kunderna
är risken att man får ett system som passar dem som utvecklar det
och inte kunderna.
– 96 –
4.3.3 Sammanfattning av intervju kring konstprojekt i
offentliga miljöer
Bo Olls
Beställarna har ofta luddiga idéer och det finns behov av att tydliggöra för dem själva vad de vill ha. Konstverk i offentliga miljöer ska
ofta stå kvar i många år, så ett långsiktigt tänkande behövs. Det gäller att tänka på även sådant som olika materials beständighet och att
göra något som andra kan gå in i och förändra längre fram i tiden.
Ett konstverk i offentlig miljö ska också passa i förhållande till sina
brukare, och behöver «säljas in» hos dem. När människor inte kan
undvika konsten måste man ta större hänsyn till hur de uppfattar
den, i det motsatta fallet kan man ta sig större friheter. När ett konstverk kommer nära inpå brukare behövs ett förankringsarbete som
man måste starta i början, inte när man kommit halvvägs.
I regel skriver man ett program innan man sätter igång, och detta
försöker man skriva så luddigt att det finns utrymme för förändringar. Man behöver anpassa till platsens konkreta förutsättningar, vilket
kan innebära en mängd förändringar jämfört med den ursprungliga
planen. Varje projekt är unikt, och det dyker alltid upp oväntade
komplikationer i processen.
Överföringen av information i projekt med många inblandade är
svår, alla tänker på sitt sätt. Man kan tackla denna problematik genom att någon som är väl insatt finns med under hela processen. Så
fort man blandar in människor som inte är tillräckligt informerade
finns det en stor risk att det blir fel.
– 97 –
– 98 –
5
Analys och diskussion
Detta kapitel syftar till att föra vidare den preliminära teoretiska
modell som presenterats i teorikapitlet och sätta den i relation till
empirin för att få svar på studiens frågeställningar.
5.1
Prototypbegreppet och
systemutvecklingsprocessen
5.1.1 Begreppet prototyp i teori och praktik
Redan i kapitel 3.1.1 såg vi att begreppet prototyp kan ha vitt skilda
innebörder beroende på vem som använder det. Detta visade sig i
den empiriska delen ställa till med problem i systemutvecklingsprojekt (se vidare kapitel 5.4). Några vanliga sätt att tolka begreppet är
följande:
en representation av en designidé
ett system under utveckling
en provisorisk version av en produkt
en färdig version av en produkt, tillverkad i ett enstaka exemplar
Även begreppet prototypning visar sig ha olika nyanser:
arbetet med att utveckla en prototyp
en metod för systemutveckling
5.1.2 Vidareutveckling av den teoretiska modellen
Till att börja med har jag åter riktat blicken mot de grundläggande
dimensionerna i min modell. Det jag kommit fram till är det bästa
sättet att beskriva det som sker i processerna som har att göra med
axeln problemrymd–lösningsrymd är kunskapsutveckling. Att arbeta
med problemrymden respektive lösningsrymden är bägge sätt att utveckla kunskap i ett systemutvecklingsprojekt. I övrigt behåller jag
de tidigare begreppen. Den förändrade teoretiska modellen återfinns
i figur 15.
Som jag nämnt tidigare (kapitel 4.3.1) uppstod i en av intervjuerna en
idé om hur den indelning som lagts fram av Houde och Hill (1997)
skulle kunna kombineras med den teoretiska modell som presenterats. Summan av perspektiven kan beskrivas enligt följande:
– 99 –
problemrymd
kunskapsutveckling
lösningsrymd
designer/utvecklare
prototyp(ning)
användare/intressent
informationsbehov
verksamhet
it-system
Figur 15. Den tredje iterationen av den teoretiska modellen.
prototyper av utseende och beteende används för att få en upp-
fattning om verksamhetens informationsbehov och hur man kan
organisera ett motsvarande användargränssnitt,
prototyper av systemets roll eller funktionalitet är ett sätt att
tränga djupare in i informationsbehovet och samtidigt se närmare på tänkbara lösningar,
med implementationsprototyper provar man ut realiseringar av
lösningar för större eller mindre delar av ett system. (Se kapitel 3
för bakgrund.)
Den kompletterade modellen ser därmed ut som följer (se figur 16):
För att göra modellen mer konkret har jag även tagit fram kategorier
av prototyper som hör ihop med någon av de tre aspekter som just
har beskrivits. För varje aspekt tar jag upp två slags prototyper, som
visar på olika möjliga riktningar att arbeta i. Det finns inga anspråk
på att dessa riktningar är de enda möjliga, utan de visar just exempel
på möjliga arbetssätt med prototyper. En kort beskrivning av de olika
arbetssätten följer:
– 100 –
roll
problemrymd
kunskapsutveckling
lösningsrymd
designer/utvecklare
utseende & beteende
implementation
prototyp(ning)
användare/intressent
informationsbehov
verksamhet
it-system
Figur 16. Den teoretiska modellen kompletterad med tre slags prototyper utifrån Houde & Hill (1997).
utseende och beteende i gränssnittet kan modelleras med mindre
eller större likhet med målsystemets utseende och beteende, där
lo-fi innebär en låg grad av likhet och hi-fi innebär en hög grad
av likhet,
roll och funktionalitet kan prototypas genom att ett utsnitt av
systemet prototypas, och där djupet varierar från att gå genom
samtliga skikt i form av en vertikal prototyp eller mer ytligt genom färre skikt i form av ett scenario,
en implementationsprototyp kan användas för att testa en en-
skild aspekt av ett system, men systemet som helhet kan också
användas som en prototyp.
Ett slags prototyp som med avsikt utelämnats i modellen är horisontella prototyper. Visserligen används de främst för att prototypa utseende och beteende, men de används även på sätt som har mer med
systemutveckling i sig att göra, och inte så mycket med prototypning.
(Se kapitel 3.2.4)
Därmed har vi kommit fram till den fjärde iterationen av den teoretiska modellen i denna studie (se figur 17).
– 101 –
Figur 17. Den teoretiska modellen med exempel på olika slags prototyper.
– 102 –
Lo-Fi
utseende & beteende
Hi-Fi
informationsbehov
verksamhet
användare/intressent
prototyp(ning)
it-system
lösningsrymd
kunskapsutveckling
problemrymd
designer/utvecklare
vertikal prototyp
roll
scenario
visa upp systemet
implementation
utvecklingsskott
5.2 Agil och traditionell systemutveckling
I de inledande intervjuerna inriktade på teori blev det tydligt att man
inom agil utveckling fokuserar på att visa upp ett körbart system
under utveckling, och inte en prototyp som är något separat i förhållande till detta. Sedan kan man välja att med Gulliksen och Göransson (2002) eller Houde och Hill (1997) utifrån olika infallsvinklar
betrakta systemet under utveckling som en prototyp.
Sett från en annan synvinkel kan man säga att man inom agil utveckling mer betonar prototypning som aktivitet (till exempel reguljär
utveckling eller utvecklingsskott) där kunskap utvecklas tillsammans
med användare, medan man inom traditionell systemutveckling har
en starkare betoning av prototyper som dokument (till exempel bilder
av systemet) som utvärderas av användare. Observera distinktionen
mellan prototyp och prototypning i detta sammanhang! (Se figur
18.)
Ytterligare något som skiljer agil utveckling från traditionella angreppssätt är att man inte fryser kravmängden i projektens början,
utan har metoder för att ta tillvara krav genom i princip hela projektförloppet (se time-boxing i kapitel 3.3.2). Därmed får prototypning
som ett sätt att samla krav betydelse under hela projektet. Detta hör
även samman med att man i varje iteration skapar något av produktkvalitet, som ger underlag för återkoppling från användare och andra
intressenter.
– 103 –
Figur 18. Den teoretiska modellen med tendenserna till dokument
respektive aktivitet tillagda.
– 104 –
Lo-Fi
utseende & beteende
Hi-Fi
dokument
informationsbehov
problemrymd
scenario
verksamhet
användare/intressent
prototyp(ning)
designer/utvecklare
kunskapsutveckling
roll
it-system
lösningsrymd
vertikal prototyp
visa upp systemet
implementation
utvecklingsskott
aktivitet
I följande tabell sammanfattas viktiga skillnader mellan agil och traditionell systemutveckling med avseende på prototypanvändning:
Tabell 3: Skillnader mellan agil och traditionell systemutveckling
utvecklingsmodell
agil
traditionell
återkoppling på prototyper från
kravställare/användare regelbundet under hela projektet
ja
nej
typ av prototyp
ordinarie utvecklingsspår
eller utvecklingsskott,
körbar
separat utvecklingsspår, i form
av dokument
Jag har här valt att lyfta fram en aspekt som hör samman mer med
utvecklarnas värld, och en som hör samman mer med användarnas
och kravställarnas värld. Därmed ringas viktiga skillnader in utan att
det blir onödigt komplext i förhållande till syftet med denna studie.
Som man även kan se hör de agila angreppssätt som valts ut hemma på den högra sidan av modellen, medan de traditionella lägger
tyngdpunkten på den vänstra sidan.
När det gäller regelbunden återkoppling under hela projektet representeras det i modellen av den stora cirkeln: när man arbetar enligt en agil modell följer man ett ständigt kretslopp genom cirklen,
medan den traditionella modellen innebär att man vanligtvis gör ett
enda varv genom cirkeln.
5.3 Prototyper och systemutveckling i praktiken
Några skarpa skiljelinjer mellan agilt och traditionellt angreppssätt i
systemutveckling är svåra att dra, det finns självklart gråzoner. Men
jag anser att det ändå finns tydliga tendenser som kan beskrivas.
Först följer en sammanställning av resultaten, sedan mina kommentarer kring dessa.
– 105 –
5.3.1 Resultat
Tabell 4: Sammanställning av resultat
intervjuperson
typ av prototyp
återkoppling under projekt
MH
ordinarie utvecklingsspår i första
hand
TV
utvärdering sker bland projektmedlemmarna under
projektet; kunden kommer in
senare i formella granskningssteg
separat utvecklings- vanligtvis inte, men integraspår, inriktat på uttion mot befintliga system
seende och beteende kan kräva tätare kontakt under projektet
KGA
MG
PG
ett separat utvecklingsspår som liknar
ordinarie utveckling,
och sedan «slängs»
lite återkoppling, produkterna
är noggrant specificerade
innan den egentliga produktutvecklingen sker
separat spår och
ordinarie spår som
utvecklas växelvis
utvalda kunder provar systemet med jämna intervall, mot
slutet av projektet går man ut
bredare till fler kunder
separat spår som
regelbunden återkoppling
delvis återanvänds
från kund i slutet av utvecktill ordinarie utveck- lingsblock
lingsspår
Det finns stora skillnader mellan vilken typ av system de olika intervjupersonerna utvecklar, och därför är det föga förvånande att spridningen i resultat också är stor. Avsikten med urvalet var också att få
en bred bild över området.
När det gäller att prototypa i ordinarie utvecklingsspår respektive
i ett separat spår ligger tonvikten på att använda ett separat spår.
Men det finns flera mellanformer där det ordinarie utvecklingsspåret
trots allt finns med i bilden, så att man kan tala om utvecklingsskott
snarare än ett separat spår. Sammanfattningsvis verkar det inte finnas något utbrett tydligt agilt inslag på denna punkt, men samtidigt
förekommer arbetsformer som trots allt går i den riktningen.
– 106 –
När det gäller att få återkoppling på prototyper från kravställare/
användare regelbundet under projektets gång var det två intervjupersoner som berättade om ett sådant arbetssätt. Där fanns alltså ett
tydligt inslag av agila metoder på den punkten, även om arbetssättet
inte är utbrett av detta material att döma.
5.3.2 Gränsdragningar
Något som gör det svårt att tydligt särskilja hur man använder prototyper i en utvecklarorganisation är att olika projekt skiljer sig åt med
avseende på ett flertal egenskaper, och detta påverkar vilka metoder
man väljer att använda. Visserligen borde ett agilt eller traditionellt
perspektiv leda till skilda val, men genom att den grundläggande synen på prototyper och systemutveckling vägs samman med egenskaper hos varje konkret projekt är det svårt att veta vilken betydelse
olika faktorer har. En studie som omfattar ett större material borde
kunna hantera detta dilemma bättre.
Ett konkret exempel kan vara kundens förväntningar och önskemål.
Kanske gör man ett avsteg från sina vanliga rutiner vid användning
av prototyper helt enkelt för att tillmötesgå kundens önskemål.
5.4 Råd för användning av prototyper i
systemutveckling
De två problem med prototyper som flera gånger kommer fram i
intervjuerna är:
det blir missförstånd angående hur nära en färdig produkt pro-
totypen är,
prototypen får eget liv och blir ett för omfattande projekt.
Den första typen av problem handlar om kommunikation och kanske kan förbättras genom förändringar i terminologin. Här vill jag
påminna om Anders Lotssons förslag (se kapitel 3.1.1) att reservera
ordet prototyp för sådant som fungerar. Utifrån de problem som
nämnts i intervjuerna skulle jag till och med vilja skärpa detta till att
begreppet prototyp bör begränsas till sådant som inte bara fungerar,
utan dessutom fungerar väl. Om det är så man ser på begreppet prototyp från beställarsidan kan det vara en god idé för systemutvecklare att anpassa sig till detta. Lotsson (2001) nämner de alternativa
begreppen attrapp och modell, som man kan använda där de passar
– 107 –
in. I intervjuerna kom även begreppet demonstrator fram som ett alternativ som används. Detta begrepp pekar på att man demonstrerar
något, vilket innebär att man gör något tillsammans med kunden. Om
man istället lämnar över något till kunden att utvärdera på egen hand
ökar risken för missförstånd.
När det gäller prototyper som drar till sig för mycket resurser vill
jag påminna om vikten av att en prototyp används för att besvara en
designfråga (se kapitel 3.1.1). Det gäller att hålla denna fråga i fokus,
och inte tillföra nya frågor bara för att de ligger nära prototypen.
Något som nämns mera som ett potentiellt problem är att någon
person som varit med i prototyparbetet bör följa med in i resten av
projektet. Annars kan viktig kunskap om verksamheten och prototypen gå förlorad på vägen. Detta ligger i linje med Naurs iakttagelse
att dokumentation till sin natur är ofullständig (se kapitel 3.4.1).
En annan sida av prototyper som nämns av flera intervjupersoner är
vikten av att använda prototyper när man gör något nytt och oprövat.
Allt kan inte bedömas korrekt vid ritbordet, utan man behöver den
lärprocess som arbete med prototypning kan ge.
5.5 Konstprojekt jämfört med systemutveckling
De problem som visar sig i konstprojekt kring utsmyckning i offentliga miljöer är remarkabelt lika de man möter i systemutveckling.
Här följer en lista över några framträdande likheter:
beställarna vet inte från början riktigt vad de vill ha,
att skapa något som långsiktigt kan anpassas och utvecklas i
framtiden är ingen trivial uppgift,
projektet måste förankras hos brukarna tidigt i processen,
projektet behöver ha spelrum för oförutsedda förändringar,
överföring av information inom projekt med många inblandade
och många led som informationen ska passera är svårt,
människor ser samma sak utifrån olika perspektiv och missförstår
varandra,
idealet är att samtliga inblandade har en förståelse för projektet
som helhet.
– 108 –
I konstprojekt är det mer eller mindre en grundprincip att varje
projekt är unikt. Detta gör det oerhört svårt att förbereda sig på de
komplikationer som kommer att dyka upp i ett enskilt projekt. Inom
systemutveckling finns det ett större spektrum av större eller mindre
grad av unikhet i olika projekt. I systemutvecklingsprojekt där man
bryter ny mark eller gör något som man saknar erfarenhet av blir
följden att man liksom i konstprojekten måste ha förmågan att anpassa sig längs vägen.
– 109 –
– 110 –
6
Slutsats
I detta kapitel presenteras kortfattat resultatet av studien.
Innebörden av begreppet prototyp
Prototyp är ett begrepp som har många olika innebörder beroende
på vem man frågar. Detta gäller även om man begränsar sig till systemutvecklingens område. Att olika personer uppfattar ordet olika
bidrar till att missförstånd uppstår. Denna studie har kommit fram
till rekommendationen att reservera ordet prototyp för sådant som
redan är väl fungerande, eftersom man från beställarhåll verkar ha
den föreställningen om prototyper. I övriga fall kan man använda
andra begrepp som förslagsvis attrapp, modell eller demonstrator.
Prototyper i systemutvecklingsprocessen
Denna studie har tagit upp begreppet problemlösning som en grund
för att förstå systemutveckling, och i förlängningen även prototypernas roll i systemutvecklingsprocessen.
Ett förslag till teoretisk modell för prototyper i systemutveckling har
tagits fram som bygger vidare på Peter Naurs förståelse av systemutveckling som teoribyggande och Houde och Hills tre dimensioner
för prototyper. Modellen visar hur olika konkreta sätt att använda
prototyper hör samman med systemutvecklingsprocessen. (Se figur
19.)
Modellen är tänkt att kunna användas som en kompass för prototyper/prototypning, en hjälp att se åt vilket håll man går och att ta ut
en ny riktning. Modellen ger en bredare överblick över området än
de tidigare arbeten som den bygger på samtidigt som den integrerar
dessa arbeten. Begreppen problemrymd och lösningsrymd ger redan i
sig själva en hjälp att förstå systemutveckling bättre, och kopplingen
till olika slags prototypanvändning gör dessutom denna förståelse
pratkiskt tillämplig på ett enkelt sätt.
Prototyper inom agil respektive traditionell systemutveckling
Till skillnaderna mellan användandet av prototyper i agil respektive
traditionell systemutveckling hör följande:
– 111 –
scenario
roll
vertikal prototyp
dokument
aktivitet
problemrymd
kunskapsutveckling
lösningsrymd
utvecklingsskott
Hi-Fi
designer/utvecklare
utseende & beteende
implementation
prototyp(ning)
användare/intressent
visa upp systemet
Lo-Fi
informationsbehov
verksamhet
it-system
Figur 19. Den teoretiska modellen så långt den utvecklats i studien.
agil utveckling prioriterar prototyper i form av körbara system,
agil utveckling prioriterar prototypning som aktivitet, medan
traditionell utveckling har större fokus på prototyper som dokument,
agil utveckling prioriterar att göra prototypning i det ordinarie
utvecklingsspåret, medan traditionell utveckling oftare har ett
helt separat prototypspår,
prototypning används för att få återkoppling från användare/
intressenter regelbundet under hela projektet i agil utveckling,
medan traditionell utveckling samlar in samtliga krav i början på
projektet.
Genomslaget för agila metoder med avseende på prototyparbete
Frågan om genomslaget för agila metoder i prototyparbete har undersökts utifrån två aspekter, nämligen om prototyparbetet sker i det
– 112 –
ordinarie utvecklingsspåret samt om återkoppling på prototyper sker
regelbundet under systemutvecklingsprojektets gång.
Resultatet är sammanfattningsvis att det förekommer agila inslag på
dessa områden, särskilt med avseende på regelbunden återkoppling
på prototyper.
– 113 –
– 114 –
7
Avslutning
I detta kapitel finns reflektioner kring studien, samt förslag till
framtida forskning.
Reflektion
En stor behållning för mig har varit den fördjupade förståelse av systemutveckling som blivit följden av att skärskåda prototyper. Det har
blivit tydligt för mig att det faktum att systemutveckling arbetar med
mer eller mindre abstrakta konstruktioner är något som ger området särskilda egenskaper och svårigheter. Den positiva sidan av detta
är att om man väl kan skapa sig en klar föreställning om en tänkbar mjukvara har man redan tagit det första steget mot att realisera
denna! Den negativa sidan är att man inte utan vidare kan bibringa
någon annan sina föreställningar. Vi tänker olika och även samma
ord (som till exempel «prototyp») uppfattas väldigt olika. Jag tror att
mycket är vunnet redan genom att man är medveten om dessa olika
egenskaper man har att göra med i systemutveckling.
Något som klarnat för mig är hur unikt varje systemutvecklingsprojekt kan vara, och vad detta får för konsekvenser för hur man arbetar
och vilka problem man stöter på. Teknikens utveckling bidrar till
detta, då man kanske har erfarenhet av att göra en viss typ av system,
men att skillnaderna ändå kan bli stora då en ny teknik ska användas.
Ett annat spår som jag blivit uppmärksam på är kreativitet och innovation inom systemutveckling. Prototypning är ett område där man
har tillfälle att prova olika möjligheter och angreppssätt, vilket ger ett
spelrum för kreativitet och att finna helt nya lösningar.
Något som kanske kunde gjorts annorlunda är själva kvantiteten av
empiri. Med totalt nio intervjuer mellan 45 minuter och två timmar
i längd har det varit ett väl omfattande material för mig att arbeta
med. Andra delar av studien kan ha blivit lidande på grund av detta,
eller så kan de ha vunnit på att omfattningen inte blev ännu större!
Framtida studier
Då jag inriktat mig på systemutvecklarnas syn på prototyper skulle
det vara intressant att studera ett användarperspektiv och/eller ett
– 115 –
beställarperspektiv. Detta blir särskilt intressant då det visade sig finnas problem med olika syn på hur pass produktfärdig en prototyp
är.
När det gäller den teoretiska sidan vore det intressant att veta mer
om beröringspunkter mellan användarcentrerad systemdesign och
agila utvecklingsmetoder. Båda har till exempel som princip att användarna ska vara djupt involverade i utvecklingsprocessen. Finns det
fler beröringspunkter och kan utvecklingsmetoderna berika varandra
respektive kombineras?
– 116 –
8
Begreppslista
DSDM
Dynamic Systems Development Method, en utvecklingmetod med
urspring i RAD. Arbetssättet är iterativt och inkrementellt.
eXtreme Programming
En systemutveckingmetod som skapts av Kent Beck och räknas till
de agila metoderna. Metoden är känd för att ha lanserat parprogrammering som ett arbetssätt.
Handlingsbarhet
Ett it-systems förmåga att ge stöd för användare att utföra handlingar både genom systemet och utifrån systemet baserat på dess information.
HCI
Human-Computer Interaction, människa-dator interaktion
Lean production
Lean production har sitt ursprung i Toyota Production System, där
grunden är att skapa ett resurssnålt och effektivt produktionssystem
Macromedia Director
Verktyg för att skapa multimedia
Rapid Application Development
En process för mjukvaruutveckling som introducerades 1991 av James Martin. Processen är iterativ och prototypning är central.
Stateful/Stateless model
Stateful innebär att en komponent har ett tillstånd/status, medan det
motsatta gäller för en komponent som är stateless.
UI
User Interface, användargränssnitt.
– 117 –
– 118 –
9
Källor
Ambler, Scott W. (2002), Agile Modeling: Effective Practices for
eXtreme Programming and the Unified Process. New York, USA:
John Wiley & Sons, Inc.
Ambler, Scott W. (2004), The Object Primer – Agile Model-Driven
Development with UML 2.0, tredje upplagan. Cambridge Cambridge: University Press.
Andersen, Erling S. (1994), Systemutveckling – principer, metoder och
tekniker. Studentlitteratur: Lund.
Beck, Kent et al (2001a), Manifesto for Agile Software Development.
(Elektronisk) Tillgänglig: <http://www.agilemanifesto.org/>
(2007-05-28)
Beck, Kent et al (2001b), Principles behind the Agile Manifesto.
(Elektronisk) Tillgänglig: <http://www.agilemanifesto.org/principles.html> (2007-05-28)
Bischofberger, Walter & Pomberger, Gustav (1992), PrototypingOriented Software Development: Concepts and Tools. Berlin:
Springer-Verlag.
Bryan-Kinns, Nick & Hamilton, Fraser (2002), One for all and all
for one? Case studies of using prototypes in commercial projects. I
Proceedings of the second Nordic conference on Human-computer
interaction NordiCHI ´02; 19–23 oktober 2002; Århus, Danmark;
ss. 91–100.
Bäumer, Dirk, Bischofberger, Walter R., Lichter, Horst, Züllighoven, Heinz, User interface prototyping – concepts, tools and experience. I Proceedings of the 18th international conference on Software engineering; 25–29 mars 1996; Berlin, Tyskland; ss. 532–541.
Cockburn, Alistair (2006), Agile Software Development: The Cooperative Game, Second Edition. USA: Addison-Wesley.
Computer Swedens ordlista (2007). (Elektronisk) Stockholm: IDG
Media.
•• Design. Tillgänglig: <http://cstjanster.idg.se/sprakwebben/ord.
asp?ord=design> (2007-04-24)
•• Programmering. Tillgänglig: <http://cstjanster.idg.se/sprakwebben/ord.asp?ord=programmering> (2007-05-06)
Cunningham, Steve (2002), Graphical problem solving and visual
– 119 –
communication in the beginning computer graphics course. I Proceedings of the 33rd SIGCSE technical symposium on Computer science
education SIGCSE ´02; 27 februari–3 mars 2002; Cincinnati,
Kentucky, USA; ss. 181–185.
Eastman, E. Grant (2003), Fact-based problem identification precedes
problem solving. I Journal of Computing Sciences in Colleges, Volume 19 Issue 2, Consortium for Computing Sciences in Colleges.
Ehn, Pelle (1988), Work-Oriented Design of Computer Artifacts. Almqvist & Wiksell International: Stockholm.
Encyclopædia Britannica (2007). (Elektronisk) Chicago, USA: Encyclopædia Britannica, Inc.
•• Problem solving: thought. Tillgänglig: <http://search.eb.com/eb/
article-15083> s. 11 (2007-04-21)
•• Personal computer. Tillgänglig: <http://search.eb.com/eb/article-9002247> (2007-05-08)
Evans, Eric (2004), Domain-driven design: tackling complexity in
the heart of software. USA: Addison-Wesley.
Goldkuhl, Göran (1998), Kunskapande. Internationella Handelshögskolan i Jönköping och CMTO, Linköpings universitet.
Gulliksen, Jan & Göransson, Bengt (2002), Användarcentrerad systemdesign – en process med fokus på användare och användbarhet.
Lund: Studentlitteratur.
Houde, Stephanie & Hill, Charles (1997), What do Prototypes Prototype? i M. Helander, T.Ê Landauer, & P. Prabhu (eds.), Handbook of Human-Computer Interaction (2nd Ed.). Amsterdam:
Elsevier Science B. V. Sidnumren för figurerna refererar till det
särtryck som finns tillgängligt elektroniskt. Tillgänglig: <http://
www.viktoria.se/fal/kurser/winograd-2004/Prototypes.pdf>
(2007-03-18)
Högskolan i Borås (2007), Guide till Harvardsystemet. (Elektronisk)
Borås: Högskolan i Borås. Tillgänglig: <http://www.hb.se/blr/
harvard/genhar.asp> (2007-05-08)
Leventis, Petros & Tomazic, Ann-Christin (2001), Tillämpning av
prototyper i Rational Unified Process. Magisteruppsats vid Handelshögskolan vid Göteborgs universitet, Institutionen för informatik. Göteborg: Göteborgs universitet.
– 120 –
Lichter, Horst, Schnedier-Hufschmidt, Matthias, Züllighoven,
Heinz (1994), Prototyping in Industrial Software Projects – Bridging the Gap Between Theory and Practice. I IEEE Transactions on
Software Engineering, Volume 20, Issue 11, IEEE Press, Piscataway, NJ, USA.
Lotsson, Anders (2001), Rätt ord för bransch och industri. Computer
Sweden, 2001-06-01.
Lundahl, Ulf & Skärvad, Per-Hugo (1999), Utredningsmetodik för
samhällsvetare och ekonomer. Lund: Studentlitteratur.
Mumford, Enid (1998), Problems, knowledge, solutions (invited session): solving complex problems. I Proceedings of the international
conference on Information systems ICIS ´98; 13–16 december 1998;
Helsingfors, Finland; ss. 447–457.
Nationalencyklopedin (2007). (Elektronisk) Höganäs: Bra Böcker.
•• Programmering. Tillgänglig: <http://www.ne.se/jsp/search/article.jsp?i_art_id=287453> (2007-05-05)
•• Prototyp. Tillgänglig: <http://www.ne.se/jsp/search/article.jsp?i_
art_id=287850> (2007-03-12)
Naur, Peter (1985), Programming as Theory Building. Citerad från
Computing: A Human Activity, ACM Press 1992 s. 37–48 av
Cockburn, Alistair (2006), Agile Software Development: The Cooperative Game, Second Edition. USA: Addison-Wesley.
Nilsson, Kenneth (2007), Systemutveckling. (Elektronisk) I Nationalencyklopedin. Tillgänglig: <http://www.ne.se/jsp/search/article.
jsp?i_art_id=322209> (2007-05-06)
Poppendieck, Mary & Poppendieck, Tom (2003), Lean Software
Development – An Agile Toolkit. USA: Addison-Wesley.
Repstad, Pål (1999), Närhet och distans – Kvalitativa metoder i samhällsvetenskap. Lund: Studentlitteratur.
Responsive (2007), Responsive. (Elektronisk) Tillgänglig: <http://
www.responsive.se/> (2007-05-28)
Schneider, Kurt (1996), Prototypes are Assets, not Toys. I Proceedings
of the 18th international conference on Software engineering; 25–29
mars 1996; Berlin, Tyskland; ss. 522–531.
Schwaber, Ken & Beedle, Mike (2002). Agile Software Development
with Scrum. USA: Prentice Hall.
– 121 –
Schwaber, Ken (2004). Agile Project Management with Scrum. Redmond, USA: Microsoft Press.
Svenska språknämnden (2000), Svenska skrivregler. Stockholm: Liber AB.
Wiktorin, Lars (2003), Systemutveckling på 2000-talet. Lund: Studentlitteratur.
– 122 –
10 Länktips
Manifesto for Agile Software Development:
http://www.agilemanifesto.org/
Alistair Cockburn har i sin bok (2006) Agile Software Development
tagit med texter av Peter Naur och Pelle Ehn, som även är tillgängliga på följande adress:
http://alistair.cockburn.us/index.php/ASD_book_
extract:_%22Naur,_Ehn,_Musashi%22
Göran Goldkuhls skrift Kunskapande finns tillgänglig på följande
adress:
http://www.vits.org/?pageId=10&pubId=409
Visioner vid vatten, skulpturen Dubbelgångaren:
http://www.visionervidvatten.se/dubbelgangaren.htm
Wikipedia om prototyper:
http://en.wikipedia.org/wiki/Software_prototyping
Samtliga länkar tillgängliga 2007-05-28.
– 123 –
– 124 –
Fly UP