Kosten technischer Qualität in der Softwareentwicklung

Kosten Technischer Qualität

In der Softwareentwicklung

e-movimento Software Design & Beratung GmbH
1030 Wien ● Marxergasse 7/26 ► www.e-movimento.com

Vorstellung
 Name: DI Sebastian Dietrich
 Tätigkeiten:
 Java-Softwareentwickler & Softwarearchitekt
 Teamleiter & Scrum-Master
 Berater, Trainer

 Überzeugungen & Leidenschaften:
 Technische Qualität & Produktivität
 Praxiserfahrung & theoretischer Background
 Agile Softwareentwicklung, Java, Android, Wikipedia

 Kontakt:
 mailto://Sebastian.Dietrich@e-movimento.com
 http://managing-java.blogspot.co.at
 http://de.wikipedia.org/wiki/Benutzer:Sebastian.Dietrich
2

► www.e-movimento.com, Sebastian Dietrich

Technische Qualität in der Softwareentwicklung
Was ist das?
 Definition:
 Teilaspekt von Softwarequalität
 Zur Erfüllung nicht-funktionaler Anforderungen wie Konformität,
Verständlichkeit, Analysierbarkeit, Modifizierbarkeit, Wartbarkeit,
Anpassbarkeit, Prüfbarkeit (ISO/IEC 9126)

 Beispiel:
public void setEmail(String email) {
this.email = email;
}

3


Was ist das?
 Definition:
Verständlichkeit, Analysierbarkeit, Modifizierbarkeit,
Anpassbarkeit, Prüfbarkeit (ISO/IEC 9126)

 Beispiel:
/**
* Sets the email to the given value.
*
* @param email the email to set.
* must not be null and a valid email
*/
this.email = email;
}
4


Was ist das?
 Definition:
Verständlichkeit, Analysierbarkeit, Modifizierbarkeit, Anpassbarkeit,
Prüfbarkeit (ISO/IEC 9126)

 Beispiel:
if (email == null)
throw new IllegalArgumentException(„null“);
if (!Pattern.matches("[a-z0-9!#$% … @ … (?:[a-z … “)
throw new IllegalArgumentException(„invalid“);
this.email = email;
}

5


Was ist das?
 Definition:
Verständlichkeit, Analysierbarkeit, Modifizierbarkeit, Anpassbarkeit,
Prüfbarkeit (ISO/IEC 9126)

 Beispiel:
public void setEmail(@Email String email) {
this.email = email;
}

6


Weitere Beispiele
Code-Smells & Programmierungs-Anti-Pattern:

7


Literatur

8


Management Sicht

9


Goldene Wasserhähne
Kosten – Nutzen Rechnung
Kosten
€ 2.035,- (Messing)
€ 3.035,- (vergoldet)
€ 13.820,- (Vollgold)

10

Nutzen
Hübscher
Weniger Fehler
Schnellerer Einbau
Bessere Wasserqualität
Schnelleres Händewaschen
Glückliche Installateure
Geringere Wartungskosten
…


Kosten – Nutzen Rechnung?
Kosten
viel (keine Smells)
viel mehr (keine Anti-Pattern)

Nutzen
Hübscherer Code
Weniger Bugs

ungeheuer viel (beides nicht) Schnellere Implementierung
Bessere Produktqualität
Produktivere Software
Glückliche Entwickler
…

11


Kosten – Nutzen Rechnung?
Kosten
viel (keine Smells)
viel mehr (keine Anti-Pattern)

Nutzen
Hübscherer Code
Weniger Bugs

ungeheuer viel (beides nicht) Schnellere Implementierung
Bessere Produktqualität
Produktivere Software
…

12


Kosten

Nutzen

1. Höhere Produktivität?

13


Höhere Produktivität in der Softwareentwicklung?
Hypothese

Ziel:

Höhere technische Qualität

Maßnahmen:

(automatisierte) Reviews &
Qualitätsverbesserungen

Entwicklungskosten


Ergebnis:
Höhere Produktivität

14


Höhere Produktivität in der Softwareentwicklung
Studien
 Höhere technische Qualität kombiniert mit
Prozessverbesserungsmaßnahmen führen zu einer
Produktivitätssteigerung um 170% [Ireland 95]
 Hohe technische Qualität führt zu höherer Produktivität
(>50%), weniger Abbrüchen (> 50%) und weniger Fehlern
bei Fehlerkorrekturen [Petermair 08]

15


Höhere Produktivität in der Softwareentwicklung?
Erkenntnis

Ziel:


Maßnahmen:


Entwicklungskosten


Ergebnis:

min.50%

16


Kosten

Nutzen

1. Höhere Produktivität 
2. Weniger Bugs?

17


Weniger Bugs durch technische Qualität?
Hypothese

Ziel:


Maßnahmen:


Entwicklungskosten


Ergebnis:
Weniger Bugs
(nach Entwicklung)

18


Frage
Frage: Was sollte sich ein Projektleiter wünschen, um
möglichst wenig Bugs zu bekommen?
a) Die bestmöglichsten klassischen Tests?
(Systemtests, Funktionstests)

