Mjukvarukvalitet Programvarukvalitet Eller Software Quality

1 - Bakgrund

Jag har märkt att jag inte riktigt känner mig bekväm när begreppet kvalitet används i samma mening som mjukvara - jag har inte någon bra känsla för vad det betyder, eller ska betyda. Begrepp som spårbarhet, process, krav, test och metrik känns på något sätt relaterat till mjukvarukvalitet utan att vara synonyma. Termen programvarukvalitet verkar vara den SSTB förespråkar, och på engelska brukar vi säga software quality.

Jag ska ge ett par exempel på tillfällen jag diskuterat mjukvarukvalitet med kollegor:

• Det första hände för flera år sedan men jag tänker ändå på det då och då. Det handlade om ett system som vi hade hittat en rad buggar i. Kollegan ville att vi skulle använda antalet kända buggar (som var av olika allvarlighet) som ett slags mått på kvalitet.
• Det andra exemplet är mer nyligen när en annan kollega inom ramen för en kompetensgrupp vi hade höll ett föredrag om kvalitet, och då inte just mjukvarukvalitet. Hans ståndpunkt var att kvalitet handlade om tre enkla steg: (1) Berätta vad du ska göra. (2) Gör det. (3) Bevisa att du gjort det.
• Vid ett annat tillfälle, med en annan arbetskamrat, handlade diskussionen kopplingen mellan test och kvalitet och mer specifikt: mäter mjukvarutest mjukvarukvalitet? Jag hävdade då och tror fortfarande att vissa aspekter av kvalitet mäts med test - men inte alla.
• Alla dessa exempel kan anses handla om olika aspekter av mjukvarukvalitet - kanske kan man säga att det första exemplet handlar om det Garvin kallar Produktbaserad kvalitet (det finns brister jämfört med spec) och det andra Tillverkningsbaserad kvalitet (vi har en sund utvecklingsprocess). Det tredje exemplet handlar om något helt annat: hur vi mäter kvalitet.

I den här texten försöker jag undersöka olika definitioner av mjukvarukvalitet och en rad begrepp som jag tycker hänger samman med detta. Men det är en lång resa och jag det verkar ganska svårt att sätta tummen på det där med Mjukvarukvalitet Programvarukvalitet Eller Software Quality.

2 - Definition av mjukvarukvalitet från ISTQB/SSTB och Feigenbaum

SSTB har i sin ordlista (se källor nedan) gjort två mycket relevanta och ganska korta definitioner:

• Kvalitet (engelska quality): Till vilken grad en komponent, ett system eller en process uppfyller ställda krav och/eller användares/kunds behov och förväntningar. [Efter IEEE 610]
• Mjukvarukvalitet (eller programvarukvalitet, som är termen SSTB föredrar, eller engelskans software quality): Den totala funktionaliteten och egenskaperna hos en programvaruprodukt med syfte att tillfredsställa fastställda och underförstådda krav. [Efter ISO 9126]

Som sagt, en kort definition som är lätt att minnas. Men den förutsätter att man har bra krav och att man på något sätt tar reda på kundens underförstådda krav.

Feigenbaum verkar vara av ungefär samma åsikt. Det är i princip samma definition som den i ISO 9126 fast med mer bakgrund och motivering. Jag är dock inte helt säker på att det är en användbar eller på ett enkelt sätt mätbar definition:

• "Quality is a customer determination, not an engineer's, marketing, nor a general management determination. It is based on upon the customer's actual experience, measured against his or her requirements -- stated or unstated, conscious or merely sensed, technically operational or entirely subjective -- and always representing a moving target in a competitive market." (Från wikipedia)

3 - Kvalitetskrav (eller icke-funktionella krav)

Nu när vi sett en typ av definition som är ganska rättfram skulle jag vilja vrida fokus från "funktion" mot "icke-funktion".

3.1 - Definition av mjukvarukvalitet från Juran

