Modeller

Introduktion till modeller

Utvecklingen av mer och mer avancerad programvara genom åren, har tvingat fram mer och mer raffinerade metoder för att samordna den personal och de resurser som ingår i ett programvaru projekt. För att kunna hantera de större mängderna ingående element och för att styra arbetsgången i de stora teamen som utgör en utvecklings enhet, måste man kunna ställa upp långsiktiga mål och bestämma vilka vägar som ska man ska ta sig dit på. Det som man kallar modeller utgör ett slags kartor över den väg man väljer. Man brukar också beskriva modellerna som en bild av en programvaras livscykel, hur den skapas, underhålls o.s.v. Liksom i allt övrigt finns det inte ett enkelt svar på hur man ska ta sig fram till sitt mål. För att kunna välja rätt väg måste man ha en bra förståelse för vad problemet består i, något som inte alltid är självklart.

En modell har som syfte att ge ramar till de som ska utveckla programvaran, och olika modeller passar olika uppgifter. Men det finns ofta ett visst generellt mönster i hur man bygger upp en lösning på problemet, som går igen i alla steg i processen. Delarna i detta mönster kan benämnas defenition, applicering av någon form av teknologi och integration av lösningen. Den lösningsgången tillämpas på såväl projektet i sin helhet, som på varje enskild komponent och funktion i programvaran. Mönstret upprätthålls inte helt intakt, men lyser ofta igenom i de olika modellerna.

Linjära modeller

Linjära sekventiella modellen (LSm)

Detta är den äldsta och mest etablerade modellen, även kallad vattenfalls modellen eller den klassiska livscykeln. Modellen anpassar det klassiska sättet att ingenjörsmässigt lösa ett problem till mjukvaru utvecklingens villkor. Modellen behandlas oftast som en helt linjär process, även om den ursprungliga modellen som ställdes upp av Winston Royce, hade inslag av feedback och iteration.

Man börjar med analys av problemet, går vidare till design av lösningen, kodar d.v.s. programmerar, levererar lösningen och utför sedan eventuellt löpande underhåll. Det är nästan uppenbart att det sällan går att följa modellen till punkt och pricka, eftersom det oftast uppstår någon form av problem eller svårighet på vägen som är beroende av ändringar i ett föregående steg. Det kan t ex. vid kodningen visa sig att man inte kan lösa ett problem, som då måste omformuleras i ett analyssteg och sedan sättas in i en ny form av programvaran. Fördelarna med modellen är att den är väl etablerad och utprövad till vissa typer av projekt. Genom att lägga till feedback loopar får man en modell som är mer flexibel och kan användas för mindre projekt med klart definierade mål och förutsättningar. Klara mål och förutsättningar är dock inte vanliga i början på ett projekt och det är ju då som analysen utförs. Dessutom lider modellen av att varje föregående steg måste vara slutfört innan nästa påbörjas.

Modellen är mer ett textboks exempel, än ett lämpligt alternativ för att utveckla större delar i ett projekt. Det är väl snarast det sämsta alternativet näst smått kaotisk improvisation.

Vattenfalls modellen följer ett helt linjärt koncept, utan möjlighet att gå tillbaka och ändra i tidigare steg.

Prototyps modellen (Pm)

Denna paradigm leder till skillnad från LSm till att alla inblandade processer kommer igång snabbare, och att man får chansen att räta till misstag och ändra utförandet av lösningarna. Man utför i nära samarbete med kunden en inledande analys av vad programvaran ska utföra, hur den ska uppträda och hur den ska användas. Sedan gör man en prototyp, en ofullständig version av den slutliga produkten och låter alla inblandade parter yttra sig om hur prototypen verkar arta sig. Därefter slutförs projektet med ytterligare en iteration, där man tagit med de problem/mål/förutsättningar som framkommit efter utvärderingen av prototypen. Prototypen kastas bort och används inte mer.

