Freitag, 10. Februar 2012

Quality Gates bei Java Entwicklung

Quality Gates in der Softwareentwicklung
CC-BY-SA Wikipedia
Die einzige Maßnahme, die die Qualität einer Software sicherstellen kann ist die Einführung von Quality Gates. Alle anderen "Qualitätssicherungsmaßnahmen" wie Pair Programming, Tests, Metriken etc. können die Qualität aufzeigen oder auch verbessern, aber niemals sicherstellen.
"Quality Gates sind Punkte im Ablauf eines Entwicklungsprojekts, bei denen anhand von im Voraus eindeutig bestimmten Qualitätskriterien über die Freigabe des nächsten Projektschrittes entschieden wird." - Jochen Peter Sondermann: Interne Qualitätsanforderungen und Anforderungsbewertung in Handbuch Qualitätsmanagement
"Freigabe des nächsten Projektschrittes" - das ist in der Softwareentwicklung die entscheidende Herausforderung.

Sinnlose Quality-Gate
CC-BY-SA Wikipedia
Einerseits gehen die Projektschritte auf Grund der immer agileren IT-Prozesse mehr ineinander über, andererseits halten sich (zumindest in der IT-Branche) Entscheider nur selten an ihre eigenen Vorgaben. Es wird sich kaum ein Projektleiter / Auftragnehmer / Auftrageber finden lassen, der die Auslieferung einer fachlich korrekten Software unterbindet, weil diese eine technische Quality Gate (wie z.B. "Zyklomatische Komplexität kleiner als 11") nicht erreicht. Quality Gates funktionieren wie andere Tore nur, wenn sie nicht nach Belieben geöffnet, untergraben oder umgangen werden können.

Die einzige Maßnahme um Quality Gates in der Softwareentwicklung sicherzustellen ist der Einbau von Quality Gates in den Build- und Deploymentprozess. Wird eine Quality Gate nicht eingehalten, so erkennt das ein Tool am Continuous Integration Server und bricht den Build ab. Quality Gate nicht erreicht à kein erfolgreicher Build à keine Auslieferung. Bei den heute üblichen kurzen Buildzyklen führt diese Vorgangsweise zu geringen Aufwänden, da die Behebung des Fehlers zeitnah zum Einbau des Fehlers erfolgt.

Welche Quality Gates aber sind für die Java Entwicklung geeignet? Es gibt eine große Menge an Architektur-, Design-, Code- und Testmetriken für die man Quality Gates einführen könnte. Nicht alle sind in jedem Softwareentwicklungsprojekt geeignet. Fail-Fast gilt auch bei Quality Gates - erkennt man Fehler bereits in der Entwicklungsumgebung ist das produktiver als sie erst beim Build zu erkennen. Darum werden bei der folgenden Aufstellung Tools bevorzugt, die sowohl in der IDE als auch im Build eingesetzt werden können:
  • Quality Gates für Architektur: Über Qualität einer Architektur lässt sich lange streiten. Das einzige was unumstritten ist (und dennoch meist nicht eingehalten wird), ist dass a) eine Architektur zyklenfrei sein muss und b) korrekt umgesetzt werden muss. Es gilt also im Build sicherzustellen, dass es keine komponentenübergeifende Zyklen oder unerlaubte statische Abhängigkeit zwischen zwei Architekturkomponenten gibt. Beides kann man einfach ausschließen, indem man die Komponenten in unterschiedliche Projekte packt und Änderungen der Projektabhängigkeiten (in den .project oder pom.xml oder manifest Files oder wo auch immer) nicht zulässt (d.h.die Files locked). Alternativ kann man dafür auch Tools wie Macker, JDepend, Sonargraph sowohl in der IDE als auch beim Build einsetzen.
  • Quality Gates für Softwaredesign: Fürs Softwaredesign gibt es zwar jede Menge allgemeingültiger Vorgaben (z.B. die Prinzipien objektorientierten Designs), aber nur wenige Metriken um diese in Form von Quality Gates zu messen. Die mMn sinnvollste Quality Gate für Softwaredesign wäre die Erkennung von Codewiederholungen. Doppelter Code ist in der Objektorientierung immer ein Zeichen schlechten Designs - dieser kann auch leicht mit Tools wie CPD oder Checkstyle sowohl in der IDE als auch beim Build geprüft werden.
  • Quality Gates für Implementierung: Die für die Wartbarkeit wichtigsten Implementierungsmetriken sind die Größen- und Komplexitätsmetriken, beispielsweise Anweisungen oder LOCs / Methode, sowie Komplexitätsmetriken wie die McCabe Metrik. Die Einhaltung dieser Quality Gates kann leicht mit Tools wie PMD oder NCSS sowohl in der IDE als auch beim Build sichergestellt werden
  • Quality Gates für Unit-Tests: Die übliche Kenngröße für die Qualität von Unit-Tests ist deren Code-Coverage (Line- und Branch-Coverage sind die aussagekräftigsten). Allerdings sagt diese Kennzahl nicht viel über die Qualität der Unit-Tests aus. Die für die Wartbarkeit einer Software wichtigste Kennzahl wäre "Wahrscheinlichkeit, dass zukünftige Codeänderungen durch Unit-Tests erkannt werden". Leider gibt es dafür (noch) keine geeigneten Tools (mutation-testing Tools gehen in diese Richtung sind aber in der Praxis viel zu langsam).
    Also bleibt zunächst nur die Coverage - diese sollte meiner Erfahrung nach mindestens 70% sein, da man erst bei diesem hohen Wert davon ausgehen kann, dass neuer Code bestehende Funktionalität vermutlich nicht bricht, wenn alle Unit-Tests durchgehen. Die Coverage lässt sich in der IDE überprüfen (z.B. mit EclEmma) und beim Build sicherstellen (z.B. mit CoberturaEmmaClover)
    Neben der Coverage sollte natürlich auch überprüft werden dass alle Unit-Tests durchlaufen (z.B. mit Surefire) und zumindest ein assert Statement enthalten. 
