Kvalitet som begreb er ofte en uhåndgribelig størrelse. Jeg kan tillægge nogle egenskaber en vis kvalitet, mens andre lægger vægt på helt andre egenskaber. Forståelsen af kvalitet er altså baseret på en meget subjektiv vurdering, både af niveauet men også hvilke egenskaber kvaliteten skal vurderes på.
Vi kan sikkert hurtigt blive enige om, at vi ønsker høj kvalitet i de løsninger vi udvikler, men udfordringen er at blive enige om, hvad det så betyder, og hvordan vi afgør om noget er af høj kvalitet?
I den klassisk filosofiske forståelse af begrebet ’kvalitet’ er der tale om en adskillelse mellem genstand og egenskab. Overført til software, der i sig selv er en uhåndgribelig størrelse, taler vi om funktion og kvalitet ofte refereret som funktionelle og ikke-funktionelle krav. Det er de ikke-funktionelle krav vi her betegner som kvaliteter eller rettere kvalitetsattributter (software quality attributes).
Ofte ser vi, at de ikke-funktionelle krav er bundet op på funktionelle krav, eksempelvis når et adresseopslag (et funktionelt krav) må have en maksimal svartid på to sekunder (et ikke-funktionelt krav). Kvalitetsbegrebet favner dog bredere, idet kvaliteten af et stykke software ikke kun er bundet op på brugeroplevelsen, men også omhandler indre kvaliteter, der eksempelvis sikrer at løsningen kan udvides, vedligeholdes og afprøves.
Men hvorfor er det overhovedet nødvendigt at bruge energi på at konkretisere kvalitetsbegrebet i et software projekt? Når vi i Visma Consulting taler om kvalitet i software, lægger vi særligt vægt på to forhold:
- Kvalitetsattributterne modvirker og forstærker hindanden – derfor skal de prioriteres. Et klassisk eksempel er, at hvis man øger sikkerheden (security) vil det ofte være på bekostning af ydelse (performance) og brugervenlighed (usability).
- Hvis vi alene stillede krav om funktionalitet – og ikke om kvalitet – så ville enhver softwarearkitektur være tilstrækkelig. Vi vælger arkitekturmønstre og praksis efter de kvalitetsattributter, der er prioriterede.
Vi kan drage to vigtige konklusioner heraf. Kvalitetsattributterne skal prioriteres, og alle interessenter bør inddrages i dette arbejde. Det skal være drevet af forretningens strategiske mål og vejledt af udviklingens tekniske indsigt.
Eksempelvis har vi for nyligt afsluttet et projekt, hvor de klassiske kvalitetsattributter ydelse (performance) og skalérbarhed (scalability) ikke var prioriteret. Dermed har vi ikke sagt at løsningen godt må være langsom, eller slet ikke skal kunne skalere. I dette tilfælde er der dog tale om to kvaliteter der, med den forretningsmæssige vision for anvendelsen af løsningen, ikke behøver nogen særlig opmærksomhed. Der var andre kvaliteter som var langt vigtigere i forhold til forretningens strategiske mål.
Den anden konklusion vi kan drage er, at kvalitet er bygget ind i grundarkitekturen for et system. Det kan altså blive relativt omkostningstungt at skifte fokus undervejs, og derfor er det værd at overveje i projektets tidlige faser.
Kvalitetsattributter
Der er faktisk flere gode grunde til at arbejde med softwarekvalitet, herunder at vi opnår en bedre fælles forståelse af, hvordan forretningens strategi skal understøttes af løsningen og samtidig laves der en forventningsafstemning mellem forretning og udvikling.
Hos Visma Consulting arbejder vi med kvalitetsdrevet arkitektur. Første skridt i vores metode til at etablere arkitekturen, er afholdelse af en ”Software Quality Attribute Workshop” med repræsentanter for hver af projektets interessenter. Resultatet heraf er en prioriteret liste af kvalitetsattributter og en samling af konkrete scenariebeskrivelser, der effektivt kommunikerer betydningen af de enkelte kvaliteter.
Dette vil ikke kun være grundlaget for softwarearkitekturen, men vil blive anvendt på alle niveauer i det daglige projektarbejde, når forskellige alternative løsninger holdes op imod hinanden, eksempelvis når udvikleren står med en vedligeholdelsesvenlig løsning og et mere ydelsesorienteret alternativ og skal vælge.
Forståelsen af kvalitetsattributterne skal derfor kommunikeres ud i hele projektorganisationen for at danne en fælles referenceramme for såvel analyse- som design- og implementeringsarbejdet.
Både tid (time-to-market) og pris (cost) kan indgå som kvalitetsattributter, men det er sjældent, at vi ser forretningen prioritere dem som kvalitetsattributter, og sjældent er det endeligt afgørende for om et projekt bliver en succes.
