1.
Software Qualitätsmetriken
alexander.michehl@gmail.com

2.
Inhalt
1.Anlass
2.Einspruch!
3.Alte Metriken
4.Bessere Metriken?
5.Neue Metriken
6.Durchführung
7.Vorläufiges Fazit

3.
1.Anlass
● Iterative Entwicklung
● „Wie verändert sich die Qualität unserer
Software pro Iteration? Wie können wir das
ausdrücken?“
➔ Qualitätsmetriken

4.
2.Einspruch!
● Metrik = Quantität → Quantität <> Qualität
● Früher: LOC = Produktivität

5.
3.Alte Metriken
● Anzahl Bugs
● Anzahl Tests
● Anzahl Warnungen
● Testabdeckung

6.
3.Alte Metriken
● Anzahl Bugs
● Anzahl Tests
● Anzahl Warnungen
● Testabdeckung
➔ Alle nutzlos, da ambivalent

7.
4.Bessere Metriken?
1.Programmierstil
2.Programmstruktur
3.Wartbarkeit
4.Performance
5.Produktivität pro Iteration
6.Testqualität

8.
4.Bessere Metriken?
1.Programmierstil
● Mittel: Codeanalyse auf Basis fester Regeln
(Programmierkonventionen)
● Ergebnis: Anzahl Verstoße gegen Regeln
● Aussage: Werden Konventionen eingehalten?

9.
4.Bessere Metriken?
1.Programmierstil
● Mittel: Codeanalyse auf Basis fester Regeln
(Programmierkonventionen)
● Ergebnis: Anzahl Verstoße gegen Regeln
● Aussage: Werden Konventionen eingehalten?
➔ ABGELEHNT, obsolet durch automatische
Refactorings

10.
4.Bessere Metriken?
2.Programmstruktur
● Mittel: Strukturelle Codeanalyse
● Ergebnis: Anzahl bestimmter
Programmierartefakte
● Aussage: Architektur in Ordnung?

11.
4.Bessere Metriken?
2.Programmstruktur
● Mittel: Strukturelle Codeanalyse
● Ergebnis: Anzahl bestimmter
Programmierartefakte
● Aussage: Architektur in Ordnung?
➔ ABGELEHNT, da Absolutwerte, die i.d.R. nur
steigen

12.
4.Bessere Metriken?
3.Wartbarkeit
● Mittel: „Maintainability Index“
MAX(0, (171-5.2*ln(H)-0.23*C-16.2*ln(L)*100/171)
● Ergebnis: Codeanalyse-Ergebnisse miteinander
korreliert
● Aussage: Ist der Code einfach wartbar?

13.
4.Bessere Metriken?
3.Wartbarkeit
● Mittel: „Maintainability Index“
MAX(0, (171-5.2*ln(H)-0.23*C-16.2*ln(L)*100/171)
● Ergebnis: Codeanalyse-Ergebnisse miteinander
korreliert
● Aussage: Ist der Code einfach wartbar?
➔ OK, trotz öffentlicher Zweifel

14.
4.Bessere Metriken?
4.Performance
● Mittel: Dauer von Testdurchläufen messen
● Ergebnis: Geschwindigkeit jedes Tests
● Aussage: Wurde durch ein neues Feature
bestehende Funktionalität verlangsamt?

15.
4.Bessere Metriken?
4.Performance
● Mittel: Dauer von Testdurchläufen messen
● Ergebnis: Geschwindigkeit jedes Tests
● Aussage: Wurde durch ein neues Feature
bestehende Funktionalität verlangsamt?
➔ OK, leider schwer umsetzbar

16.
4.Bessere Metriken?
5.Produktivität pro Iteration
● Mittel: Implementierte Features & gelöste Bugs
pro Iteration zählen
● Ergebnis: Anzahl abgeschlossener Aufgaben
● Aussage: Gibt es Fortschritt?

17.
4.Bessere Metriken?
5.Produktivität pro Iteration
● Mittel: Implementierte Features & gelöste Bugs
pro Iteration zählen
● Ergebnis: Anzahl abgeschlossener Aufgaben
● Aussage: Gibt es Fortschritt?
➔ ABGELEHNT, da Aufwand von Aufgabe zu
Aufgabe variiert

18.
4.Bessere Metriken?
6.Testqualität
● Mittel: Testabdeckung
● Ergebnis: Testabdeckung pro Projekt, reduziert
auf Testdurchläufe aus dazugehörigem
Testprojekt
● Aussage: Machen wir TDD richtig?

19.
4.Bessere Metriken?
6.Testqualität
● Mittel: Testabdeckung
● Ergebnis: Testabdeckung pro Projekt, reduziert
auf Testdurchläufe aus dazugehörigem
Testprojekt
● Aussage: Machen wir TDD richtig?
➔ OK

20.
5.Neue Metriken
Maintainability Index
Testabdeckung
Testperformance
Codeanalyse auf Basis fester Regeln
Strukturelle Codeanalyse (absolute Zahlen)
Implementierte Features
Gelöste Bugs

21.
6.Durchführung
● Von Hand?
● Erfassung: Schwer, da untersch. Plugins
● Analyse: Schwer, da untersch. Ausgabeformate
➔ Automatisierung selbst programmieren!

22.
7.Vorläufiges Fazit
● Qualität <> Quantität
● Manuelle Reviews weit besser

23.
Eigene Erfahrungen?
Fragen?