Effektiv förvaltning börjar i kravspecifikationen

Att ett system har god förvaltningsbarhet (maintainability på engelska) innebär att det är lätt att underhålla, det vill säga att det är lätt att rätta fel i systemet och det är lätt att ändra och lägga till funktionalitet. Den här artikeln, som jag skrivit tillsamans med Magnus Österlund från Ida Infront, ger råd och tips om hur man får med rätt krav på förvaltningsbarhet i kravspecifikationer.

Att se till att ett system har hög förvaltningsbarhet är nyttigt redan under utvecklingsfasen, efter att den första raden programkod är skriven gör samma egenskaper systemet både enklare att utveckla och att förvalta. Trots detta finns det inga garantier för att utvecklingsprojekt alltid levererar system som är lätta att förvalta. Förvaltningsbarhet är dessutom en egenskap som är mycket svår att lägga till i efterhand. Därför anser vi att krav på förvaltningsbarhet är en viktig del av kravspecifikationen för nya IT-system.

Med krav på förvaltningsbarhet menar vi alla krav som syftar till att det ska vara lätt att rätta fel, ändra funktionalitet och lägga till ny funktionalitet i systemet efter att det tagits i drift. Vi tänker här redogöra för våra erfarenheter från en fallstudie om hur krav på förvaltningsbarhet hanteras idag, samt ge ett antal råd om hur krav bör ställas för att ge mer förvaltningsbara system i framtiden.

Nuläget i teori och praktik

Vi har genomfört en fallstudie av hur krav på förvaltningsbarhet behandlas i riktiga kravspecifikationer. Som underlag för fallstudien har vi även studerat litteraturen, i form av läroböcker, forskningsartiklar och processer. Slutsatserna kan kort sammanfattas som att alla tycker att det är viktigt att ställa krav på förvaltningsbarhet, men att det inte finns något konsensus om hur det bör gå till.

Fallstudien har utförts på kravspecifikationer från ett tiotal svenska myndigheter, som under perioden 2003-2004 genomfört offentliga upphandlingar angående nyutveckling av IT-system. Kravspecifikationerna granskades med målet att ta reda på hur vanligt det är med krav på förvaltningsbarhet, vilken typ av sådana krav som ställs och hur de formuleras.

Fallstudien visade att alla de studerade kravspecifikationerna innehöll någon form av krav på förvaltningsbarhet, vilket vi tolkar som ett utbrett intresse för god förvaltningsbarhet bland de kravställande myndigheterna. Vi fann dock att det finns utrymme för förbättringar av hur kraven ställs. För det första utnyttjar flertalet kravspecifikationer inte det breda spektrum av möjligheter som finns för att specificera förvaltningsbarhetskrav. För det andra är många av de krav som finns dåligt formulerade. De flesta kraven är inte testbara till följd av vaga formuleringar eller svårtolkade krav. Några exempel:

• "Förändringar bör kunna göras på ett enkelt sätt"
• "Systemet ska stödja tillägg och ändring av funktionalitet utan nämnvärda designändringar"
• "Spelet ska vara enkelt att bygga vidare på för framtida utveckling"

Tabellen nedan visar vilka typer av förvaltningsbarhetskrav som ställdes på systemen. Varje rad i tabellen visar vilka krav som ställts på ett specifikt system och som rubrik för varje rad finns en mycket övergripande beskrivning av systemet. Varje kolumn representerar olika områden inom vilka man kan ställa krav på förvaltningsbarhet. Vad de olika områdena innebär beskrivs nedan, under rubriken "Checklista med kravkategorier". En cirkel visar att det fanns krav inom området. I de fall kraven var försumbara, genom att bara något enstaka vagt eller väldigt "smalt" krav finns, är cirkeln ofylld.

Hela fallstudien beskrivs utförligt i en artikel (här är artikeln som pdf-fil) som vi publicerade på konferensen SERPS.

Sammanfattningsvis visar alltså både litteraturen och verkligheten på ett utbrett intresse för förvaltningsbarhet, men det tycks vara brist på handfasta råd om hur man ställer krav för att få förvaltningsbara system. Vi tänkte försöka angripa den bristen.

Generella råd till kravställare

Vi anser att den viktigaste förutsättningen för att lyckas ställa relevanta krav på förvaltningsbarhet är att som kravställare vara medveten om att denna aspekt finns och ska behandlas i kravspecifikationen. Användbarhet och säkerhet är andra sådana aspekter, som redan idag får ganska stort fokus i kravarbetet.

