Swk vortrag metriken

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?