swk vortrag metriken

Software Qualitätsmetriken

alexander.michehl@gmail.com

Inhalt

1.Anlass

2.Einspruch!

3.Alte Metriken

4.Bessere Metriken?

5.Neue Metriken

6.Durchführung

7.Vorläufiges Fazit

1.Anlass

● Iterative Entwicklung● „Wie verändert sich die Qualität unserer

Software pro Iteration? Wie können wir das ausdrücken?“

➔ Qualitätsmetriken

2.Einspruch!

● Metrik = Quantität → Quantität <> Qualität● Früher: LOC = Produktivität

3.Alte Metriken

● Anzahl Bugs● Anzahl Tests● Anzahl Warnungen● Testabdeckung

3.Alte Metriken

● Anzahl Bugs● Anzahl Tests● Anzahl Warnungen● Testabdeckung➔ Alle nutzlos, da ambivalent

4.Bessere Metriken?

1.Programmierstil

2.Programmstruktur

3.Wartbarkeit

4.Performance

5.Produktivität pro Iteration

6.Testqualität

4.Bessere Metriken?

1.Programmierstil● Mittel: Codeanalyse auf Basis fester Regeln

(Programmierkonventionen)● Ergebnis: Anzahl Verstoße gegen Regeln● Aussage: Werden Konventionen eingehalten?

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

4.Bessere Metriken?

2.Programmstruktur● Mittel: Strukturelle Codeanalyse● Ergebnis: Anzahl bestimmter

Programmierartefakte● Aussage: Architektur in Ordnung?

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

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?

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

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?

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

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?

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

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?

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

5.Neue Metriken

Maintainability Index

Testabdeckung

Testperformance

Codeanalyse auf Basis fester Regeln

Strukturelle Codeanalyse (absolute Zahlen)

Implementierte Features

Gelöste Bugs

6.Durchführung

● Von Hand?● Erfassung: Schwer, da untersch. Plugins● Analyse: Schwer, da untersch. Ausgabeformate➔ Automatisierung selbst programmieren!

7.Vorläufiges Fazit

● Qualität <> Quantität● Manuelle Reviews weit besser

Eigene Erfahrungen?Fragen?