Det är viktigt att sätta ambitionsnivån. Hur viktig är förvaltningsbarheten är för systemet? Ofta underskattas den - system får ofta längre livslängd än planerat. Dessutom gäller att om förvaltningsbarheten är god är det större chans att systemet kan bli långlivat och därmed kostnadseffektivt. Men det är inte så enkelt att högre förvaltningsbarhet alltid är bättre än låg dito. Det kan kosta tid och pengar att göra systemet lättunderhållet och ibland är leveranstid och låg initialkostnad viktigare. Rådet blir därför ganska allmänt hållet: tänk till och gör ett medvetet val av ambitionsnivå för systemets förvaltningsbarhet. Låt sedan detta styra kravarbetet på området.

På samma sätt som när man arbetar med andra sorts krav är det viktigt att involvera verksamhetsexperter. Verksamhetsexperter för förvaltningsbarhetskrav är i första hand personer från förvaltningsorganisationen. De har värdefull kunskap om arbetssätt, kompetens, etc. Det är även viktigt att från användare/beställare inhämta kunskaper om ifall det finns delar av systemet som kan förväntas bli mer utsatta för ändringar och om det finns några specifika ändringar som ska förberedas för när systemet utvecklas (mer om detta under "Specifika förvaltningsbarhetskrav" nedan).

Det är bra om syftet med varje krav är tydligt. Det gör kravspecifikationen tydligare och minskar risken för missförstånd. Ett enkelt sätt att åstadkomma detta är att lägga alla krav som syftar till att specificera förvaltningsbarheten för systemet under en speciell rubrik.

Checklista med kravkategorier

Det finns en mängd sätt att ställa krav på förvaltningsbarhet. Här presenterar vi 10 kategorier som man kan ställa krav inom. Alla sätt passar inte för alla system och för de flesta system behöver långt ifrån alla kravkategorier användas. Vi rekommenderar att använda listan som en checklista. Gå igenom varje kategori och tänk efter om det finns något som är relevant för systemet att ställa krav på inom kategorin. Välj "era" kategorier utifrån typ av förvaltningsorganisation, etc.

1. Dokumentation. Dokumentation över hur systemet är designat och implementerat kan vara mycket värdefull när man ska utföra underhåll på systemet. Man kan ställa krav på dokumentationen, till exempel genom att ange vad som ska dokumenteras, hur det ska beskrivas (notationer, språk) och tekniska format för den.
2. Arkitektur och design. Systemets arkitektur och dess design påverkar förvaltningsbarheten och därför kan det vara relevant att ställa krav på dessa. Vissa arkitekturer och designmönster hävdas ge högre förvaltningsbarhet, som t.ex. abstract factory pattern. Att konsekvent använda samma mönster i olika delar av systemet kan öka förvaltningsbarheten.
3. Källkod. Krav på att systemets källkod ska följa kodningsstandarder och krav på kommentarer i källkoden kan ha en positiv påverkan på förvaltningsbarheten. En viktig faktor som påverkar förvaltningsbarheten är källkodens komplexitet. Komplexitetsmetriker kan användas för att specificera en acceptabel nivå.
4. Tredjepartsprodukter. Många produkter från tredjepartsleverantörer behövs för att skapa IT-system, till exempel programmeringsspråk, databaser och operativsystem. Ibland kan det vara relevant att ställa krav på sådana produkter för att förbättra förvaltningsbarheten. Om underhållsorganisationen består av erfarna Java-programmerare är det relevant att kräva att systemet skrivs i språket Java.
5. Testfall. Att ha en uppsättning regressionstestfall kan vara ett sätt att minska risken att introducera fel när systemet förändras. Därför kan det vara relevant, av förvaltningsbarhetsskäl, att kräva att sådana testfall levereras med systemet.
6. Körande system. Det kan vara relevant att ställa krav på hur det körande systemet får påverkas av förändringar. Sådana krav kan specificera vilken grad av tillgänglighet man kräver av systemet när förändringar görs.
7. Underhållsorganisation. Ett sätt att hantera förvaltningen är att låta någon annan göra det, det vill säga att kräva att systemet levereras med förvaltningstjänster. Krav kan ställas på hur sådana tjänster ska vara utformade.
8. Process. Man kan ställa krav på processen som ska användas för att utveckla systemet. Antingen genom att kräva att någon utvecklingsprocess som hävdas ge lägre förvaltningskostnader används (exempelvis Extreme Programming), eller genom att ställa krav på enskilda aktiviteter, som till exempel inspektioner med fokus på förvaltningsbarhet.
9. Systemövergripande. Det går att ställa systemövergripande krav på hur förvaltningsbart systemet ska vara. Exempel på sådana krav är hur mycket arbete som får krävas för olika typer av förändringar.
10. Ägande. För att över huvud taget kunna utföra förändringar i systemet är det viktigt att ha legala möjligheter att göra det. Krav kan ställas på att källkod och dokumentation ska ägas av kunden eller att licensrättigheter åtminstone tillåter förändringar.