Fördelarna med denna modellen är att kunden får en känsla för hur den slutliga produkten kommer att se ut, och därmed kan ändra sina krav och önskemål. I LSm är det ofta svårt för kunden att kunna precisera sina målsättningar tillräckligt tydligt i början, och utvecklarnas uppfattning av vad som ska åstadkommas kan visa sig vara skild från beställarens. Med Pm får både kunden och utvecklarna något att ta tag i snabbare. Nackdelen är att kunden kan missförstå syftet med prototypen, som oftast är långt ifrån en bra produkt, och kräva att man istället för att göra en riktig version, endast fixar till det nödvändigaste. Prototypen, som var menad som ett snabbt hopplock att fundera över, kan ofta inte klara av att hantera det som förväntas av den färdiga programvaran. En ytterligare fara ligger i att man på grund av tidsbrist, kostnadsskäl eller ren glömska inte byter ut de delar av projektet som inte når upp till de krav som blivit uppställda. När det då förflutit lite tid kan det visa sig att lösningar, som är allt annat än ideala, har blivit en integrerad del i programvaran och därmed kan utgöra en svag länk eller flaskhals.

Modellen har starka fördelar, men man utvecklar en prototyp som senare inte kan användas, vilket gör den ganska ineffektiv i längre tidsaspekter.

Prototypsmodellen innehåller ett inslag av vidareutveckling, som ger möjlighet att göra om de delar som inte fungerade i den ursprungliga lösningen.

Rapid Application Development modellen (RADm)

Ytterligare en variant av LSm, ofta använd för informationssystem eller 'vanliga' applikationer som inte ska användas i kritiska system. RADm är en high-speed modell som syftar till att få fram den färdiga produkten inom tre till fyra månader. Liksom i LSm måste man ha klart uppställda mål redan från början, eftersom man i RADm följer den enkelriktade arbetsordningen till punkt och pricka. Genom att man använder gamla projekt, och delar av redan utförda projekt, när man utvecklar den nya programvaran sparar man in tid och arbete. Med hjälp av utvecklingsverktyg som samordnar arbetet effektivt, gör man ytterligare tidsbesparingar (se 4GT nedan). Man återanvänder i största möjliga mån komponenter som redan utvecklats, och om man inte har önskad funktionalitet avdelar man ett separat RAD-team till att utveckla komponenten. Komponenten kan senare användas i framtida projekt.

Tidsbesparingen ställer dock stora krav på att alla inblandade i RAD-teamet är tillräckligt disciplinerade och utför sina uppgifter inom de givna tidsramarna. Man måste också ha tillräckliga personalresurser för att kunna bilda flera RAD-team, om man behöver göra många nya komponenter. Återanvändandet av gammal kunskap kan också inverka på prestandan, då man inte får en lösning som är helt anpassad till problemet. Det kan också leda till säkerhetsproblem och driftstörningar, därför används RADm mer sällan i situationer där man måste ha friktionsfritt samarbete mellan programvarans alla delar och resten av systemet, eller där man använder nya teknologier som ännu inte testats fullt ut.

RADm är en metod som snabbt får fram fungerande programvara, men ställer höga krav på utvecklarna, och passar inte i kritiska system. För att snabbt få fram godtagbara applikationer är det dock en metod som kan vara lämplig, förutsatt att man kan avgränsa målen tydligt.

Evolutionära modeller

Evolutionära modeller bygger på att den färdiga produkten utvecklas och förfinas under flera steg. Genom att låta programvaran passera genom LSm flera gånger, får man större möjligheter till kontroll och ändringar.

Incremential modellen (Im)

Modellen bygger på att man bygger flera fullt fungerande versioner av samma programvara, fast lägger till ökad funktionalitet för varje iteration. Man går igenom LSm-processen och levererar en kärnprodukt med grundläggande funktioner, som till skillnad från Pm är en stabil och användbar produkt. Därefter påbörjas nästa version med eventuella ändringar och ännu en passage genom LSm stegen tar vid. Efter ett antal versioner har man lagt till alla de funktioner och egenskaper som man föresatt sig.

Fördelen med Im är att man kan färdigställa en fungerande produkt snabbt även om man har begränsade personalresurser. Kunden kan snabbt få en programvara som kan sättas in i systemet och komma i bruk. Genom att leverera delmål kan eventuella ändringar och förfiningar smygas in utan att man ändrar på hur det fungerar i kärnan av programvaran. Nackdelen med den här modellen är att det kan ta tid om det är många delmål som ska åstadkommas.

