Steg 3: Support och underhåll
Reaktiv, proaktiv och prediktiv
Support kan göras på tre olika sätt beroende på hur involverade Strikersoft ska vara. Den kan vara reaktiv där vi åtgärdar fel som användarna rapporterar. Supporten kan vidare vara proaktiv vilket innebär att vi även åtgärdar saker som inte direkt påverkar driften, men som har påverkan på längre sikt. Prediktiv support innebär slutligen att vi agerar på kritiska fel innan de har uppstått. Mer information finns här >>
Driftsprocess
För att hantera underhållet finns en driftsprocess som sköter automatiska backuper och övervakning så att inte systemet går ner. Om det ändå skulle hända något finns i driftsprocessen en beskrivning av hur eskalering ska ske för att snabbast möjligt åter få systemet i drift.
Nivåer i övervakning
Kunden bestämmer alltid på vilken nivå övervakningen ska ske. Nivån beror på vilken nertid som är acceptabel i systemet. En högre nivå på övervakningen, och därmed mindre nertid, innebär t.ex. att man har dubblerade system i varje datahall, har flera datahallar om någon slås ut, dubblerade diskar i varje server eller använder virtuella maskiner som backup.
Senast giltiga versionen
Det agila arbetssättet med sprintar och kontinuerliga uppdateringar av produktens specifikation innebär att underhållet sker på den senast giltiga versionen av den levererade produkten. Det är mot den man ställer eventuella felrapporter under supportfasen och inte mot idén man hade vid projektets start.
Agilt underhåll
Det agila arbetssättet innebär också att utvecklarna alternerar mellan olika delar i processen. När det kommer nya krav på produkten efter lanseringen innebär det att dessa krav snabbt kan plockas in och bli en del av den totala koden.
Det vanliga är annars att för varje ny bit kod som adderas så förstörs gradvis den logiska och överskådliga strukturen i koden som initialt finns, för att slutligen bestå av en kod som är helt omöjlig att följa eller förstå för en utomstående. Alla som hört om eller själva sett så kallad ”spagettikod” inser vad detta innebär. Det agila arbetssättet behåller istället en väldokumenterad kod som går att bygga vidare på.
Se de andra stegen i utvecklingsprocessen:
