Boken The Economics Of Software Quality

The Economics of Software Quality av Capers Jones och Olivier Bonsignour, från Addison-Wesley, 2011, ISBN: 0132582201 eller 9780132582209. Kostar nu strax över 440 kr på Adlibris, 48$ eller 44£ på Amazon.

Jag har använt den som referensverk i ett projekt jag jobbat på och även som stöd i ett utbildningsmaterial jag kontinuerligt jobbar med (se min pdf på [1]).

Utöver det sedvanliga förordet, introduktionen, författarpresentation, en utmärkt sökdel, och en referenslista har The Economics of Software Quality 7 kapitel:

1. Defining Software Quality and Economic Value (cirka 34 sidor)
2. Estimating and Measuring Software Quality (cirka 80 sidor)
3. Software Defect Prevention (cirka 70 sidor)
4. Pretest Defect Removal (cirka 80 sidor)
5. Software Testing (knappt 70 sidor)
6. Post-Release Defect Removal (cirka 90 sidor)
7. Analyzing the Economics of Software Quality (cirka 110 sidor)

Boken innehåller erfarenheter från gurun Capers Jones och hans kollegors arbete med 13000 mjukvaruprojekt från 100tals organisationer sedan 1973 till 2011. De har systematiskt granskat hur effektiva olika metoder är och hur man tjänar på att ha bra kvalitet.

Enligt författarna är de bästa faktorerna för mjukvarukvalitet (min feting):

• Low defect potential
• Effective defect prevention methods
• High defect detection methods
• High defect removal efficiency
• Use of pretest inspections
• Use of pretest static analysis
• Use of formal test case design
• Good ease of learning
• Good ease of use
• Good technical support
• High user satisfaction
• Good Warranty

Bra mjukvarukvalitet får man alltså om man, till exempel, genomför granskning av krav och design; kör statisk kodanalys och har en metod för hur man designar sina testfall. Jämför med mina inlägg om Testing In Visual Studio där jag avhandlar i alla fall en del av dem.

Och de sämsta (igen, min fetning):

• Executice indifference to high quality
• Management indifference to high quality
• Team indifference to high quality
• Customer indifference to high quality
• Cost-per-defect quality metrics
• CMMI < 2
• Lines of code quality measures
• Litigation for poor quality (consequential, contractual, financial loss, safety, medical)
• No warranty expressed or implied

Dålig kvalitet får man om någon involverad part inte bryr sig om kvalitet (till exempel ens chef eller kund), men även om man mäter och styr på ett tvivelaktigt sätt - till exempel att ge bonus till den utvecklare som skriver flest rader kod, eller om man mäter vad bugar kostar. Även en dålig eller odokumenterad utvecklingsprocess riskerar att leda till låg mjukvarukvalitet.

En faktoid som krossas i Boken The Economics Of Software Quality är att buggar som upptäcks sent i projektet är dyrare än andra - de postulerar att i princip alla buggar kostar i medel 5 timmar.

Tillhör Kategori Test
Tillhör Kategori Boktips

Se även Boken Advanced Software Testing
Se även Beräkna Testinsats