Utvecklingsmodeller

Livscykelmodellen är ett vanligt sätt att beskriva ett system från det att beslut tas om införandet av ett nytt system tills dess att systemet avvecklas (Andersen, 1994).

44

Förändrings- analys

Analys Utformning Realisering Implementering Förvaltning och drift

Avveckling Systemutvecklingsprocess

Figur 4. Livscykelmodellen med systemutvecklingsprocessen markerad (Andersen, 1994).

Bild 1 visar var i livscykeln som systemutvecklingsprocessen äger rum. I dagsläget finns ett flertal olika modeller för att bedriva systemutveckling. Möjligheten att bedriva användbarhetsarbete kan påverkas beroende på vilken av dessa arbetsmodeller man väljer för utvecklingsarbetet.

Vattenfallsmodellen

Systemkrav Mjukvarukrav Analys Programdesign Kodning Testning Drift Figur 5. Vattenfallsmodellen (baserad på bild i Gulliksen och Göransson, 2002).

Vattenfallsmodellen är en av de äldsta modellerna och används fortfarande. Den bygger på att hela systemet byggs på en gång och föregående steg avslutas innan nästa påbörjas. Fullständig

dokumentation fungerar som stoppkriterium för varje fas. Många nyare och mer effektiva utvecklingsmodeller har sin grund i vattenfallsmodellen.

Fördelarna med vattenfallsmodellen är att den är enkel och lätt att följa. De olika faserna har kriterier både för att påbörjas och avslutas och utförs i ordning. Eftersom den funnits i många år är den välbekant och den gör det enkelt att fördela personal på grund av de olika strikta faserna. Vidare fungerar vattenfallsmodellen bra för mindre projekt med väl kända och förstådda krav (Braude och Bernstein 2010).

Nackdelarna med vattenfallsmodellen är att systemkraven måste vara kända i förväg, vilket ofta är svårt. Många gånger startar ett projekt med en viss osäkerhet som klarnar allt eftersom projektet fortskrider. Det är också svårt att göra tillförlitliga beräkningar då beräkningar tenderar att bli mer exakta allt eftersom. Vidare saknas möjligheter för intressenterna att ta del av resultatet förrän efter testfasen, vilket är väldigt sent. Större problem blir inte heller synliga förrän sent i processen då tiden som finns att korrigera felen är kort. Detta kan ge enorma följder för tidsplaner och kostnader. Vattenfallsmodellen gör det också omöjligt att utveckla olika delar av systemet parallellt. Även om det är lätt att fördela personal, riskerar man också att personalen kan bli sittandes medan de väntar på att saker ska bli färdiga (Braude och Bernstein 2010).

Även Budde et al. (1992, se Gulliksen och Göransson 2002, s. 141) kritiserar Vattenfallsmodellen eftersom de anser att:

 _{det inte går att formulera en fullständig och oföränderlig kravspecifikation innan}

utvecklingsprocessen börjar

 specifikation, design och konstruktion inte kan ses som separata arbetssteg

 tung, komplex och formell dokumentation oftast är obegriplig för både användare och utvecklare

45

Iterativ och inkrementell utveckling

De steg som ingår i vattenfallsmodellen är viktiga. Problemet är att det är svårt att samla alla krav, designa hela systemet, skriva all kod och sedan testa hela systemet i en linjär process. Det är mer naturligt att utvecklingen sker cykliskt genom att en del av systemet utvecklas och testas. Baserat på resultat och feedback på denna del utvecklar man ytterligare en del av systemet tills hela systemet är klart. I en iterativ utvecklingsprocess upprepar man helt eller delvis stegen i vattenfallsmodellen vilket leder till en förfining av krav, design och implementation. En iterativ process blir inkrementell om varje iteration är relativt liten. Cockburn (1994) beskriver en inkrementell utveckling som en strategi som tillåter delar av ett system att utvecklas vid olika tidpunkter eller i olika takt och som sedan integreras allt eftersom delarna blir klara (Braude och Bernstein 2010).

Gulliksen och Göransson nämner följande fördelar med den inkrementella utvecklingsmodellen:

 Projektstyrningen blir mer hanterbar för varje inkrement eftersom delprojekten är mindre.

 Det är lättare att förstå och testa inkrement med mindre funktionalitet.

 _{Man har möjlighet att lägga till användarkrav, som är ett resultat av tidigare versioner, i}

framtida versioner. Designen är lättare att anpassa under utvecklingens gång.

 Initiala funktioner utvecklas snabbare och successivt byggs ny fungerande funktionalitet.

 _{Avsättning för investeringar syns tidigare.}

 _{Mjukvara som levereras som inkrement kommer med större sannolikhet att möta}

förändrade krav än om hela systemet levereras i slutet av utvecklingsprojektet.

Exempel på iterativa och inkrementella modeller är Spiralmodellen, Unified Software Development Process (USDP) och Rational Unified Process (RUP) som utvecklats av IBM (Braude och Bernstein 2010).

Agila metoder

Man har med tiden utvecklat metoder som anses vara mer flexibla än den traditionella

vattenfallsmetoden. Dessa metoder brukar kallas agila metoder och agil betyder lättrörlig eller vig. Agil systemutveckling kan ses som ett paraplybegrepp för ett flertal olika metoder där SCRUM är ett välkänt exempel. Andra metoder är Adaptive Software Development, Crystal, DSDM, Extreme Programming (XP), Lean Software Development och Pragmatic Programmer (Eriksson, 2005). År 2001 började en grupp som kallar sig Agile Alliance att diskutera olika sätt att förbättra mjukvaruutveckling. Målet var att skapa värderingar och principer som skulle leda till att

utvecklingen gick snabbare och som effektivt skulle kunna anpassas till förändringar. De värderingar och regler som de kom fram till kallas Manifesto for Agile Software Development eller Agile

Manifesto. Huvudpunkterna i det agila manifestet lyder:

 Individer och interaktioner framför processer och verktyg

 _{Fungerande programvara framför omfattande dokumentation}  Kundsamarbete framför kontraktsförhandling

 Anpassning till förändring framför att följa en plan

De agila metoderna är iterativa och inkrementella. Vanligtvis uppfyller de följande:

46

 Regelbundna, ofta förekommande möten gällande krav.

 En kodcentrerad inställning, dokumentation bara när det anses nödvändigt.

 _{Kundrepresentanter arbetar tillsammans med teamet.}

 User-stories utgör basen för kraven; fullständiga beskrivningar av hur användarna utför uppgifter.

 Refactoring, vilket innebär att förbättra källkoden på ett sådant sätt att funktionaliteten inte förändras. Detta görs främst för att underlätta underhåll.

 Parprogrammering, där två programmerare hjälps åt.

 Fortlöpande uni-test (test av små delar, t.ex. en metod) och acceptanstester.

Fördelarna med agila metoder är att det finns fungerande programvara att visa upp då utfallet av varje iteration är fungerande mjukvara. Vidare är det motiverande för utvecklarna att få arbeta mer med kod än med dokumentation. Kunderna har också en möjlighet att ställa bättre krav då de kan se hur systemet växer fram.

Nackdelarna med de agila metoderna är att de kan vara olämpliga för större projekt. Det är vanligare att använda agila metoder för mindre projekt och det pågår debatt om lämpligheten för större projekt. Det finns också en risk för att nödvändig dokumentation inte tas fram, då dokumentationen inte prioriteras (Braude och Bernstein 2010).

När vi läser vad Gulliksen och Göransson (2002, s. 110) skriver om vikten av att arbeta iterativt och inkrementellt som en del av den användarcentrerade arbetsprocessen, drar vi slutsatsen att de agila metodernas principer stöder ett arbetssätt som gynnar användbarhet.