"The word quality has multiple meanings. Two of these meanings dominate the use of the word: (1) 'Quality consists of those product features which meet the need of customers and thereby provide product satisfaction.' (2) 'Quality consists of freedom from deficiencies.' Nevertheless, in a handbook such as this it is convenient to standardize on a short definition of the word quality as "fitness for use". (Från wikipedia)

Juran antyder att programvarukvalitet handlar om mer än att uppfylla krav. Den ska vara fri från defekter och passa användningsområdet. Vi fortsätter på spåret att kvalitet inte är en enda egenskap.

3.2 - En dualitet i kvalitet

Wikipedia citerar Consortium for IT Software Quality (CISQ) och deras kvalitetsmodell. Den innehåller en aspekt med kvalitetskrav som är funktionell och en annan aspekt som är strukturell. Strukturella aspekter som tillför värde för företaget är tillförlitlighet, effektivitet, säkerhet, underhållsmässighet och storlek. Denna skillnad i strukturell och funktionell kvalitet hör samman med om man observerar kvalitet inifrån eller utifrån.

Den här modellen antyder att det finns två sidor av kvalitet och att det finns fem bra icke-funktionella aspekter som är viktiga.

3.3 - Mer om icke-funktionella krav eller kvalitetskrav

(Notera att begreppet icke-funktionella krav ofta är synonymt med kvalitetskrav.)

Jag associerar till kravhantering. I Boken Requirements Engineering Fundamentals så nämns krav av tre typer: funktionella krav ("det ska finnas en växelspak"), kvalitetskrav ("växelspaken ska vara skön att hålla i") och begränsningar ("minst 90% av växelspakens delar ska vara tillverkade i Sverige"). Med det tänket kan man ju se till att inte ha några implicita krav genom att skriva ner allt (men det är svårt eller antagligen omöjligt).

Så om vi nu för ett ögonblick undersöker icke-funktionella aspekter av mjukvara för att se olika sidor av kvalitet med den linsen. Vi börjar med att titta på ISTQB och SSTB's definition:

• Icke-funktionellt krav: Krav som inte relaterar till funktionaliteten i ett program utan till egenskaper såsom tillförlitlighet, effektivitet, användbarhet, underhållbarhet och portabilitet.

Det jag som jag tycker är intressant med den definitionen är exemplen på kvalitetsaspekter vi får: "tillförlitlighet, effektivitet, användbarhet, underhållbarhet och portabilitet". Här har vi fem aspekter som verkar viktiga - men det är inte samma som CISQ listade. Det visar sig att om man gräver lite hittar man ganska många olika sorters aspekter.

En blogg jag hittar (se [1]) listar ett femtontal olika "dimensioner" på mjukvarukvalitet. Samma sida gav tipset att när någon säger 'Den här mjukvaran har god kvalitet.', så kan man ställa frågan 'I vilka kvalitetsdimensioner?'.

Men jag noterar att den sidan inte listar till exempel storlek som jag stött på tidigare. Till slut slår det mig att Wikipedia har en sida för icke-funktionella krav där de listar omkring 50 olika kategorier. Jag bryr mig inte om att översätta: "...network bandwidth..., Accessibility; Audit and control; Availability; Backup; Capacity; Certification; Compliance; Configuration management; Dependency on other parties; Deployment; Documentation; Disaster recovery; Efficiency; Effectiveness; Emotional factors; Environmental protection; Escrow; Exploitability; Extensibility; Failure management; Fault tolerance; Legal and licensing issues or patent-infringement-avoidability; Interoperability; Maintainability; Modifiability; Network topology; Open source; Operability; Performance/Response time; Platform compatibility; Price; Privacy; Portability; Quality; Recovery/Recoverability (e.g. mean time to recovery - MTTR); Reliability (e.g. mean time between failures - MTBF); Reporting; Resilience; Resource constraints (processor speed, memory, disk space, network bandwidth, etc.); Response time; Robustness; Safety; Scalability; Security; Software, tools, standards etc. Compatibility; Stability; Supportability; Testability; Usability...". Den uppmärksamme läsaren noterar att kvalitetskravet Quality var med i listan. Men rekursiv hantering av mjukvarukvalitet är det nog ingen som vill ha.