b) Die bestmöglichsten Entwicklertests?
(Unittests, Integrationstests)

c) Die bestmöglichsten Reviews?
(Design Reviews und Code Inspections)

Zusatzfragen:
Welche der Testarten kann Fehler vermeiden?
Und welche Testart findet am meisten Fehler?

19


Antwort
90%

% gefundene Fehler je Tätigkeit

50%
40%

30%
20%

Klassische
Tests

60%

Entwickler
Tests

70%

Reviews

80%

10%
0%

[Jones 02]
20


Weitere Studien
 80-90% aller Bugs können mittels Code-Inspections
gefunden werden. [Fagan 76]
 Code-Inspections bei Motorolas Iridium Projekt
entdeckten 80% der Fehler, Reviews 60% der Fehler
[Brown 99]
 Bei Bell Northern Research fand man heraus, dass Fehler
durch Code-Ispections 2-4 mal schneller gefunden
werden können als durch Tests [Russell 91]
 Teams mit geringem Qualitätsfocus produzieren 200 mal
mehr Bugs (6 pro function point) als Teams mit hohem
Qualitätsfocus (3 Bugs pro 100 function points) [Jones 00]

21


Fehlervermeidung durch technische Qualität:
 Reviews erkennen:
 Doppelten Code (z.B. via CPD oder Simian)
Erfahrung aus Assessments: 1% - 24% (7% median)
 Redundanter Code (z.B. via Dead Code Detector)
Erfahrung aus Assessments: 1% - 5% (3% median)
 Toter Code (= ausgeführter Code dessen Ergebnis nie verwendet
wird)
 Unerreichbarer Code (= kann im Programmablauf nie erreicht
werden)

 Wartbarkeit, Verständlichkeit, Analysierbarkeit, Modifizierbarkeit
 weitere Faktoren die Fehler vermeiden

d.h. Technische Qualität  min. 10% Fehler vermieden

22


Erkentnis:

Ziel:


Maßnahmen:



Ergebnis:

Entwicklungskosten

30%
bis
85%

min.10%
Weniger Bugs
(nach Entwicklung)

23


Kosten

Nutzen

1. Höhere Produktivität 
2. Weniger Bugs 
3. Weniger Entstehungskosten?

24


Weniger Entstehungskosten durch techn. Qualität?
Hypothese
Ziel:


Entwicklungskosten



Weniger Bugs
(nach Entwicklung)

Maßnahmen:


Weniger
Entstehungskosten

Ergebnis:

Weniger Testaufwand

25

Weniger Bugfixingaufwand

Weniger Testaufwand?
 Frage:
„Um wieviel weniger Testfälle benötige ich, wenn ich mir
deutlich (40%-95%) weniger Bugs erwarte?“
 Antwort:
„Da man nicht weiss, wo die Bugs liegen braucht man
exakt gleichviele Testfälle“
 Frage:
„Was kann man sich überhaupt ersparen, wenn weniger
Bugs gefunden werden?“

