Förvaltning börjar med krav och slutar med test

Denna artikel publicerades ursprungligen av Konsultbolag1. Sedan 2020 har verksamheten gått ihop med inUse (part of AFRY). Vi har sedan dess kunnat erbjuda ett spännande urval av kurser inom de samspelande områdena kravhantering, test, design och effektkartläggning under inUse Academy.

Vi har också sett att det kan vara både roligt och utmanande men vi har också fått erfara att det nästan alltid är projekten medarbetarna och företagen själva helst pratar om, och kanske framför allt det som många medarbetare vill arbeta med. Många gånger är det så att förvaltningarna knappast ens tilldelas de resurser som behövs, ingen riktigt känner ansvar för viktiga uppgifter som kravhanteringen och testarbetet eller har fått rätt förutsättningar för att genomföra arbetsuppgifterna.

Vi vill i den här artikeln beskriva varför vi tycker att förvaltningsarbete är något av det viktigaste som ditt företag arbetar med och varför en bra kravhantering och ett bra testarbete är A och O för att skapa en kostnadseffektiv och kvalitativ förvaltning.

Vad är förvaltningsarbete?

För att underlätta förståelsen vid läsandet vill vi först beskriva vad vi menar med förvaltningsarbete.

Förvaltningsarbete kan för enkelhets skull beskrivas som ett projektarbete utan en tydlig startpunkt eller slutpunkt. Förvaltningsarbete kan bedrivas både som en linjefunktion för att hantera stående förvaltningar, vilket är vanligt för förvaltning av IT-infrastruktur, PC-klienter et cetera, eller i en projektliknande matrisorganisation där medarbetare från både verksamhet och IT samlas i en förvaltningsorganisation vilket är mer vanligt för förvaltning av IT-system.

Den huvudsakliga skillnaden mellan projekt och förvaltning är att projektet fokuserar på att leverera mot ett fastställt mål på en fastställd tid med en fastställd budget medan förvaltningen utgår från ett antal olika rättningar, anpassningar och förbättringar som behöver införas i en release av ett IT-system och utgående från detta underhåll och vidareutveckling får förvaltningen en årsbudget att arbeta med. När en release är klar påbörjas planeringen med nästkommande release då, i princip, alla IT-system har kontinuerliga behov av rättningar, anpassningar för förbättringar för att möta de behov som organisationen har vid varje enskilt tillfälle.

Förvaltningen ansvarar även för att drifta de system som de förvaltar så att verksamheten och användarna har tillgång till dem och kan utföra sina arbetsuppgifter. En förvaltning kan också ansvara för renodlad nyutveckling som kan hanteras som mini-projekt inom ramar för förvaltningsbudgeten. Förvaltning ansvarar även för att säkerställa utbildningar och användarstöd för användarna efter anpassningar, förbättringar och nyutveckling. Man brukar ofta prata om RAFS när det gäller en förvaltnings olika utvecklingsuppdrag, vilket står för Rättning, Anpassning, Förbättring och Sanering.

Detta innebär att det både finns tydliga skillnader och tydliga likheter mellan förvaltningar och projekt, och att det finns gråzoner om vad som är vad och varje företag måste bestämma utgående från sina förutsättningar om vad som är vad.

Förvaltning och kravhantering

Hur fungerar då kravhantering inom en förvaltning - skiljer det sig åt mot hur det fungerar inom projekt? Svaret är "både ja och nej ".

Skälet till att det både skiljer sig och att det inte skiljer sig åt gällandes hur du måste arbeta med dina krav och behov mellan förvaltningar och projekt kommer från det faktum att du har en existerande kravmassa att förhålla dig till, nedskriven eller inte, vilket kan både underlätta och komplicera arbetet. Du kanske behöver skriva ett antal nya krav, uppdatera ett antal andra krav eller ta bort ett antal krav som inte längre är giltiga över huvud taget efter den önskade förändringen.

Att krav finns att förhålla sig till kan göra det enklare, men om de befintliga kraven är av lägre eller rent av obefintlig kvalitet och förändringen är stor eller komplex kan detta vara ett tidsödande jobb som kräver en hel del analys. Men det är en analys som ändå behövs för att utvecklarna ska kunna skapa förändringen kodmässigt. I detta fall kommer det arbete du behöver utföra för att beskriva en korrekt kravställning skilja sig rätt mycket åt mot hur du hade arbetat i ett projekt för nyutveckling.

