Systemutvecklingsmodeller

I en undersökning som publicerades 1996 (Bäumer et al) var följande en av de trender som man kunde iaktta:

Traditional life-cycle approaches are being replaced by evolutionary strategies in projects focused on building user-friendly systems. Prototyping is today an establis- hed part of these evolutionary strategies. (Bäumer et al 1996)

Här ser vi hur begreppen användarvänlig, evolutionära strategier och prototypning sammanförs. För att bättre förstå vad det handlar om ska vi se närmare på olika systemutvecklingsstrategier eller -model- ler.

Jag tar upp vattenfallsmodellen som ett exempel på en traditionell strategi inom systemutveckling, som kontrast till agil utveckling. Ci- tatet ovan och liknande utsagor gjorde mig intresserad av vilken roll användarcentrerad systemdesign har i sammanhanget, därför finns det även ett avsnitt om den.

3.3.1 Vattenfallsmodellen

Den modell för problemlösning som Polya har föreslagit (se kapitel 3.1.5) har inspirerat en fasindelning av systemutveckling enligt föl- jande: specifikation,  analys,  konstruktion,  provning. (Wiktorin 2003) 

Denna fasindelning är mycket vanlig och innebär en naturlig ord- ningsföljd mellan momenten, som fått beteckningen vattenfallsmo- dellen. Tidiga varianter på denna modell föreskrev att arbetet i en fas skulle vara klart innan man fortsatte till nästa fas. I praktiken brukar man behöva gå tillbaka till föregående fas på grund av brister som vi- sar sig. Det senare är det gängse arbetssättet idag. (Wiktorin 2003) En mer omfattande variant av vattenfallsmodellen är livscykelmo- dellen (se Figur 6). Viktiga punkter i detta synsätt är att användarna

ska analysera sig fram till sina önskemål, och att detta ska göras inn- an utformningen av systemet påbörjas. Analysfasen är särskilt viktig; om den utförs dåligt blir hela informationssystemet dåligt vad man än gör senare i projektet. Till exempel när problemställningarna för- ändras hela tiden kan livscykelmodellen vara mindre lämplig. Där- emot passar den väl för stabila verksamheter, till exempel när man flyttar över manuella rutiner till ett informationssystem. (Andersen 1994)

3.3.2 Agil utveckling

Inom agil utveckling finns det många olika metoder och angrepps- sätt med en gemensam kärna av värden som uttrycks i det agila ma- nifestet:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more. (Beck et al 2001a)

För- ändrings-

analys

Analys Utform-

ning Realise-ring menteringImple- ning och Förvalt- drift Avveck- ling Systemering Systemutveckling Livscykel Valda u tveck lingså_tgärd er Kravs pecifi_katio n Realis_erbar t info rmatio nssyst_em Färdig t info rmatio nssyst_em Infört _infor matio nssyst_em Figur 6. Livscykelmodellen. (Figur efter Andersen 1994, s. 48)

Inom agil utveckling undviker man att ha ett långt avsnitt i början av projekt där man utförligt slår fast samtliga krav i detalj. Istället växer kraven fram och utvecklas under projektets gång. Om såväl kraven som den teknik som ska användas är väl kända och förstådda skulle ett mjukvaruprojekt kunna följa ett linjärt förlopp. Men i den ut- sträckning som det finns oklarheter kring krav eller teknik – och det brukar det finnas gott om – ökar projektets komplexitet, och ett an- nat arbetssätt behövs. Istället för att enbart staka ut en färdriktning i början av projektet måste denna kontinuerligt anpassas utifrån vad man upptäcker under arbetet. (Schwaber & Beedle 2002)

För att hantera krav på ett rationellt sätt utan att behöva frysa dem helt använder man inom den agila metoden Scrum något som kallas för time-boxing. Det innebär att man fryser kraven under en be- stämd tid, då utvecklarna får arbeta i fred. En enda person, exem- pelvis projektledaren eller produktansvarig, ansvarar för vad som ska utföras i nästa time-box. Den personen hanterar listan med krav och prioriterar mellan dessa. (Schwaber 2004)

Centralt för agil utveckling är att underlätta samverkan mellan kund/ beställare och utvecklare. (Wiktorin 2003)

Användare har lättare att förstå fungerande programvara än doku- ment som beskriver programvaran. Därför arbetar man inom agil utveckling med att skapa fungerande program tidigt och ofta i ett projekt. Man behöver också ta hänsyn till att förändringar hör till i mjukvaruutveckling: villkoren för en verksamhet förändras, teknik förändras över tid. Intressenternas förståelse av systemet förändras. Man behöver ha en projektplan, men samtidigt lämna ett spelrum för förändringar av denna. (Ambler 2002)

Det tillhör de grundläggande principerna inom agil utveckling att personer från verksamheten och utvecklare arbetar tillsammans dag- ligen genom hela projektet. (Beck et al 2001b)

3.3.3 Användarcentrerad systemdesign

Användarcentrerad systemdesign fokuserar på användare och an- vändbarhet under hela utvecklingsprocessen. Systemet utvecklas evolutionärt med den typ av iterationer som beskrivs i figur 7. Proto- typer används tidigt i projektet och under hela dess förlopp. Målet är

att visualisera och utvärdera designlösningar tillsammans med slut- användarna. (Gulliksen & Göransson 2002)

Inom användarcentrerad systemdesign rekommenderas att man bör- jar med prototyper i form av enkla pappersskisser och konceptuell design på hög nivå. Man lägger stor vikt vid att designförslagen ut- värderas mot mätbara användbarhetsmål som satts upp för projektet. (Ibid.)

En målsättning är att skapa en delad förståelse bland alla inblandade parter. Därför behövs en representation av designen som ger använ- darna en konkret bild av hur det är att använda systemet, samtidigt som den behöver vara effektiv för utvecklarna. (Ibid.)

Alla delar av systemet ska utvecklas parallellt, kontinuerligt och i ett sammanhang med varandra. Detta gäller allt från användargränssnitt till handböcker och arbetsmiljöaspekter. På så vis kan man uppnå en integrerad systemdesign. (Ibid.)

3.4 Att förstå systemutveckling

För att förstå prototypernas roll i systemutveckling behöver man också förstå systemutveckling. Därför ägnas följande kapitel åt frå- gor kring vad systemutveckling är för något.

3.4.1 Peter Naur

Vad är egentligen systemutveckling, vad går det ut på? I första hand kanske man tänker på det system som produceras, i form av specifi- kationer, dokumentation av olika slag samt programkod. Med detta

Analys av användarna, arbetsuppgifter och användningssammanhang

Designförslag med prototyper – i sig en iterativ process som beskriver det kreativa arbetets natur Utvärdering med

mätningar mot användbarhetsmål Återkoppling med förslag till förändringar

Användarfokus, mätbar användbarhet och iterationer

Figur 7. Grundelementen i en iterativ användarcentrerad process. (Figur efter Gulliksen & Göransson 2002, s. 109)

tänkesätt är systemutvecklarens uppgift främst att producera dessa olika artefakter. En person som lagt fram ett alternativ till detta syn- sätt på sådana frågeställningar är dansken Peter Naur, en förgrunds- figur inom dansk datalogi.

Naurs forskning har sin bakgrund i svårigheten att förklara vissa pro- blem utifrån det Naur kallar för ett produktionsperspektiv på pro- gramutveckling; alltså att produktionen av vissa artefakter är centralt i programutvecklingsprocessen. Två typiska fenomen som kan belysa detta är de problem som hänger samman med att rätta programkod som innehåller fel, respektive att modifiera program. (Naur 1985) I detta sammanhang använder Naur begreppet programmering, men säger tydligt att han avser hela raden av aktiviteter från utformning på olika nivåer till implementation av mjukvara. Jag väljer här istäl- let att använda ordet programutveckling när jag refererar Naur, efter- som programmering enligt min mening lätt kan förknippas med att «skriva kod» i mer inskränkt bemärkelse. (Se Naur 1985 samt kapitel 3.1.4 i denna studie)

Naur ser programutveckling som att man får symbolmanipulering som kan utföras av ett datorprogram att överensstämma med en del och aspekt av något i den riktiga världen. Med dessa begrepp som bakgrund blir det tydligt att förändringar i den riktiga världen måste motsvaras av en ofrånkomlig aktivitet i programutvecklingen, näm- ligen att man modifierar program. (Naur 1985)

Att program behöver modifieras är alltså inte någon «extra» aktivitet utanför programutvecklingen, utan ingår som en normal del i denna. Därmed är det också tveksamt om man någonsin kan se programut- vecklingsprojekt som fullständigt avslutade.

