De fem kvalitetsperspektiven

Definition av kvalité

Det finns ett antal olika definitioner på mjukvarukvalité. ”Fitness for use” är den mest refererade definitionen och beskrivs i boken ”Jurans Quality Handbook” från 1979. Detta utvidgades senare till ”Fitness of purpose”.  Juran menade att hög kvalité innebär att mjukvaran har alla funktioner som uppfyller kundens behov. Men han menade även att god kvalité dessutom innebär avsaknaden av fel, så att arbetet inte behöver göras om och om igen. God kvalité innebär avsaknaden av missnöjda kunder.  Crosby definierade kvalié som ”conformance to requirements”. Deaming och även Bergman definierade mjukvarukvalité som ”the softwares ability to satisfy the (present and future) needs and expectations of the customers”.  Feigenbaum utvidgade Demings definition och tillade bland annat att produktens pris skulle överensstämma med förväntningarna. ISO definierar kvalitet som: “Quality is the totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs

Problemet med försök att definiera mjukvarukvalitet är att det i princip är omöjligt att i förväg, innan mjukvaran byggts, veta vilka behov användaren har flera månader senare, då mjukvaran levereras. Det är inte lätt att definiera mätbara kvalitetsegenskaper i förväg. Och om vi skulle känna oss nöjda över att ha lyckas definiera mätbara kvalitetskrav i förväg tillsammans med användarna, så har troligtvis användarnas behov ändrats vid leverans, konkurrenter och ny teknik har tillkommit och hela världen ser annorlunda ut.

Garvins fem perspektiv

Professor David Garvin (et al), har gjort ett antal undersökningar av kvalité ur ett flertal olika perspektiv som ekonomiska, marknadsmässiga och filosofiska. Slutsatsen är, kanske inte helt oväntat, att kvalité är komplext och att det inte går att förlita sig på en enda kvalitets-definition. Om man vill undvika att stöta på problem måste man istället se kvalité ur ett antal olika perspektiv, och Professor David Garvin har kommit fram till att det finns fem kvalitetsperspektiv som är gemensamma för alla definitioner av mjukvarukvalite.

  1. Enastående (transcendant): Kvalité kan inte definieras exakt utan är någonting som "känns" och som vi lär oss känna igen av erfarenhet. Det är idealbilden av vad vi vill uppnå, men som förmodligen inte kommer att  uppnås. Ungefär på samma sätt som vi känner igen skönhet eller "jag vet det när jag ser det" eller ”wooow".
  2. Användarbaserat (user based): Kvalité ses utifrån användarens perspektiv. Det skall vara användbart och "kunden/användarna skall vara totalt nöjda”. Den användarbaserade kvalitetssynen är mer konkret än den transcendala synen.
  3. Utvecklings- och tillverkningsbaserat (development and manufacfactoring based): Kvalité ses som "överensstämmelse med kraven”. Det är denna syn som ISO har definierat kvalitet efter. Även CMM Capability Maturity Model, har denna syn. De hävdar att en kvalitets produkt är direkt relaterade till kvaliteten på utvecklingsprocessen.
  4. Produktbaserat (product based): Kvalité  ses som något mätbart och exakt. Produkten eller tjänsten skall innehålla alla nödvändiga funktioner/features och man anser att "god intern kvalité resulterar i god extern kvalité”. Om alla separata delar i den underliggande mjukvaran har god kvalité blir den totala mjukvarans kvalité också god.
  5. Värdebaserat (value based): Kvalitet ställs i relation till kostnader och priset. Det skall finnas funktioner, och ”wow-upplevelser” och användbarhet i mjukvaran till en rimlig kostnad. Även utvecklingsprocessen skall ställas i relation till kostnsderna. ”Quality is the degree of excellence at an acceptable price and the control of variability at an acceptable cost." (R. A. Broh, Managing Quality for Higher Profits, 1982, p. 3)

Om synen på kvalité skiljer sig åt i projektet brukar det värdebaserade perspektivet spela en stor roll. Det värdebaserade kvlitétsperspektivet kan vara budget eller vad kunden är beredd att betala. De övriga perspektiven brukar då få anpassa sig efter detta.

Svårigheten med att uppfylla alla fem perspektiv