OK, sammanfattningsvis kan vi säga att det finns många olika typer av icke-funktionella krav på en mjukvara och antagligen så handlar de alla om mjukvarukvalitet på ett eller annat sätt.

4 - En definition för att unifiera alla andra definitioner?

Gurun Capers Jones har undersökt kvalitet och i Boken The Economics Of Software Quality undersöker han och Olivier Bonsignour otroligt många aspekter av kvalitet och mjukvara. Jag har plockat ut några citat här som först belyser att begreppet mjukvarukvalitet kan undersökas med olika hattar eller perspektiv för att använda Garvins terminologi (de använder istället attribut för samma tanke). Jag citerar avsnittet "Defining Software Quality" från boken med hjälp av Google Translate följt av min egen manuella översättning.

Men först tittar vi på några uttalanden från Deming och Garvin.

4.1 - Mjukvarukvalitet enligt Deming

"The problem inherent in attempts to define the quality of a product... were stated by the master Walter A. Shewhart. The difficulty in defining quality is to translate future needs of the user into measurable characteristics, so that a product can be designed and turned out to give satisfaction at a price that the user will pay. This is not easy, and as soon as one feels fairly successful in the endeavor, he finds that the needs of the consumer have changed, competitors have moved in, etc." (Från wikipedia)

Här får vi en tydlig indikation på att det är svårt att definiera mjukvarukvalitet, och att så fort man gjort det så stöter man på patrull - nya aspekter och problem dyker snabbt upp. Deming menar även att kvalitet måste vara mätbar.

4.2 - Garvins fem perspektiv på Kvalitet

Både Wikipedia och ISTQB/SSTB hänvisar till Garvin (eller Kitchenham, Pfleeger och Garvin) som ger fem perspektiv på mjukvarukvalitet. Här handlar det inte om fem typer av icke-funktionella krav utan fem "hattar" man kan ta på sig när man tittar på kvalitet. (Citat från SSTB Ordlista.)

• Känslobaserad kvalitet: Ett sätt att se på kvalitet som innebär att kvalitet inte kan definieras på ett exakt sätt, trots det kan vi ända avgöra om kvaliteten hos en produkt när vi ser den. I detta synsätt beror kvaliteten på uppfattning och de känslor som som produkten väcker hos en individ eller en grupp av individer.
• Användarbaserad kvalitet: Ett sätt att se på kvalitet som innebär att kvaliteten hos en produkt definieras av produktens förmåga att uppfylla användarens behov och önskningar. En produkt som inte uppfyller användarnas behov kommer troligtvis inte att ha några användare. Denna vy av kvalitet är kontext och tillfällighetsberoende eftersom olika affärssituationer kräver olika egenskaper hos en produkt.
• Tillverkningsbaserad kvalitet: Ett sätt att se på kvalitet som innebär att kvaliteten hos en produkt eller tjänst avgörs av i vilken grad den stämmer överens med dess ursprungliga design och krav. Kvaliteten i produkten uppkommer genom de använda utvecklings- eller tillverkningsprocesserna.
• Produktbaserad kvalitet: Ett sätt att se på kvalitet som innebär att kvaliteten hos en produkt definieras via ett antal väldefinierade kvalitetsattribut, vilka ska kunna mätas objektivt och kvantitativt. Kvalitetsskillnader mellan produkter av samma typ kan spåras tillbaka till hur specifika kvalitetsattribut har implementerats.
• Värdebaserad kvalitet: Ett sätt att se på kvalitet som innebär att kvaliteten hos en produkt avgörs av produktens pris. Produkter eller tjänster är av hög kvalitet om de tillhandahåller önskad prestanda för en acceptabel kostnad. Kvaliteten hos en produkt avgörs i form av en beslutsprocess hos en intressent där tids, ansträngnings och kostnadsaspekter vägs mot varandra.

