Kosten technischer Qualität in der Softwareentwicklung

e-movimento Software Design & Beratung GmbH

1030 Wien ● Marxergasse 7/26 ► www.e-movimento.com

Kosten Technischer Qualität

In der Softwareentwicklung

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://[email protected]

http://managing-java.blogspot.co.at

http://de.wikipedia.org/wiki/Benutzer:Sebastian.Dietrich

► www.e-movimento.com, Sebastian Dietrich

2

mailto:[email protected]



http://managing-java.blogspot.co.at/



http://de.wikipedia.org/wiki/Benutzer: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


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

*/

public void setEmail(String email) {

this.email = email;

}


4


Definition:



Verständlichkeit, Analysierbarkeit, Modifizierbarkeit, Anpassbarkeit,

Prüfbarkeit (ISO/IEC 9126)

Beispiel: public void setEmail(String email) {

if (email == null)

throw new IllegalArgumentException(„null“);

if (!Pattern.matches("[a-z0-9!#$% … @ … (?:[a-z … “)

throw new IllegalArgumentException(„invalid“);

this.email = email;

}


5


Definition:



Verständlichkeit, Analysierbarkeit, Modifizierbarkeit, Anpassbarkeit,

Prüfbarkeit (ISO/IEC 9126)

Beispiel:

public void setEmail(@Email String email) {

this.email = email;

}


6

Technische Qualität in der Softwareentwicklung Weitere Beispiele


7

Code-Smells & Programmierungs-Anti-Pattern:

Technische Qualität in der Softwareentwicklung Literatur


8

http://bit.ly/refactoring_fowler

http://bit.ly/cleancodecmartin

http://bit.ly/cleancoder

http://bit.ly/pragmaticprogrammer

http://bit.ly/codecomplete

Technische Qualität in der Softwareentwicklung Management Sicht


9

Goldene Wasserhähne Kosten – Nutzen Rechnung


10

Kosten Nutzen

€ 2.035,- (Messing) Hübscher

€ 3.035,- (vergoldet) Weniger Fehler

€ 13.820,- (Vollgold) Schnellerer Einbau

Bessere Wasserqualität

Schnelleres Händewaschen

Glückliche Installateure

Geringere Wartungskosten

…

Technische Qualität in der Softwareentwicklung Kosten – Nutzen Rechnung?


11

Kosten Nutzen

viel (keine Smells) Hübscherer Code

viel mehr (keine Anti-Pattern) Weniger Bugs

ungeheuer viel (beides nicht) Schnellere Implementierung

Bessere Produktqualität

Produktivere Software

Glückliche Entwickler


…

Technische Qualität in der Softwareentwicklung Kosten – Nutzen Rechnung?


12

Kosten Nutzen

viel (keine Smells) Hübscherer Code

viel mehr (keine Anti-Pattern) Weniger Bugs

ungeheuer viel (beides nicht) Schnellere Implementierung

Bessere Produktqualität

Produktivere Software



…

Technische Qualität in der Softwareentwicklung Kosten – Nutzen Rechnung


13

Kosten Nutzen

1. Höhere Produktivität?

Ziel:

Maßnahmen:


14

Höhere Produktivität in der Softwareentwicklung? Hypothese

Höhere technische Qualität

(automatisierte) Reviews &

Qualitätsverbesserungen


Höhere Produktivität


Ergebnis:

Entwicklungs-

kosten

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

Ziel:

Maßnahmen:


16

Höhere Produktivität in der Softwareentwicklung? Erkenntnis







Ergebnis:

Entwicklungs-

kosten

min.50%



17

Kosten Nutzen

1. Höhere Produktivität

2. Weniger Bugs?

Ziel:

Maßnahmen:


18

Weniger Bugs durch technische Qualität? Hypothese




Weniger Bugs

(nach Entwicklung)

Ergebnis:


Entwicklungs-

kosten

Weniger Bugs durch technische Qualität? Frage


19

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?

Weniger Bugs durch technische Qualität? Antwort

0%

10%

20%

30%

40%

50%

60%

70%

80%

90% % gefundene Fehler je Tätigkeit


20

Revie

ws

Entw

ickle

r Tests

Kla

ssis

che

Tests

[Jones 02]

Weniger Bugs durch technische Qualität? 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


22

Weniger Bugs durch technische Qualität? 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

Ziel:

Maßnahmen:


23

Weniger Bugs durch technische Qualität? Erkentnis:




Weniger Bugs

(nach Entwicklung)

Ergebnis:


min.10%

30%

bis

85%

Entwicklungs-

kosten



24

Kosten Nutzen


2. Weniger Bugs

3. Weniger Entstehungskosten?

Ziel:

Maßnahmen:


25

Weniger Entstehungskosten durch techn. Qualität? Hypothese




Weniger Bugs

(nach Entwicklung)

Ergebnis:


Weniger Testaufwand Weniger Bugfixing-

aufwand



Entwicklungskosten

Weniger

Entstehungskosten

Weniger Entstehungskosten durch techn. Qualität? 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 Entstehungskosten durch techn. Qualität? Weniger Testaufwand

Antwort:

„Man spart sich Regressionstest-Durchgänge“ (ca. 10%)

„Man spart sich Fehlerbehebungsaufwände“ (40%-95%

weniger Fehler 36%-85,5% weniger Aufwand)


27

Test

Gefundene

Fehler

Fehlerbehebung

~1 Fehler / Testfall

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

0,5 – 0,8 neue Fehler je Fix

~1 PT / Fehler

= x10 wie während

Entwicklung

Solange bis

Akzeptanzkriterien

erfüllt

Weniger Entstehungskosten durch techn. Qualität? 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

En

twic

klu

ng

Te

st

Weniger Entstehungskosten durch techn. Qualität? Kosten - Nutzenrechnung

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

Weniger Entstehungskosten durch techn. Qualität? 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

Ziel:

Maßnahmen:


32

Weniger Entstehungskosten durch techn. Qualität? Erkenntnis:




Weniger Bugs

(nach Entwicklung)

Ergebnis:



aufwand



Entwicklungskosten

Mehr/Weniger

Entstehungskosten

ca.10% 36%-85% 46% -

95%

10%-105%

50%-170%

+7% bis -253%



33

Kosten Nutzen


2. Weniger Bugs

3. Weniger Entstehungskosten

4. 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

Ziel:

Maßnahmen:


35

Deutlich geringere Gesamtkosten durch techn. QS? Hypothese




Weniger Bugs

(nach Entwicklung)

Ergebnis:


Entwicklungskosten

Deutlich geringere

Gesamtkosten



Weniger Wartungsaufwand


aufwand

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

So

ftw

are

wa

rtun

g

So

ftw

are

entw

icklu

ng

Deutlich geringere Gesamtkosten durch techn. QS? Kosten - Nutzenrechnung


37

So

ftw

are

test

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

Ziel:

Maßnahmen:


38

Deutlich geringere Gesamtkosten durch techn. QS? Erkenntnis:




Weniger Bugs

(nach Entwicklung)

Ergebnis:


Entwicklungskosten

Deutlich geringere

Gesamtkosten



Weniger Wartungsaufwand


aufwand

ca.10% 36%-85%

46% -

95%

10%-105%

50%-170%

min. 20%

11%-73%

Technische Qualität in der Softwareentwicklung Kosten – Nutzen Rechnung: Fazit


39

Kosten Nutzen

Gratis Flexibel für Änderungen

Amortisiert sich bereits

während der Entwicklung

Deutlich weniger Bugs

(min. 40% weniger)

Schnellere Fertigstellung

(bis zu 250% schneller)


(min 20% geringer)

Geringere Gesamtkosten

(min 11% geringer)


Glückliche Endkunden

Technische Qualität in der Softwareentwicklung Kosten – Nutzen Rechnung: Fazit


40

Technische Qualität in der Softwareentwicklung 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:


Limbo mit Softwarequalität: http://managing-

java.blogspot.co.at/2012/05/limbo-mit-softwarequalitat.html


41

https://de.wikipedia.org/wiki/Codequalität






https://de.wikipedia.org/wiki/Anti-Pattern


















http://managing-java.blogspot.co.at/2012/05/limbo-mit-softwarequalitat.html








Technische Qualität in der Softwareentwicklung 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-95-

TR-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

Technische Qualität in der Softwareentwicklung 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


44

Vielen Dank für Ihre Aufmerksamkeit!

Q&A [Sebastian Dietrich]

[email protected]

http://managing-java.blogspot.com




Date post:	24-Jan-2015
Category:	Technology
Upload:	sebastian-dietrich
View:	482 times
Download:	1 times

Kosten technischer Qualität in der Softwareentwicklung

Technology