Modellen är bra för projekt där man måste få fram en skelett produkt och en prototyp inte kan leva upp till de krav som ställs.

Den inkrementiella modellen har en elegant lösning, som ger stora möjligheter för revision och modifiering. Genom att göra flera fungerande versioner av programvaran, bygger man ut dess funktionalitet.

Spiral modellen (Sm)

Sm kombinerar kontrollen från LSm och den iterativa egenskapen hos Pm. Den liknar Im, eftersom man även här går igenom LSm stegen i flera iterationer, men istället för att efter varje genomgång leverera en fungerande, men inkomplett, version utvecklas den färdiga produkten via flera utökande steg. Efter första genomgången utvecklas en pappersprodukt som de inblandade parterna kan lämna synpunkter på. Efter ännu en vända kanske en prototyp tillverkas. Vid nästa vända ytterligare en förfinad prototyp, som kanske kan användas i väntan på den helt färdiga produkten o.s.v. Efter att ha snurrat runt i LSm stegen ett par gånger, ständigt förbättrande programvaran har man till slut fått fram det slutliga resultatet. För varje snurr i spiralen uppdateras tids- och kostnadsplanerna, vilket ger en bra överblick på hur projektet framskrider.

Sm är den modell som de flesta större projekt följer, eftersom den ger relativt bra möjligheter att göra ändringar i programvaran. Baksidan på medaljen med evolutionära modeller är att det finns risk att man skjuter de problem som kan uppstå på framtiden. Eftersom kodningen av programvaran kommer in ganska sent i processen, kan det visa sig att planerna kan behövas göras om i grunden. Förhoppningsvis ska sådana problem dock fångats upp i tidigare iterationer. Det finns också risk att man kan tvingas pussla ihop lite nödlösningar, om det visar sig att man inte planerat tillräckligt bra i början på projektet.

Spiralmodellen börjar vid 1:an, och processen tar sig sedan vidare i utvecklingens steg till 2:an o.s.v. Ju längre från origo man kommer desto mer funktioner läggs till, och desto mer utvecklad blir programvaran. I varje varv kan man ändra och uppdatera planeringen.

Framtidsmodeller

Dessa är inte modeller i egentlig mening, snarare verktyg och regler som används mer och mer, och därför förtjänar ett omnämnande.

Formella metoder

Egentligen ingen modell utan snarare ett sätt att genom rigorös och komplicerad matematik hitta fel i algoritmer och programvara. Med hjälp av en speciell matematisk notation kan inkonsekvenser, tveksamheter och brister upptäckas och rättas till innan man tar programvaran i bruk. Formella metoder är en mycket dyr och tidskrävande process, som främst används i säkerhetskritiska system i stil med kärnkraftverk, flygindustri och liknande.

Fourth Generation Techniques (4GT)

Ett sätt att utveckla programvara där problemställningen behandlas på en mycket hög, generell nivå. Man använder ofta grafiska verktyg för att koppla samman lösningarna i programvaran, och återanvänder komponenter från tidigare lösningar. Verktygen kan ofta automatiskt generera programkod utifrån givna förutsättningar, och man använder 'spreadsheets' eller tabeller för att styra och anpassa de ingående komponenterna. Tekniken är användbar för mindre projekt och används numer ganska flitigt. Invändningar mot 4GT är att den kod som genereras ofta inte är ideala lösningar på problemen. Se även RADm.

Extreme Programming (XP)

En uppsättning regler och riktlinjer som ofta går stick i stäv med de vederlagda konventionerna. Till exempel anser XP att man inte ska skriva mer generell kod än nödvändigt, eftersom man har tillräckligt att tänka på med det nuvarande uppgiften, utan att behöva tänka på framtida situationer. Vidare ska man testa koden väldigt ofta och bryta mot planeringen om det visar sig att man kan göra en uppgift på ett annat sätt. XP bygger en del på Im, och sätter kodningen i fokus mer än vad de flesta andra modeller gör.