Lärdomen här är nog att det är svårt att definiera mjukvarukvalitet på ett enkelt sätt, eller att det i alla fall finns många olika aspekter av det.

4.3 - Kategorier för kvalitetskrav

Jones och Bonsignour skriver att "... Olika nyanser av kvalitet kan kategoriseras i sju stora fokusområden eller kvalitetstyper:

1. Tekniskt och strukturkvalitet ...
2. Processkvalitet ...
3. Användande kvalitet ...
4. Servicekvalitet ...
5. Estetisk kvalitet ...
6. Kvalitet på följande av standard ...
7. Rättslig kvalitet ..."

Vi ser att det är ett ganska stor överlapp med Garvins fem, men överlappet är inte 100%. Intressant är att rättslig kvalitet dyker upp - kanske är det en lite mer amerikaniserad källa än vi hittills sett.

4.4 - Kriterier för en bra definition

Ok, det är svårt att definiera kvalitet och mjukvarukvalitet har många aspekter - det budskapet börjar jag acceptera. Men om man skulle försöka definiera mjukvarukvalitet då - vad ska man tänka på då? Jones och Bonsignour menar även att "... Kvaliteten beror ofta på sammanhanget ... exakt samma komponent kan vara av utmärkt kvalitet eller mycket farligt beroende på miljön ... Det finns sju kriterier som bör tillämpas på definitioner av programvarukvalitet för att vi ska kunna använda definitionen i en affärsmiljö för ekonomiska analys: [Kvalitetsdefinitionen bör vara]

1. ... förutsägbar innan projektet startar.
2. ... mätbar under och efter projekten är klara.
3. ... bevisbara om tvister uppstår.
4. ... förbättringsbara över tid.
5. ... flexibel och omfatta alla leverabler.
6. ... utbyggbar och omfatta alla faser och aktiviteter.
7. ... utbyggbar för att möta nya tekniker som cloud computing."

4.5 - Vad ger hög kvalitet

Författarna duckar lite för att ge en definition med ger många och långa listor på faktorer som uppfattas som sådana som ger hög kvalitet: "... taxonomi av kvalitet behövs eftersom en full uppsättning av alla möjliga kvalitetsattribut omfattar mer än 100 olika ämnen ... [Av dessa finns det 12] viktigaste faktorer för att uppnå kvalitet baserat på mätningar av flera tusen tillämpningar ...

1. Låg defektpotential
2. Effektiva metoder för att förebygga defekt
3. Hög grad av detektering av defekter
4. Hög grad av borttagning av defekter
5. Användning av inspektioner före testning
6. Användning av statisk analys före testning
7. Användning av formella designtekniker av testfall
8. Lätt att lära sig
9. Bra användarvänlighet
10. God teknisk support
11. Hög kundnöjdhet
12. Bra garanti"

4.6 - Sammanfattning

Så man kan se på mjukvarukvalitet med många hattar, en definition måste ta hänsyn till en rad kriterier och om man mäter kvalitet med kvalitetskrav så finns det ett antal huvudkategorier.

5 - Diskussion

To be completed

• Hur kan vi ha nytta av en bra definition? Mätbarhet, checklistor, kommunikation,
• Hur kommer jag använda mig av en definition?
• Vilka definitioner gillar jag? Skillnad på att vara leverantör och att vara mottagare.
• Varför är en definition viktig? Tala samma språk, mäta rätt sak, anstränga sig på rätt sätt.
• När kan man säga att en mjukvaras kvalitet är hög?
• Hur mäter vi mjukvarukvalitet?
• Räcker det med att ha bra koll på icke-funktionella krav?

6 - Källor

• SSTB Ordlista Version 2.1 Baserad på ”Standard Glossary of Terms used in Software Testing, version 2.1”, se [2]
• Engelska Wikipedia om Software Quality: [3]
• Engelska Wikipedia om icke-funktionella krav [4]
• Boken The Economics Of Software Quality

Tillhör Kategori Test (typ)