26


Weniger Testaufwand
Test

~1 Fehler / Testfall

Gefundene
Fehler

0,5 – 0,8 neue Fehler je Fix

Solange bis
Akzeptanzkriterien
erfüllt

Fehlerbehebung

~1 PT / Fehler
= x10 wie während
Entwicklung

[Jones 86], [Jones 96a], [Jones 96b], [Shull 02], [McConnell 04], [Fagan 76], [Gilb 93]

 Antwort:
„Man spart sich Regressionstest-Durchgänge“ (ca. 10%)
„Man spart sich Fehlerbehebungsaufwände“ (40%-95%
weniger Fehler  36%-85,5% weniger Aufwand)
27


Review und Qualitätsverbesserungsaufwand
 Reviewkosten:
 Können (falsch gemacht) explodieren
(bis 15% der Entwicklungsaufwände [Humphrey 89]).
 Richtig ist:
 Großteil der Reviews automatisieren (insbesondere
Architektureinhaltung, Design, Unit-Testqualität)
 Reviews in den Build als „Quality Gate“ einbauen (fail fast)
 Manuelle Reviews durch Techniken wie DoD, Collective Code
Ownership, PairProgramming, TDD, BDD, … umsetzen

 Eigene Erfahrung: +5% des Entwicklungsaufwandes

 Qualitätsverbesserungsaufwand:
 Im Nachhinein deutlich teurer als mittels Quality Gates
 Eigene Erfahrung: +100% im Nachhinein, +5% sofort

28


Qualitätsverbesserungsaufwand
Verbesserungen im Nachhinein
 Verbesserungen im Nachhinein
 Wenige Tage bis Jahre nach Entstehen der Qualitätsmängel
 Sauteuer (bis 100% der Entwicklungskosten)
 will keiner zahlen

 Lösung: Limbo mit Softwarequalität
1. Quality Gates (= Limbostange) einführen
(Build bricht, wenn nicht eingehalten)
2. Quality Gates auf aktuelle Qualität setzen
 Build bricht bei Verschlechterungen
 Verschlechterungen sofort ausbessern
3. Sobald (zufällig, nebenbei) Qualität besser
 Quality Gate sofort anpassen

 Erfahrungswerte:
1 Entwickler verbessert 10 KLOC/Jahr um 50% „nebenbei“
29


Kosten - Nutzenrechnung

Entwicklung
Test

 Rechnung:
5% Mehraufwand durch Reviews
5%-100% Mehraufwand durch Qualitätsverbesserung
50%-170% höhere Entwicklerproduktivität
10% weniger Testaufwand
36%-85,5% weniger Fehlerbehebungsaufwand
===================================
19% geringere bis 245,5% höhere Produktivität in Entwicklung
10% höhere Produktivität im Test
 Typisches Softwareentwicklungsprojekt (1.000 PT):
500PT Entwicklung, 400PT Test, 100PT Fehlerbehebung
 204 – 595 PT Entwicklung
74 PT Mehraufwand bis
360
PT Test
395 PT Minderaufwand
41 – 119 PT Fehlerbehebung
+7 bis -253%

30


Studien
 Reviews und Inspections alleine reduzieren die
Softwareentstehungskosten / Dauer um bis zu 30% [Jones 00]
 Code-Inspections führen zu einer Aufwandsreduktion von bis zu 25%
[Fagan 86]
 Fehlerbehebungsaufwände machen bis zu 90% der
Entwicklungsaufwände aus [Jones 00]
 Focus auf technische Qualität bringt ein 2- bis 4-fache Steigerung der
Entwicklungsproduktivität (bei schlechten Teams bis 10-fach)
[Anderson 10]
 Bei AT&T führten Reviews zu einer 10-fachen Verbesserung der
Qualität und 14% höheren Produktivität. [Humphrey 89]
 IBM berichtet, dass jede Stunde Inspections 20 Stunden Test spart
[Holland 99]

31


Erkenntnis:
Ziel:


10%-105%

Maßnahmen:


Entwicklungskosten

