Technische Qualitätssicherung im Projekt und deren praktische
Umsetzung
OLIVER WRONKA
JANUAR 2014
Best Practise – Technisc...
Agenda
2
» Inhalt
» Die verschiedenen Ebenen der technischen
Qualitätssicherung
» Praktische Beispiele für die Ebenen
» Vo...
Inhalt
3
» Nicht immer wird in einem Projekt von Beginn an eine
technische Qualitätssicherung aufgebaut.
» Ist dies jedoch...
Die verschiedenen Ebenen der technischen
Qualitätssicherung
4
Die technische Qualitätssicherung kann in vier Ebenen untert...
Praktische Beispiele – Codierrichtlinien
(Kommentierung, Formatierung)
Guter Code:
/**
* Die Funktion calcTax berechnet
* ...
Praktische Beispiele – Codierrichtlinien
(Defensive Programmierung)
Guter Code:
int addPerson (String firstName, String la...
Praktische Beispiele – Codierrichtlinien
(Beispiel für einen Bericht)
7
Tools zur Überprüfung von Codierrichtlinien gibt e...
Praktische Beispiele –
Statische Quellcodeanalyse
8
Die statische Quellcodeanalyse ist eine sinnvolle Ergänzung zu
den Cod...
Codierrichtlinien
Statische Quellcodeanalyse
Testabdeckung
Metriken
Praktische Beispiele – Statische
Quellcodeanalyse (Bei...
Codierrichtlinien
Statische Quellcodeanalyse
Testabdeckung
Metriken
10
» Alle Entwickler müssen Testfälle schreiben die sp...
Praktische Beispiele - Metriken
11
Metriken sind die Kür der technischen Qualitätssicherung und
müssen mit Bedacht angewen...
Praktische Beispiele - Metriken
12
NBD: Nested Block Deep – Verschachtelungstiefe
Eine Verletzung dieser Metrik zeigt an, ...
Praktische Beispiele - Metriken
13
VG: McCabe Cyclomatic Complexity
Vereinfacht werden hier einfach die Anzahl der Verzwei...
Praktische Beispiele - Metriken
Schlechtes Design
class complex {
private int zustand;
void method1 () {
if (zustand == 1)...
Vorbereitende Maßnahmen
15
Die technische Qualitätssicherung sollte zu Beginn eines Projekts
eingefordert bzw. aufgesetzt ...
Gegenmaßnahmen
16
Ist dies nicht der Fall so kann man diese in einem laufenden
Projekt einführen.
» Ist ein Projekt gestar...
Gegenmaßnahmen
17
» Sind die DoD etabliert so können diese nun in einem
zweiten Schritt dafür genutzt werden, die Codequal...
Backup
DoD Java
19
» Der Code erfüllt alle an ihn gestellten funktionalen Anforderungen (Todos erledigt)
» Der Code muss fehlerfr...
Unsere Standorte
Niederlassung Köln
Wilhelmstraße 3
51143 Köln
Tel +49 22 03 – 91 22 0
Fax +49 22 03 – 91 22 23
Niederlass...
Nächste SlideShare
Wird geladen in …5
×

Best Practise - technische Qualitätssicherung

1.069 Aufrufe

Veröffentlicht am

Diese Präsentation zeigt die technische Qualitätssicherung im Projekt und deren praktische Umsetzung und wurde von Oliver Wronka, Principal Architect/ Project Manager bei axxessio, erstellt.

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.069
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
3
Aktionen
Geteilt
0
Downloads
7
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Best Practise - technische Qualitätssicherung

  1. 1. Technische Qualitätssicherung im Projekt und deren praktische Umsetzung OLIVER WRONKA JANUAR 2014 Best Practise – Technische Qualitätssicherung
  2. 2. Agenda 2 » Inhalt » Die verschiedenen Ebenen der technischen Qualitätssicherung » Praktische Beispiele für die Ebenen » Vorbereitende Maßnahmen » Gegenmaßnahmen
  3. 3. Inhalt 3 » Nicht immer wird in einem Projekt von Beginn an eine technische Qualitätssicherung aufgebaut. » Ist dies jedoch der Fall so werden Daten geliefert, die sich nicht automatisch jedem Erschließen » Diese Präsentation soll zum Einen einen Überblick darüber verschaffen, wie eine TQS aufgebaut ist und zum Anderen, wie mit den gewonnenen Daten umgegangen werden kann. » Zu guter Letzt wird darauf eingegangen, wie eine schlechte, technische Qualität von vornherein vermieden werden kann bzw. wie eine Kehrtwende zum Besseren in einem Projekt erreicht werden kann.
  4. 4. Die verschiedenen Ebenen der technischen Qualitätssicherung 4 Die technische Qualitätssicherung kann in vier Ebenen unterteilt werden. Man kann vier Ebenen der TQS definieren: Codierrichtlinien: Diese geben vor wie ein Quelltext zu formatieren und zu kommentieren ist. Darüber hinaus sind häufig auch Richtlinien vorhanden die auf einen defensiven und insbesondere sicheren Programmierstil verweisen. Statische Quellcodeanalyse: Mit Hilfe von Tools können Programmierfehler im Programmcode erkannt werden. Testabdeckung: Mit Hilfe von automatisierten Tests können Anwendungen nicht nur zyklisch getestet werden. Darüber hinaus kann auch die dabei erreicht Testabdeckung ermittelt werden und ungetestete Codestrecken ermittelt werden. Metriken: Metriken sind die Kür in der TQS. Wenn Code z.B. stabil gegenüber Änderungen sein soll so helfen Metriken, dies sicher zu stellen. Codierrichtlinien Statische Quellcodeanalyse Testabdeckung Metriken
  5. 5. Praktische Beispiele – Codierrichtlinien (Kommentierung, Formatierung) Guter Code: /** * Die Funktion calcTax berechnet * die Mehrwertsteuer zu einem * übergebenen Preis * @param price der Nettopreis * @return 19% vom Nettopreis **/ double calcTax (double price) { if (price < 0) { /* mit einem negativen Betrag können wir nichts anfangen, daher Vorzeichen umkehren */ return price * -0.19; } return price * 0.19; } Schlechter Code: double c(double p){return p<0 p*-0.19:p*0.19;} 5 Codierrichtlinien sind die Basis und bewirken, dass Code überhaupt lesbar ist. Die Methode ist dokumentiert Parameter und Rückgabe sind dokumentiert Eine Anweisung pro Zeile, Blöcke sind eingerückt. Fachliche Anforderung und deren Umsetzung sind dokumentiert. Codierrichtlinien Statische Quellcodeanalyse Testabdeckung Metriken
  6. 6. Praktische Beispiele – Codierrichtlinien (Defensive Programmierung) Guter Code: int addPerson (String firstName, String lastName) { if (firstName == null || firstName.length() == 0) { return ERR_NO_FIRST_NAME; } if (lastName == null || lastName.length() == 0) { return ERR_NO_LAST_NAME; } return db.insertPerson (firstName, lastName); } Schlechter Code: void addPerson (String name1, String name2) { db.insert (name1, name2); } 6 Codierrichtlinien führen letztendlich zu robustem Code. Die Parameter werden geprüft. Dies ist ein defensiver Programmierstil. Im Fehlerfall werden eindeutige Codes zurückgeliefert Codierrichtlinien Statische Quellcodeanalyse Testabdeckung Metriken
  7. 7. Praktische Beispiele – Codierrichtlinien (Beispiel für einen Bericht) 7 Tools zur Überprüfung von Codierrichtlinien gibt es schon seit langem und sind frei verfügbar. Dies ist ein typischer Auszug einer automatisierten Überprüfung der Codierrichtlinien. In diesem Fall durch das frei verfügbare Checkstyle. Hier häufige Verletzung dieser Checkstyle-Regel weist darauf hin, das der Programmierer lieber der Kreativität anhängt anstatt von Zeit zu Zeit auch mal seine geistigen Ergüsse zu dokumentieren. Verschärftes „DuDu“ aussprechen! Codierrichtlinien Statische Quellcodeanalyse Testabdeckung Metriken
  8. 8. Praktische Beispiele – Statische Quellcodeanalyse 8 Die statische Quellcodeanalyse ist eine sinnvolle Ergänzung zu den Codierrichtlinien. Offensichtliche Programmierfehler können toolgestützt erkannt werden. String concat (String firstName, String lastName) throws ApplicationException { String name = firstName.toUpperCase () + lastName.toUpperCase (); if (firstName == null || lastName == null) { throw new ApplicationException („FirstName or LastName is null“); } return name; } Das ist grober Unfug! Auf beide Variablen wird im Statement zuvor bereits zugegriffen, sodass dort bereits eine Nullpointer- Excpetion auftritt. Die ApplicationException kann also niemals geworfen werden. Codierrichtlinien Statische Quellcodeanalyse Testabdeckung Metriken
  9. 9. Codierrichtlinien Statische Quellcodeanalyse Testabdeckung Metriken Praktische Beispiele – Statische Quellcodeanalyse (Beispiel für einen Bericht) 9 Diese ist in der Lage echte Programmierfehler zu finden die in der Ausführung des Programms zu schweren Fehlern führen können. Dies ist ein typischer Auszug einer statischen Quellcodeanalyse. In diesem Fall durch das frei verfügbare FindBugs. Dieser Code läuft nur sofern die Anwendung die entsprechende Verzeichnisstruktur (*) vorfindet. „Peitschenhiebe“ androhen! (*) Anm. des Autors: Gilt nicht mehr bei Continious Delivery
  10. 10. Codierrichtlinien Statische Quellcodeanalyse Testabdeckung Metriken 10 » Alle Entwickler müssen Testfälle schreiben die später zyklisch in einer entsprechenden Buildumgebung ausgeführt werden. » Jeder Bugfix sollte einen Testcase nach sich ziehen, was im Laufe der Zeit zu einer vollständigen Testabdeckung führen kann. » Neben einer Übersicht zur Gesamtabdeckung können auch gezielt die Stellen identifiziert werden, die noch durch Hinzufügen weiterer Testcases abgedeckt werden müssen. » Idealerweise werden auch Stellen erkannt, die überhaupt nicht mehr genutzt werden (fachlich toter Code). Automatisiertes Testen und die kontinuierliche Steigerung der erreichten Testabdeckung führen zu einer wirklich fehlerfreien Anwendung.
  11. 11. Praktische Beispiele - Metriken 11 Metriken sind die Kür der technischen Qualitätssicherung und müssen mit Bedacht angewendet werden. Eine geringe Anzahl von Metriken reicht, um die Qualität des Quellcodes einschätzen zu können. Die wichtigsten Metriken sind: MLOC: Methods Lines of Code – Anzahl der Quellcodezeilen je Methode Diese Metrik besagt, dass die Anzahl von Quellcodezeilen je Methode z. B. unter 100 liegen sollte. Ist diese Zahl wesentlich größer so kann davonausgegangen werden, dass man eine sogenannte Gottmethode hat. Dies ist eine Methode, die eigentlich „Alles“ macht. Solche Methoden sind schwer zu warten (schon alleine deswegen, weil diese nicht auf den Monitor passen) und zu testen. TLOC: Total Lines of Code – Anzahl der Quellcodezeilen je Klasse Hierfür gilt das bereits oben gesagt für eine Klasse statt nur einer Methode Codierrichtlinien Statische Quellcodeanalyse Testabdeckung Metriken
  12. 12. Praktische Beispiele - Metriken 12 NBD: Nested Block Deep – Verschachtelungstiefe Eine Verletzung dieser Metrik zeigt an, dass es sich um sehr komplexen Code handelt. Ein Beispiel: void complex (int param1, int param2, int param3, int param4, int param5) { if (param1 < 1) { if (param2 > 2) { if (param3 != 3) { if (param4 == 4) { if (param1 == param3) { /* dann tu ich was */ } else { /* dann tu ich was anderes */ } } } else { /* hm, ich glaube ich gehöre zu f (param2 > 2){ if (param5 == 5) { /* dann tu ich eben was anderes, vorausgesetzt param5 ist 5 */ } } } } } Codierrichtlinien Statische Quellcodeanalyse Testabdeckung Metriken
  13. 13. Praktische Beispiele - Metriken 13 VG: McCabe Cyclomatic Complexity Vereinfacht werden hier einfach die Anzahl der Verzweigungen je Methode gezählt. Ein Wert von über 10 weist darauf hin, dass die Methode sehr komplex ist und somit fehleranfällig. Sehr häufig deckt diese aber auch Schwächen im Codedesign auf. Ein Beispiel: Häufig findet man im Code Verzeigungen die die Verarbeitung steuern basierend auf dem inneren Zustand einer Klasse. Codierrichtlinien Statische Quellcodeanalyse Testabdeckung Metriken
  14. 14. Praktische Beispiele - Metriken Schlechtes Design class complex { private int zustand; void method1 () { if (zustand == 1) { /* ich tue dieses */ } else { /* ich tue jenes */ } } void method2 () { if (zustand == 1) { /* ich tue dieses */ } else { /* ich tue jenes */ } } } Gutes Design interface simple { void method1 (); void method2 (); } class quiteSimple implements simple { void method1 () { /* ich tue dieses */ } void method2 () { /* ich tue dieses */ } } class verySimple implements simple { void method1 () { /* ich tue jenes */ } void method2 () { /* ich tue jenes */ } } 14 int main (argv[]) { int zustand = argv[0]; Simple s; if (zustand == 1} { s = new quiteSimple (); } else { s = new verySimple (); } } Was passiert wenn ein weiterer Zustand mit dem Wert 3 eingeführt wird ? Codierrichtlinien Statische Quellcodeanalyse Testabdeckung Metriken
  15. 15. Vorbereitende Maßnahmen 15 Die technische Qualitätssicherung sollte zu Beginn eines Projekts eingefordert bzw. aufgesetzt werden » Wird ein Projekt neu ausgeschrieben, so sind die Anforderungen an die TQS in den Vertrag mit auszunehmen. » Idealerweise wird die aufzubauende Umgebung für das Continiuos Integration beschrieben (z. B. maven zusammen mit Jenkins) und die zu erstellenden Reports (z. B. Checkstyle, FindBugs, Cobertura) beschrieben. » Sind die Reportingmodule definiert so sollte man die zugehörigen Konfigurationsdateien (z. B. checkstyle.xml) direkt mitliefern. » Die Konfigurationsdateien sollten im Repository (z. B. Subversion) abgelegt und versioniert werden. Dies verhindert „unbeabsichtigte“ Änderungen an den Konfigurationsdateien.
  16. 16. Gegenmaßnahmen 16 Ist dies nicht der Fall so kann man diese in einem laufenden Projekt einführen. » Ist ein Projekt gestartet ohne die Anforderungen an die TQS im Vertrag festzuhalten, so können Gegenmaßnahmen wie folgt ergriffen werden: » In einem Workshop werden „Definitions of Done“ definiert und dokumentiert. » Die DoD beinhalten eine Liste von Eigenschaften die ein Softwareartefakt haben muss, bevor die Aufgabenstellung als „erledigt“ betrachtet werden kann. » Die DoD sind eine freiwillige Selbstverpflichtung die nicht abnahmerelevant ist. » Erfahrungen haben gezeigt, dass die Teams untereinander in einen Wettstreit treten, wer den besten Code schreibt.
  17. 17. Gegenmaßnahmen 17 » Sind die DoD etabliert so können diese nun in einem zweiten Schritt dafür genutzt werden, die Codequalität schrittweise anzuheben. » Hierzu werden die DoD nun als abnahmerelevant erklärt. » Es ist eine Baseline zu ermitteln die dokumentiert, in wie weit der aktuelle Sourcecode die DoD nicht erfüllt. » Es ist je Release eine nichtfunktionale Anforderung einzustellen die fordert, das 20% der Fehler zu beseitigen sind. » Nach fünf Release sollten die DoD dann erfüllt sein und zukünftig auch eingehalten werden. » Im Backup sind die DoD für Java beigefügt.
  18. 18. Backup
  19. 19. DoD Java 19 » Der Code erfüllt alle an ihn gestellten funktionalen Anforderungen (Todos erledigt) » Der Code muss fehlerfrei kompilieren » Die Unittests müssen fehlerfrei durchlaufen. » Der Code muss vollständig eingecheckt sein. Hierzu gehören neben den eigentlichen Quellcodedateien auch die zugehörige Dokumentation sowie die Unittests. » Der Code ist an alle relevanten Stellen gemerged. » Der Code muss den Richtlinien für Java entsprechen. Diese lauten: » Die Codierrichtlinien für Java sind einzuhalten. Die Einhaltung dieser Richtlinien wird durch ein Maven-Checkstyle-Plugin im Rahmen der Continious Integration täglich überprüft. Die entsprechende Konfigurationsdatei ist im WiKi abgelegt unter Java_Checkstylekonfiguration und kann auch in Eclipse eingebunden werden. Die formelle Korrektheit (Einrücktiefe, Tabsize, Klammersetzung usw.) des Codes kann sichergestellt werden durch die Java Formatterkonfiguration für den Eclipse Sourcecodeformatter. » Die Sicherheitsrelevante Codierrichtlinien für Java sind einzuhalten. Die Einhaltung dieser Richtlinien wird durch Quellcodreviews geprüft. » Der Code darf keine FindBugs-Regeln verletzen. Die Einhaltung dieser Richtlinien wird durch ein Maven-FindBugs-Plugin im Rahmen der Continious Integration täglich überprüft. » Die Testabdeckung muss mindestens 65% auf Paketeben betragen. Die Einhaltung dieser Richtlinien wird durch ein Maven-Cobertura-Plugin im Rahmen der Continious Integration täglich überprüft. » Es sind folgende Softwaremetriken einzuhalten » DIT: Depth Of Inheritance Tree (Vererbungstiefe) darf nicht größer sein als 6 » MLOC: Method Lines Of Code (Anzahl Quellcodezeilen je Methode) darf nicht größer sein als 100 » TLOC: Total Lines Of Code (Anzahl Quellcodezeilen je Klasse) darf nicht größer sein als 2000 » NBD: Nested Block Deep (Verschachtelungtiefe) darf nicht größer sein als 5 » PAR: Parameter (Anzahl der Parameter je Methode) darf nicht größer sein als 5 » VG: McCabe Cyclomatic Complexity (vereinfacht ist dies die Anzahl der Verzweigungen je Methode, darf nicht größer als 10 sein. » WMC: Weighted Method Complexity ist die Summe aller VG einer Klasse, darf nicht größer sein als 50 » Die Einhaltung dieser Softwaremetriken wird durch das Eclipse-Metrics-Plugin überprüft.
  20. 20. Unsere Standorte Niederlassung Köln Wilhelmstraße 3 51143 Köln Tel +49 22 03 – 91 22 0 Fax +49 22 03 – 91 22 23 Niederlassung Darmstadt Kasinostraße 60 64293 Darmstadt Tel +49 61 51 – 78 90 0 Fax +49 61 51 – 78 90 23 0 Hauptsitz Bonn Kurfürstenallee 5 53177 Bonn Tel +49 228 – 76 36 31 0 Fax +49 228 –76 36 31 3 Niederlassung Bern Frohbergweg 7 3012 Bern Tel +41 31 – 534 07 06 Fax +41 31 – 536 69 78 Consider IT done!

×