Your SlideShare is downloading. ×
Best Practise - technische Qualitätssicherung
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Best Practise - technische Qualitätssicherung

460
views

Published on

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.

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.

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
460
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Technische Qualitätssicherung im Projekt und deren praktische Umsetzung OLIVER WRONKA JANUAR 2014 Best Practise – Technische Qualitätssicherung
  • 2. Agenda 2 » Inhalt » Die verschiedenen Ebenen der technischen Qualitätssicherung » Praktische Beispiele für die Ebenen » Vorbereitende Maßnahmen » Gegenmaßnahmen
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Backup
  • 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. 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!