State-of-the-art bei Quality Gates ist die Verwendung von SonarQube. SonarQube kann - basierend auf den meisten hier erwähnten Tools - für ein gesamtes Projekt Qualitätsberichte in einem Dashboard zusammenfassen und ebenfalls in den Build dermaßen integriert werden, dass dieser fehlschlägt, wenn bestimmte Quality Gates nicht erreicht wurden.

Fazit: Einige (bei weitem nicht alle) Qualitätskriterien lassen sich in der Java Entwicklung automatisiert durch Quality Gates sicherstellen. Wer die Technik der Quality Gates nicht nutzt bekommt mit hoher Wahrscheinlichkeit eine deutlich schlechtere Qualität geliefert und zahlt dafür - auf Grund der daraus resultierenden hohen Wartungs- und Weiterentwicklungskosten - auch noch ein vielfaches.




3 Kommentare:

  1. Hi Sebastian,

    interessante Thesen. Mich würde es freuen, wenn die aktuelle A1 IT CRM Factory-Konzeption von diesen Überlegungen profitieren würde. Ein Schwerpunkt in dem Factory-Konzept liegt auf den Schnittstellen zwischen beteiligten Parteien - und damit auf Quality Gates für Architektur, Design, Implementierung und Test. Was für mich nich nicht ganz ersichtlich ist: geht es hier ausschliesslich um Java & Implementierung/Development an sich, oder lassen sich die Aussagen und Überlegungen auf pre-development und post-development (all das, was den Sourcing Partner nicht betrifft) erweitern?

    Meines Erachtens ist diesbezügliche Fokussierung und rigorose Orientierung auf die Quality Gates eines der Erfolgskriterien für Factory & Sourcing.

    Beste Grüße
    Boris Tabachnik

    AntwortenLöschen
  2. Die hier geschilderten Überlegungen gelten mal nur für Java & Implementierung/Development. Die können in einem Sourcing-Szenario natürlich von beiden Partnern geprüft werden.

    Ich denke aber, dass sich diese Überlegungen auch auf alles andere erweitern lassen. Die Herausforderungen dabei sind aber a) Definition eindeutig messbarer Quality-Gates, b) Effiziente Prüfung derselben und c) Sicherstellung, dass der nächste Projektschritt nur dann angegangen wird, wenn die Quality-Gate auch erreicht wurde.

    Punkto c) bin ich skeptisch. Es bedarf eines wirklich starken Managements, um als Auftraggeber z.B. wegen Dokumentationsschwächen eine Software nicht abzunehmen (also auch nicht in Betrieb zu nehmen).

    AntwortenLöschen
  3. a) im Rahmen der Factory-Konzeption ist das ein wichtiges Ziel bzw. Arbeitspaket

    b) versteht sich. Ohne ist und bleibt das nur ein Konzeptpapier

    c) Autsch. HAst du recht. Aktueller Rolloutstop läßt hoffen.

    AntwortenLöschen

web analytics