Den huvudtes som Naur driver är att programutveckling i första hand sker i form av att programutvecklaren bygger upp en kunskap av ett särskilt slag. Denna kunskap är primär, medan till exempel varje form av dokumentation utgör en yttre sekundär produkt. Detta kan hjälpa oss att förstå varför det är så svårt att bygga ut befintliga program, även när dessa är väldokumenterade och byggda enligt sunda princi- per för programutveckling. (Naur 1985)

Utifrån ett produktionsperspektiv på programutveckling är det na- turligt att anta att man bör kunna modifiera eller utöka program till en låg kostnad. Detta skulle isåfall stå i motsättning till förändring

av andra komplicerade konstruktioner som till exempel byggnader, där rivning och nybyggnation ofta är mer ekonomiskt fördelaktigt än ombyggnation. Ser man programutveckling som en form av text- produktion – att datorprogram redigeras som en form av texter in- bjuder till det – är det naturligt att tänka att utökning av ett program handlar om skrivandet av ytterligare ett tämligen litet antal rader text (programkod). Men då tar man miste. Programutveckling hanterar i själva verket synnerligen komplicerade konstruktioner. (Naur 1985) En möjlig jämförelse för ett mindre utvecklingsprojekt skulle kunna vara en lärobok där olika kapitel skrivits av olika författare. Inför en ny upplaga låter man någon författare skriva till ett kapitel om till exempel ny teknik som kommit fram. Kanske behöver förfat- taren inte ens läsa resten av boken, och kostnaden inskränker sig till kostnaden för det nyskrivna kapitlet, som helt enkelt läggs till i bo- ken. Då stämmer ett rent produktionsperspektiv, och kostnaden för förändringen är låg. Men det kan också vara så att den nya tekniken har betydelse för innehållet i samtliga kapitel i boken, som plötsligt blivit föråldrade. Då står man inför valet att omarbeta hela boken från grunden eller att låta skriva en ny bok, där bägge alternativen är väsentligt dyrare än att bara lägga till ett kapitel. Skulle man trots att stora delar av boken blivit föråldrade välja att bara lägga till ett nytt kapitel blir resultatet en bok av lägre kvalitet, som inte längre uppfyl- ler sitt syfte lika väl. Upprepas detta 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 systemutveck- ling. Nedan följer några av hans kommentarer kring Naurs idéer. Den kunskap som utvecklas vid systemutveckling kan beskrivas som en form av tyst kunskap hos utvecklarna. Det rör sig om en förståelse

av å ena sidan det behov eller problem som finns i verksamheten, å andra sidan av hur detta kan tillfredsställas eller lösas. Dessutom tillkommer förståelsen av hur dessa bägge sidor svarar mot varan- dra. En samstämmighet mellan dessa båda sidor är nödvändig för att skapa it-system av god kvalitet. När en utvecklare kommer in senare hänger kvaliteten på hans arbete på att hans förståelse av det befint- liga systemet överensstämmer med förståelsen hos dem som byggt systemet. (Cockburn 2006)

3.4.2 Pelle Ehn

Pelle Ehn lyfter fram två utvecklingstendenser inom mjukvaruut- veckling:

en

 teoretisk utveckling mot ett processorienterat humanistiskt pa- radigm,

en

 teknisk utveckling mot kraftfulla miljöer för prototypning. (Ehn 1988)

Det nya teoretiska perspektivet handlar om att fokusera på lärande och kommunikation vid både användning och utveckling av mjuk- vara. Kvaliteten hos mjukvara bedöms i detta perspektiv inte enbart utifrån dess överensstämmelse med en kravspecifikation, utan man ser till dess relevans och ändamålsenlighet i praktiska användnings- situationer. Följden blir att mjukvaruutveckling inte kan ses som en rad faser ordnade i tiden där formella dokument förfinas allt mer för att slutligen mynna ut i ett system. Istället ser man den som en fortlöpande process där design, implementation och utvärdering sker i cykler i kontexten av den arbetsprocess där mjukvaran ska användas. Designartefakter som exempelvis prototyper används för att under- lätta kommunikation och samarbete, där man steg för steg kommer underfund med systemet. (Ibid.)

När det gäller de nya tekniska möjligheterna med prototyper ser Ehn många användningsområden. Det han ser som den centrala frågan är: innebär prototyperna att användarna får möjlighet att experimen- tera med olika prototyper, så att de kan samla erfarenhet som en grund för designkrav? (Ibid.)

Byggt på denna grund ser Ehn framför sig möjligheten till ökad kreativitet och ett större inslag av användardeltagande vid systemut- veckling. (Ibid.)