En komplicerande faktor är självklart att kravdokumentationen kan vara lagrad på olika sätt för olika objekt men även för ett och samma objekt. Detta beror vanligen på att system växer fram över tiden och hur vi hanterar och lagrar vår dokumentation förändras på samma sätt. Du kan inte helt förlita dig på att all kravdokumentation för ett system under förvaltning finns tillgänglig på ett och samma ställe och inte ens att den är beskriven på ett och samma sätt. Det innebär att du måste ta reda på och ha tillgång till all kravdokumentation för ett system när du ska hantera den nya kravuppgiften så att du kan göra en korrekt analys av förändringar, nya tillägg och borttag av enskilda krav och kravgrupper. Ett inte helt ovanligt scenario kan dessutom vara att det finns kravdokumentation för delar av ett system medan det för andra delar av systemet inte finns kravdokumentation eller att det är känt att den inte är uppdaterad och gällande. I vissa lägen är det dock inte känt om det är den gällande dokumentationen du har fått tag i, och det kanske är svårt att ens från koden helt säkerställa om befintlig kravdokumentation är giltig eller inte. Det kan då vara bättre att bortse från den och ta fram ny kravdokumentation som man vet stämmer och är helt uppdaterad med vad som är önskad funktionalitet än att basera sin kravanalys på ett felaktigt underlag.

När du ska kravställa funktionalitet till ett system som inte alls existerar sedan tidigare så blir arbetet i stort som inom ett projekt där du kan fokusera på det nya kravområdet. Självklart finns det fortsatt krav som du måste förhålla dig till, exempelvis de krav som beskriver angränsande funktionalitet eller de förutsättningar som finns för det system som den nya funktionaliteten ska inkluderas i. Eftersom det är ett befintligt system så finns det självklart vanligen relativt mycket kunskap att bygga på och oftast beställare som vet ganska väl vad de faktiskt behöver och önskar. Men i huvudsak blir arbetet med kravställning detsamma som du skulle ha utfört mot ett helt nytt system och skiljer sig därför, i all väsentlighet, inte mot vad du hade gjort inom ett projekt för nyutveckling.

Eftersom vi vill säkerställa att vi bara genomför de förändringar av ett system som verkligen behövs är det också mycket viktigare att en nyttovärdering av varje förändring genomförs så att de förändringar som ger mest nytta till lägst kostnad prioriteras högst. Vid nyutveckling är detta inte riktigt lika viktigt då vi tittar mer på hela projektet nyttomässigt och kostnadsmässigt och inte enskilda behov och krav, även om de bör vara prioriterade inbördes.

Förvaltning och testarbete

Är det då när vi börjar med testarbetet som de stora skillnaderna uppstår? Nja, det är fortsatt så att det finns både likheter och skillnader men i huvudsak är nog likheterna större än skillnaderna.

En av de stora skillnaderna blir när du ska testa en förändring av befintlig funktionalitet. Det räcker inte med att testa själva förändringen utan du måste även fundera på vilka andra delar som kan vara påverkade av förändringen och testa dessa delar också. När sen alla enskilda förändringar är testade bör du självklart utföra ett samlat regressionstest över hela systemet för att säkerställa att ingen sent inkommen förändring har brutit någon funktionalitet över huvud taget. Självklart är det så att de ingående förändringarna påverkar hur mycket regressionstest du behöver utföra och vilka av dina regressionstester som är relevanta att genomföra. Men själva testarbetet förändras inte direkt. Du kommer fortsatt planera och driva ditt testarbete på i huvudsak samma sätt. Skillnaden ligger i hur du väljer ut vad som ska testas och att du i större utsträckning har testfall som redan täcker det som ska testas än vad du har vid projektdriven nyutveckling.

En annan del som skiljer sig åt när du ska testa förändringar är att du även måste testa frånvaron av funktionalitet ibland. Du måste nämligen även säkerställa att de krav som helt är borttagna får önskad påverkan, det vill säga den beskrivna funktionaliteten är borttagen, på det system du håller på att testa, och inte bara de krav som är förändrade eller de som är tillagda.

När du testar förändringar av befintlig funktionalitet behöver du sällan fundera på vilka testtyper som är relevanta utan i huvudsak kommer du använda dig av de testtyper som du har beskrivit i din teststrategi för systemet och som du har använt dig av tidigare under förvaltningsarbetet. Självklart kommer även omfattningen av förändringen du testar påverka vilka testtyper från din teststrategi som du verkligen väljer för den enskilda förändringen. En enkel förändring av ett användargränssnitt där ytterligare informationsfält har lagts till kanske medför att du bedömer att du inte behöver testa om prestandan eller genomföra några säkerhetstester. Du måste dock alltid fundera och aktivt välja bort de testtyper, som finns genomgångna i din teststrategi för systemet, och som inte är relevanta för den enskilda förändringen och dess påverkan på systemet.

Om det systemområde du ska testa är helt nyutvecklat så blir skillnaden egentligen ingen alls. Du kommer att planera och genomföra dina tester på i stort sett samma sätt som du skulle ha gjort om du deltog i ett rent nyutvecklingsprojekt. Du hade självklart planerat in regressionstester i slutet av testarbetet för att säkerställa att det du testade inte har förändrats medan andra delar har tillkommit. Skillnaden är antagligen bara att du inkluderar regressionstester för ytterligare andra systemområden också. Till skillnad mot när du testar förändring av funktionalitet kan dock helt nyutvecklad funktionalitet medföra att du måste förändra din teststrategi då just dessa systemförbättringar är de som kan medföra att du behöver fundera på prestandatester, på säkerhetstester eller på någon annan testtyp som du inte haft med i dina tester tidigare.