50%-170%


+7% bis -253%

Ergebnis:

Mehr/Weniger
Entstehungskosten

Weniger Bugs
(nach Entwicklung)

ca.10%
Weniger Testaufwand

32

36%-85%

46% 95%


Kosten

1.
2.
3.
4.

33

Nutzen

Höhere Produktivität 
Weniger Bugs 
Weniger Entstehungskosten
Deutlich geringere
Gesamtkosten?

Deutlich geringere Gesamtkosten durch techn. QS?
Überlegung
 Ziele der Technischen Qualität:
 Erfüllung nicht-funktionaler Anforderungen wie Konformität,
Verständlichkeit, Analysierbarkeit, Modifizierbarkeit,
Wartbarkeit, Anpassbarkeit, Prüfbarkeit (ISO/IEC 9126)

 Aufgaben während der Wartung:
 Code verstehen, analysieren, modifizieren, anpassen,
überprüfen
  Technische Qualität reduziert insbesondere
Wartungsaufwände

 Wartungskosten:
 Traditionell der größte Teil des Software Lebenszyklus
 Steigt stetig (70er Jahre 35%-60%, 2000er Jahre 80%90%) ([Macario et al. 03], [M.M. Lehman 80])
34


Hypothese
Ziel:
Maßnahmen:



Entwicklungskosten

Weniger Wartungsaufwand

Ergebnis:
Weniger Bugs
(nach Entwicklung)

Weniger Testaufwand
35

Deutlich geringere
Gesamtkosten


Höhere Wartbarkeit
Studien
 Alleine der Einsatz von Komplexitätsmetriken und die Verbesserung
der damit aufgezeigten Codeteile führen zu ca. 20 % höherer
Produktivität in der Softwarewartung. [Jones 00]
 HPs Programm zur Verbesserung der technischen Qualität brachte
ein ROI von 10 : 1. HP ersparte sich damit geschätzte $21.4 Millionen
pro Jahr. [Grady 94]
 Reviews von 2.5 Mio LOC (real-time-code bei Bell) reduzierte den
Wartungsaufwand im Schnitt um 33 Stunden je gefundenem Defect
[Russell 91]
 IBM berichtet, dass jede Stunde für Reviews im Schnitt 82 Stunden
Wartungsaufwand reduziert [Holland 99]
 Bei Imperial Chemical Industries wurden ca. 400 gereviewte
Programme mit anderen ca. 400 nicht gereviewten Programmen
verglichen. Qualitätsverbesserte Programme kosten in der Wartung
nur 1/10tel von Programme ohne Qualitätsoptimierungen [Gilb 93]
36



Software
wartung

Software Software
test
entwicklung

Kosten - Nutzenrechnung
19% geringere bis 245% höhere Produktivität

10% höhere Produktivität

20% - 1000% höhere Produktivität

 Typisches Softwareentwicklungsprojekt (66% Wartung):
500PT Entwicklung, 400 Test, 100 Fehlerbehebung, 2000 Wartung
 204 – 595 PT Entwicklung
360
PT Test
326 – 2195 PT Minderaufwand
41 – 119 PT Fehlerbehebung
11% – 73% Minderaufwand
200 – 1600 PT Wartung
37


Erkenntnis:
Ziel:
Maßnahmen:


Entwicklungskosten


50%-170%

min. 20%
Weniger Wartungsaufwand

Ergebnis:
Weniger Bugs
(nach Entwicklung)

ca.10%
Weniger Testaufwand
38

10%-105%

11%-73%
Deutlich geringere
Gesamtkosten

36%-85%

46% 95%


Kosten – Nutzen Rechnung: Fazit
Kosten
Gratis
Amortisiert sich bereits
während der Entwicklung

Nutzen
Flexibel für Änderungen
Deutlich weniger Bugs
(min. 40% weniger)
Schnellere Fertigstellung
(bis zu 250% schneller)
(min 20% geringer)
Geringere Gesamtkosten
(min 11% geringer)
Glückliche Endkunden

39