Beroende på vilken roll vi har i projekten ser vi olika på kvalitén. En användare kanske värdesätter att systemet är tillförlitligt och att det alltid är tillgängligt. En utvecklare är kanske mer intresserad av att mjukvaran skall vara lätt att underhålla och ha en låg feltäthet. Det kan finnas många fel i koden utan att dessa för den skull påverkar eller stör tillförlitligheten. En säljare kan vara mer intresserad av hur användargränssnittet ser ut och hur enkelt det är att använda. Projektledaren är fokuserad på att alla kundkrav implementeras och att projektet levereras i rätt tid. Ledningsgruppen tycker kanske att det är viktigast att budgeten hålls. Hur vi definierar, ser på och värderar kvalité varierar från projekt till projekt.

I ett projekt som utvecklar styrsystemet hos ett JAS-flygplan skulle kanske några anse att det allra viktigaste är att alla styrfunktionerna måste fungera felfritt medan någon annan anser att det viktigaste är att användargränssnittet är enkelt och intuitivt att använda för piloten. Någon annan anser att dokumentationen är viktigast. 

I ett JAS-projekt är kvalitetsperspektiven inte alls de samma som i projekt som utvecklar ett ordbehandlingsprogram. 

Vilket synsätt skall man välja i ett projekt?

Med alla dessa olika roller och perspektiv i åtanke, är det i princip omöjligt att peka ut en enda definition och ett enda synsätt av mjukvarukvalité som skall passa alla i projektet.

Att försöka uppfylla alla fem perpektiven, för att göra alla nöjda och glada, är ingenting att sträva efter eftersom det då finns en mycket stor risk att projektet blir ett kostsamt evighetsprojekt.

Det uppstår oftast "en dragkamp" om kvalitén inom projektet. Vi drar och stretar åt olika håll vilket resulterar i långa utdragna (ibland meningslösa och mycket kostsamma) diskussioner kring vad som skall göras och hur det skall göras osv.

De fem kvalitétsperspektiven är inte alls absolut ortogonala. Det finns inga skarpa gränser mellan dem, istället går de in i varandra. Det innebär att om ett kvalitétsperspektiv dominerar i ett projekt så fås automatiskt lite av de övriga kvalitéerna på köpet.

Hitta en gemensam syn i projektet

Ett sätt att hitta en gemensam syn och ett gemensamt mål, och för att undvika onödiga slitningar i projektet, är att alla i projektet kommer överens om 1 primärt och 1 sekundärt kvalitétsperspektiv och sedan fokusera på dessa. Jag själv brukar göra på följande vis:

  1. Samla kunder, testare, utvecklare, chefer, VD... ja alla som har något intresse av projektet, i ett rum som har en stor whiteboard.

  2. Brainstorma och skriv på whiteboarden vad alla tycker är bra kvalité. Det kan t.ex. vara "snabbt", "billigt", "lätt att använda", "få resurser", "gedigen dokumentation", "tillförlitligt", "häftigt", "snyggt", "lätt att underhålla", "omfattande hjälp", "räknar rätt" osv.

  3. Diskutera kring alla ord som kommit upp på tavlan och jämför dessa med de fem kvalitetsperspektiven: Produktbaserat, Användarbaserat, Värdebaserat, Enastående, Utvecklingsbaserat.

Kom sedan överens om 1 PRIMÄRT och 1 SEKUNDÄRT kvalitetsperspektiv och fokusera sedan på dessa.

Det har visat sig att om man fokuserar på två kvalitétsperspektiv så får man de resterande med på köpet.

Genom att alla i projektet gemensamt diskuterat och kommit överens om vilka två kvalitétsperspektiv som alla skall fokusera på så går det mycket smidigare att snabbt besluta om vad som skall göras och inte göras. Du slipper både onödigt "tjafs", onödigt arbete, missförstånd och onödiga spänningar i projektet.

Efter ett tag kommer du troligtvis även att märka att ni behöver ändra fokuseringen. Det som var viktigast i början av projektet kanske inte alls är lika viktigt i underhållsfasen.

Lycka till!

Vill du diskutera mer, eller få hjälp och tips i ditt projekt? Kontakta mig. Jag håller workshops eller ingår i ditt team som projektledare eller coach.

References:

Ohlsson N. (1998). Towards Effective Fault Prevention. Department of Computer and Information Science, Linköpings University, Sweden

William Perry. (2000). Effectiv Methods for software testingSecond ed. John Wiley & Sons, Inc.

Quality Assurance Instritute, USA (1999). Common body of knowledge for certified software test engineer (CBOK)
www.affectus.se  

Scroll to top