Specifika förvaltningsbarhetskrav

Ibland vet man redan vid utvecklingen av ett system att några specifika förändringar kan komma att behövas i framtiden. Kanske har man skäl att tro att systemet i framtiden behöver stödja flera valutor, eller att det kommer att behöva användas via Internet. Det är vanligt att kunna förutse sannolika framtida förändringar som man ändå inte vill ha med vid utvecklingen för att den ska bli billigare, snabbare eller helt enkelt för att man vill låta organisationen använda systemet en tid innan man bestämmer om förändringarna behövs. Krav som handlar om att beskriva tänkbara framtida förändringar, så att systemet redan från början kan vara förberett för att förändras kallas specifika förvaltningsbarhetskrav.

För att ett specifikt förvaltningsbarhetskrav ska vara bra räcker det inte att det beskriver en tänkbar framtida förändring. Kravet måste även beskriva hur väl förberett systemet ska vara för förändringen. Det är till exempel stor skillnad på att en förändring är tekniskt möjlig och att förändringen ska kunna göras genom några enkla inställningar i en parameterfil. Några exempel på specifika förvaltningsbarhetskrav:

• Alla texter i systemets användargränssnitt skall kunna bytas ut genom att ändra i en textfil.
• Införande av konceptet "bonuskund" som har en personlig rabattsats kopplad till sig skall kunna göras utan att systemets databasschema behöver ändras.
• Systemet skall kunna förändras för att stödja följande tänkbara framtida krav, utan några förändringar i telefonimodulen: rapporterna ska kunna visas på mobila enheter, lönetillägg ska kunna baseras på personlig försäljning.

Det är alltså viktigt att varje specifikt förvaltningsbarhetskrav beskriver hur väl förberett systemet ska vara för en viss förändring. Lämpligen uttrycker man detta i termer av vilken påverkan på systemet förändringen skulle ha om den genomfördes. Det finns ett stort antal varianter av påverkan, exempelvis:

• Förändringen skall kunna utföras utan att systemets källkod behöver ändras eller utökas.
• Förändringen skall kunna utföras utan att systemets källkod behöver ändras. Ny källkod får dock läggas till (och anrop till den nya koden får läggas till i befintlig kod).
• Förändringen skall kunna utföras utan att några förändringar behöver göras i systemets kompilerade enheter. Nya kompilerade enheter får dock läggas till.
• Förändringen ska kunna utföras utan att systemets databasschema behöver ändras.
• Förändringen skall kunna utföras utan att systemets klientmoduler måste ändras.
• Ingen ändring alls, dvs. systemet ska redan ha funktionen inbyggd, men det ska gå att köra systemet utan att använda den. Det här betyder att det inte är fråga om något förvaltningsbarhetskrav utan ett normalt funktionellt krav.

Vårt råd är att se till att få med relevanta specifika förvaltningsbarhetskrav i kravspecifikationen och att låta dem bestå av både vad som ska ändras och på vilket sätt systemet får påverkas.

Generella förvaltningsbarhetskrav

Generella förvaltningsbarhetskrav är krav som syftar underlätta oförutsedda förändringar (till skillnad mot specifika förvaltningsbarhetskrav, där förändringarna är förutsedda). Vi anser att många generella förvaltningsbarhetskrav kan standardiseras och katalogiseras för att sedan återanvändas för flera system. Vi har gjort en sådan katalogisering av ett antal generella förvaltningsbarhetskrav. Här är några exempel på krav från katalogiseringen:

• Kodningsstandard. Källkod som skrivs i programmeringsspråket X skall följa kodningsstandarden Y.
• Automatisk byggmiljö. Med systemet skall en komplett byggmiljö levereras.
• Källkodsspråk. Identifierare och kommentarer i källkoden skall vara på engelska.
• Klientdistribution. Funktioner för centralt administrerad uppdatering av kod på klienter skall finnas.

Vid katalogiseringen bör kraven dokumenteras på ett sätt som gör det lätt att förstå vilka konsekvenser det får att ställa kravet och på vilka sätt det är rimligt att anpassa kravet för det aktuella systemet. Nedan följer ett exempel på ett sådant återanvändbart standardkrav.