Kosten – Nutzen Rechnung: Fazit

40


Literatur
 Wikipedia:
 Codequalität @ Wikipedia: https://de.wikipedia.org/wiki/Codequalität
 Code-Smells@ Wikipedia:
https://de.wikipedia.org/wiki/Smell_(Programmierung)
 Programmierungs Anti-Pattern @ Wikipedia:
https://de.wikipedia.org/wiki/Anti-Pattern#Programmierungs-Anti-Pattern

 Literatur:






The Clean Coder @ Amazon: http://bit.ly/cleancoder
Clean Code @ Amazon: http://bit.ly/cleancodecmartin
Refactoring @ Amazon: http://bit.ly/refactoring_fowler
Code Complete @ Amazon: http://bit.ly/codecomplete
The Pragmatic Programmer @ Amazon:
http://bit.ly/pragmaticprogrammer
 Limbo mit Softwarequalität: http://managingjava.blogspot.co.at/2012/05/limbo-mit-softwarequalitat.html
41


Referenzierte Studien
 [Ireland 95] – Blake Ireland, Ed Wojtaszek, Dan Nash, Ray Dion, Tom Haley:
„Raytheon Electronic Systems Experience in Software Process
Improvement“, Software Engineering Institute, November 1995, CMU/SEI-95TR-017
 [Petermair 08] - Patrick Petermair: „Auswirkung von Codequalität auf die
Produktivität in Softwareprojekten“ – FH Campus Wien 2008/09
 [Jones 02] – Capers Jones 2002:
http://www.cs.nyu.edu/artg/Producing_Production_Quality_Software/Fall2005
/lectures/SOFTWARE_QUALITY_IN_2002_CAPERS_JONES.pdf
~ 12.000 Projekte, 600 Unternehmen, 24 Länder
 [Fagan 76] M.E. Fagan (1976). "Design and Code inspections to reduce
errors in program development". IBM Systems Journal 15 (3): pp. 182–211.
 [Brown 99]: Brown, Norm. "High-Leverage Best Practices: What Hot
Companies Are Doing to Stay Ahead," Cutter IT Journal, Vol. 12, No. 9
(September 1999), pp. 4-9.
 [Russell 91]: Russell, Glen W. "Experience with Inspection in Ultralarge-Scale
Developments," IEEE Software, Vol. 8, No. 1 (January 1991), pp. 25-31.
42


Referenzierte Studien cont.
 [Jones 00]: Capers Jones: Software Assessments, Benchmarks, and Best
Practices. Addison-Wesley, 11. Mai 2000, ISBN 978-0201485424
 [Jones 96] Applied Software Measurement, Capers Jones, 1996
 [Jones 86] Programming Productivity, Capers Jones, 1986
 [Jones 96] Software Defect-Removal Efficiency, Capers Jones, 1996
 [Shull 02] What We Have Learned About Fighting Defects, Shull et al 2002
 [McConnell 04] Code Complete, Steve McConnell 2004
 [Gilb 93] Tom Gilb, Dorothy Graham, Susannah Finzi „Software Inspection“,
Addison-Wesley: Trevor Reeve, Case Study Chapter
 [Humphrey 89]: Watts S. Humphrey: Managing the software process,
Addison-Wesley 1989, ISBN:0-201-18095-2
 [Anderson 10]: David J. Anderson: Kanban. Blue Hole Press, 2000, ISBN
978-0-984521401
 [Holland 99]: Holland, Dick. "Document Inspection as an Agent of
Change," Software Quality Professional, Vol. 2, No. 1 (December 1999), pp.
22-33.
43


Vielen Dank für Ihre Aufmerksamkeit!

QA
&

[Sebastian Dietrich]
Sebastian.Dietrich@e-movimento.com
http://managing-java.blogspot.com

44


Kosten technischer Qualität in der Softwareentwicklung

Weitere ähnliche Inhalte

Was ist angesagt?

Andere mochten auch

Ähnlich wie Kosten technischer Qualität in der Softwareentwicklung

Kosten technischer Qualität in der Softwareentwicklung