Självklart är det så att testfallen i sig behöver uppdateras i förhållande till de förändringar som ska testas. Testfall kan både behöva förändras, läggas till och tas bort. Att bara hitta alla relevanta testfall kan vara en utmaning då de kan ha lagrats på olika ställen och i olika verktyg över åren. Detta är även det en av de stora skillnaderna mot projekt där du kan fokusera på att ta fram testfall och inte behöver lägga tid på att samla ihop de befintliga testfallen.

Kravhantering och testarbete inom förvaltningar sammantaget

Den huvudsakliga skillnaden mellan krav- och testarbetet i förvaltning och i projekt är egentligen vad du har att förhålla dig till och vad du har att utgå från. Det som kan vara krångligare vid kravarbetet, när du behöver förhålla dig till och förstå den existerande kravmassan, är kanske samtidigt det som kan göra testarbetet något lättare då du redan har mycket testfall, testdata och testkunskap på plats. På samma sätt kan det som gör kravarbetet vid nyutveckling enklare vara det som gör testarbetet svårare då du inte har tidigare erfarenhet och arbetsmaterial att luta dig emot.

I förvaltningsarbete är det inte ovanligt att det blir ännu viktigare att lägga mer tid på att genomföra ett bra kravarbete eftersom det är tidskrävande att förstå och förutse helt hur en förändring slår på befintlig funktionalitet. Däremot är det inte ovanligt att många förvaltningar missar detta och tror att kravarbetet faktiskt blir mycket enklare eftersom det "bara" är förändringar som ska beskrivas. Effekten blir då den att utvecklings- och testarbetet blir mycket mer tidsödande, och den tid som sparades på kravarbetet gick förlorad, och dessutom mer därtill, i de senare processtegen när de outredda krav-sambanden och påverkan på andra delar börjar bli tydliga och ge negativa konsekvenser.

Vid förvaltningsarbete är det därför kanske som allra tydligast att krav och test verkligen är två sidor av samma mynt. Om vi har genomfört ett gediget och bra analysarbete när vi arbetat med våra kravbeskrivningar och verkligen förstått hur den önskade förändringen påverkar och påverkas av det befintliga systemet så kommer testarbetet bli mycket enklare eftersom den behövda påverkansanalysen är genomförd, det blir enkelt att se vilka testfall som kan återanvändas och vilket testdata som behövs etc. På samma sätt medför ett påskyndat kravarbete, där analysen om hur den önskade förändringen slår på det befintliga systemet, att våra tester måste ta ansvar för detta och när brister och defekter då hittas måste vi backa genom hela processen för att få beslut om och de behövda rättningarna införda på korrekt sätt.

Sammanfattning

Som vi har sett finns det både likheter och skillnader mellan krav- och testarbete i projekt och förvaltningar. Så länge vi är medvetna om skillnaderna för att hantera dem och vi hittar sätt att dra nytta av likheterna så är det möjligt att ha ett effektivt förvaltningsarbete. Det vanligaste problemet vi ser när vi kommer ut till våra kunder är dock att detta inte är fallet. Endera arbetar man exakt på samma sätt i sin förvaltning som man gör i projekt och glömmer att man faktiskt kan dra nytta av redan tidigare gjort arbete, eller så förenklar man alldeles för mycket och tror att förändringar av systemet nästan kravar och testar sig själv.

Detta samspel mellan kravhantering och testarbete är något av det som verkligen gör förvaltningsarbete så stimulerande. Ofta kan vi väldigt snabbt se effekterna av våra förändringar men för en analytisk person finns det intressanta utmaningar att möta då det kan krävas mycket arbete för att verkligen förstå och hantera konsekvenserna de önskade förändringarna har på systemet. Det finns också mycket stora möjligheter att arbeta med kontinuerliga förbättringar av arbetssätten då vi hela tiden kan identifiera enklare och kraftfullare sätt att dra nytta av tidigare utfört arbete och därmed bli effektivare.

Den svårighet som många förvaltningar har att hantera för att få ordning på dessa problem är att verksamheten allt för ofta inte vet hur mycket tid de behöver avsätta för att säkerställa att en korrekt behovs- och kravanalys genomförs vid förvaltningsarbete och vilken roll de har vid acceptans av förändringarna. I de flesta företag är det tydligt för verksamheten att deras tid behövs vid projektarbete för att säkerställa att de får den systemlösning som de behöver, medan det är mycket mer otydligt hur verksamheten ska delta i förvaltningarnas arbete. Detta är ett av de problem som adresseras genom införande av ett strukturerat förvaltningsarbete, exempelvis genom förvaltningsmodellen PM3, där de olika rollernas ansvar beskrivs och förtydligas - bland annat verksamhetens ansvar för kravhanering och testarbete.

Förvaltningsarbete är också något som verkligen lämpar sig för nära samarbete mellan verksamheten och IT, mellan beställare och leverantör, men också mellan de olika disciplinerna kravhantering, utveckling och test. Kan det bli roligare och bättre än så?

---

Läs allt om kurserna på inUse Academy här!