Wenn von Softwarequalität im Unternehmen gesprochen wird sind sich Software-Entwickler, –Architekten und Product-Owner meist einig, denn „Software muss nachhaltig entwickelt werden!“. Doch was ist eigentlich nachhaltige Software? Wie kann Nachhaltigkeit messbar und damit auch managebar gemacht werden? Wie kann Software tatsächlich nachhaltig entwickelt werden? Im Nachfolgenden ein paar grundlegende Gedanken:

 

Was ist eigentlich nachhaltige Software?

Eine Software ist dann nachhaltig, wenn sie folgende Eigenschaften mindestens bis zum geforderten Maße (Achtung: das sollte im Projekt definiert werden) berücksichtigt:

  1. Energie- und Ressourceneffizienz
  2. Wirtschaftlichkeit
  3. Verfügbarkeit
  4. Sozialverträglichkeit
  5. Kultur

Im Kern handelt es sich also um mehr, als „nur“ sauber geschriebener, fachlich korrekter und getesteter Source Code. Die Punkte Sozialverträglichkeit und Kultur lassen sich aus Entwickler-Sicht meist nur in geringem Maße beeinflussen (z.B. im UX Design). Diese Themen müssen bereits in der Anforderungs-Analyse und beim Definieren der globalen EPICs von den Product Ownern und der Organisation geklärt werden. Dabei helfen Business Analysten, die zwischen Technik und Betrieb vermitteln. So könnte z.B. durch Organizational Change Management der Faktor Mensch mit einbezogen und somit die Sozialverträglichkeit sowie die kulturellen Hemmnisse analysiert werden.

Energie- und Ressourceneffizienz, Wirtschaftlichkeit sowie Verfügbarkeit liegen jedoch stark in der Hand der Software-Architekten und -Entwickler.

 

Wie kann Nachhaltigkeit messbar gemacht werden?

Natürlich kann man, mit genug Ausdauer und Zeit, Software manuell analysieren und bewerten. Dabei wird man sich unter Anderem mit folgenden Fragen beschäftigen:

  1. Wie gut ist die Software dokumentiert (JavaDoc + UML)?
  2. Gibt es technische Konzepte und dokumentierte Architekturentscheidungen?
  3. Existieren Entwicklerhandbücher / How2s?
  4. Welche Arten von UML-Diagrammen existieren und sind auf dem aktuellen Stand?
  5. Wie hoch ist die Testabdeckung?
  6. Welche Qualität (fachlich & technisch) haben die Tests?
  7. Wie lange dauert die Einarbeitung neuer Mitarbeiter?
  8. Werden funktionale und nichtfunktionale Anforderungen eingehalten?
  9. Generiert die Anwendung einen messbaren „Business-Value“?

Da sich Unternehmenssoftware stetig weiter entwickelt, ist der Aufwand sehr hoch eine solche Bewertung manuell zu aktualisieren und zu managen. Abhilfe schaffen Tools, die bei jedem Build (Continuous Integration / Continuous Delivery vorausgesetzt) den Code analysieren und bewerten. Sie gehören zu den Werkzeugen der dynamischen Code-Analyse. In der Java Welt bietet sich die OpenSource-Anwendung „SonarQube“ an. Sie ist weit verbreitet und integriert einige ausgereifte Analysewerkzeuge und Metriken. Natürlich gibt es auch Alternativen wie „Panopticode“, „Squale“ oder „CodePro Analytix“. Eins haben alle Tools gemeinsam: Sie untersuchen den Code und die JavaDoc, nicht jedoch Klartext-Dokumentationen und UML-Diagramme oder einen abstrakten Business-Value.

Somit kann eine Anwendung wie „SonarQube“ automatisiert Hinweise auf Nachhaltigkeit, Wartbarkeit und Qualität geben, selten aber alle erforderlichen Faktoren zur Bewertung mit einbeziehen.

 

Wie kann eine Software nun nachhaltig entwickelt werden?

Nachhaltigkeit muss durch den gesamten Lebenszyklus einer Anwendung hindurch gemanagt werden, d.h. es müssen messbare Ziele definiert werden und diese regelmäßig geprüft werden. Werden Abweichungen festgestellt müssen diese schnellst möglich korrigiert und gegengesteuert werden.

Angefangen von der Architektur bzw. den Entwurfsmustern der Anwendung wie z.B. Modularisierung über SOA oder MicroServices, über die technischen Designs, bis hin zum eigentlichen Code, begleitet die Frage nach der Nachhaltigkeit den Umsetzungsprozess.

Hier lediglich ein Gedankenspiel zum Thema nachhaltige Entwicklung unter dem Aspekt der Automatisierung:

  1. Codestyle-Guide erstellen und Regeln in SonarQube hinterlegen. Damit gilt SonarQube als zentrale Stelle und somit führend für die Bewertung des Codestyles.
  2. Das Plugin SonarLint in die IDE (IntelliJ oder eclipse) integrieren. Es ermöglicht dem Entwickler vor jedem Check-In/Push die globalen Regeln gegen die lokalen Code-Änderungen zu prüfen.
  3. Jenkins Build mit Sonar-Plugin verknüpfen. Der Build schlägt fehl, wenn die Qualitätsbewertung des Codes durch einen Check-In/Push verschlechtert wird (Quality-Gates).
  4. Feste Zeitblöcke in jeden Sprint einplanen, um technische Schulden abzubauen. Dazu werden Fehler priorisiert angegangen (Priorisierung erfolgt durch SonarQube) und Mitarbeitern zugewiesen. Auch das Zuweisen kann per SonarQube erfolgen. Technische Schulden entstehen auch durch fehlende Testabdeckung, d.h. in den freien Zeitblöcken werden auch Tests geschrieben.

Software kann nur dann auf lange Sicht nachhaltig entwickelt werden, wenn im Team eine gemeinsame Vision vorherrscht und diese verbindlich gemacht wird. Dies wird ohne automatisierte Code-Analyse nicht funktionieren können. Hilfreich sind auch Handbücher über die Entwicklung von Entities, Repositories, Business Services, dem Logging, Exception Handling etc.

Darüber hinaus muss auch auf fachlicher Ebene eine regelmäßige Überprüfung durchgeführt werden. Ist der Business-Value eines Use-Cases noch gegeben? Sind unsere fachlichen Dokumentationen der Software und die Handbücher aktuell? Welche Annahmen aus vorherigen Analysen sind inzwischen nicht mehr valide?

 

Fazit:

Nachhaltigkeit ist eine weitreichende, wettbewerbsentscheidende Eigenschaft von Business-Anwendungen. Sie muss begleitet werden von verschiedenen Personen, durch den gesamten Lebenszyklus einer Anwendung hindurch. Man benötigt viel Zeit und Engagement, um einen messbaren, durchgängigen Grad an Nachhaltigkeit in Software zu erreichen und diesen langfristig bei zu behalten. Zum Glück gibt es einige Hilfsmittel, die dem Java-Entwickler zur Hilfe kommen.