Softwarequalität an der Wurzel gepackt

1. Intro
2. Was verstehen wir unter Softwarequalität?
3. Am Anfang steht die Idee
4. Weiter voran mit dem Vorgehensmodell
5. Das Team spricht mit
6. Geschichten erzählen
7. Die vier Schlüsselmetriken
8. Fazit

1. Intro

Ein Sofa kann gemütlich weich sein, ein Apfel appetitlich rot, ein Lautsprecher einen wohligen Klang haben, oder ein Fahrrad leicht und aus einem Guss geformt sein. Wir ordnen allen Dingen mehr oder weniger subjektiv empfundene Eigenschaften zu und folgern aus Emotionen und Messwerten bewusst oder unbewusst, dass ein Produkt als Ganzes eine bestimmte Qualität aufweist.

Lassen Sie mich mit einer Frage beginnen: Was ist eigentlich Qualität? Jeder hat eine intuitive Vorstellung von Qualität. Wenn man tiefer einsteigt, gelangt man schnell in den psychoanalytischen Bereich, bei dem es um die Marke eines Produkts geht oder dass dem Produkt eine höhere Qualität zugesprochen wird, wenn es viele Menschen benutzen oder viel (positiv) davon sprechen. Eine große Rolle spielen hier also Emotionen, die zunächst durch Werbung transportiert und auch durch eigene Erfahrungen (z.B. durch Haptik) generiert werden. Durch das gezielte Erschaffen dieser positiven Emotionen werden auch weitere positive Eigenschaften suggeriert. Selbst eher negativ auffallende Merkmale können dadurch neutralisiert werden. Genau wie diese schwer fassbaren subjektiven Merkmale, kann eine Qualität auch durch harte Fakten und Zahlen dargestellt werden. So kann z.B. durch Angabe einer objektiv messbaren Messtoleranz auf die Qualität eines Produkts geschlossen werden.

Obwohl sich die Herstellung von Software in seinem Gesamtprozess grundlegend von der eines anfassbaren Produkts unterscheidet, trifft man hier auf ähnliche Erkenntnisse. Eine Software kann sich in der Verwendung „gut anfühlen“ oder eine bestimmte Performance-Messzahl erfüllen. Es kann aber auch sein, dass Performance oder die Bedienbarkeit keine Rolle spielen, wenn es darum geht, nächtliche Batch-Jobs zuverlässig zu verrichten.

2. Was also verstehen wir unter Softwarequalität

3. Am Anfang steht die Idee

Schon die erste Idee beeinflusst die Qualität des späteren Produkts maßgeblich. Hier werden bereits erste Ziele und Anforderungen formuliert. Je klarer hier schon Qualitätsziele definiert werden und je klarer die Systemgrenzen gezogen werden, umso zuträglicher ist das am Ende für die Produktqualität. Denn alle an dem Projekt Beteiligten können und werden sich in ihrer täglichen Arbeit an diesen Zielen orientieren. Und das ist der eigentliche Knackpunkt: Fehlen diese Leitplanken, führt das dazu, dass die Projektbeteiligten im Laufe des Entwicklungszyklus ihren auf Erfahrung basierenden eigenen Maßstab anlegen und im schlimmsten Fall gar nicht geforderte oder gar sich konkurrierende Qualitätsziele implementieren. Meist geschieht das nicht explizit, sondern implizit und die Folge davon ist eine zu komplexe oder zu unflexible Architektur der Software und des Entwicklungsprozesses.

4. Weiter voran mit dem Vorgehensmodell

In der Natur der Sache ist es, dass das Vorgehensmodell mal mehr, mal weniger frei bestimmt werden kann. Das hängt zusammen mit der Historie der Firma, einem vorhandenen Qualitätsmanagement und nicht zuletzt mit der Konstellation der Menschen, die das Projekt angehen.

Es macht immer Sinn zu hinterfragen, wie man voranschreiten möchte. Ein Vorgehensmodell darf auf keinen Fall zum Selbstzweck angewendet werden, sondern muss im Einklang mit den Zielen des jeweiligen Projekts und des Unternehmens sein.

Ein ggf. vorhandenes Qualitätsmanagement muss den Rahmen schaffen, sodass die Qualitätsziele eingehalten werden können. Denn diese sind das Maß der Dinge und bestimmen letztendlich auch den wirtschaftlichen Erfolg des Projekts. Sie sollten maßgeblich sein, welches Modell gewählt wird. Was hier so einfach steht, ist in der Realität eine sehr schwierige und vor allem andauernde Tätigkeit, deren Herausforderung darin besteht die richtige Dosis von Kommunikationskanälen, Dokumenten, Vorschriften und Richtlinien zu finden. Historisch haben wir hier eine enorme Bandbreite von Modellen, von Wasserfall und SPICE bis zu Scrum und XP. Ein Vorgehensmodell zu verstehen und richtig anzuwenden allein ist schon eine große Kunst. Ich möchte hier nicht diskutieren, welches Modell „besser“ ist, denn allen Modellen, ob schwergewichtig oder nicht muss fairerweise zugeschrieben werden, dass sie existieren, weil sie echte Schmerzen lösen wollen.

Dabei gibt es sicherlich Vorgehensmodelle, die das Erlangen bestimmter Qualitätsziele begünstigen oder behindern. Schon in sehr frühen Konferenzen über Softwareengineering, wie der NATO Software Engineering Conference 1968 [1], wurde schon viel über dieses Thema gesprochen (Siehe Abbildung 1).

Abbildung 1: Ein Foto von der NATO Software Engineering Konferenz 1968

Hier wurde nichts Geringeres als das Wort „Softwarekrise“ geprägt. Denn in den 1950er Jahren liefen die meisten größeren Softwareprojekte aus dem Ruder. Sie brauchten zu viel Budget, wurden selten in gegebener Zeit fertig und die Qualität der Software wurde sehr gering eingeschätzt. Ein Zitat zum Thema Softwaredesign von Douglas Ross möchte ich hier nicht unerwähnt lassen:

„The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from.“ – Douglas Ross, NATO Software Engineering Conference, 1968

Dieser Satz zielt darauf ab, dass es gefährlich ist, zu versuchen, eine Software von vornherein komplett zu spezifizieren und sie dann auch tatsächlich genauso zu implementieren. Weiter heißt es: „The projects that are called successful, have met their specifications. But those specifications were based upon the designers’ ignorance before they started the job.“

Schon damals war bekannt, dass die Softwarewelt eine sehr dynamische Welt ist. Dennoch wurden zu Beginn eines Projektes, an dem eigentlich sehr viel von dem zu implementierenden System noch unbekannt ist, wichtige Entscheidungen getroffen. Was aber hat das mit Qualitätszielen zu tun? Sehr viel, denn die hohen Kosten, die in dem Fall auftreten, dass erst sehr spät im Entwicklungszyklus Fehlentscheidungen erkannt werden, können mit sorgfältig gewählten Qualitätszielen kompensiert werden. Früh formulierte Qualitätsziele können, wenn sie im Projekt richtig gelebt werden, die Weichen in die richtige Richtung stellen.

5. Das Team spricht mit

Wo wir schon bei gelebten Zielen sind: Die Menschen in dem Projektumfeld sind also diejenigen, die die Qualitätsziele leben und die Verantwortung für die Einhaltung der Qualitätsziele tragen, aber auch die Früchte davon ernten. Was viele vergessen: In jedem Vorgehensmodell bestehen gewisse Freiheiten, die vom Team ausgenutzt werden können und auch müssen.

Alle Regeln sollen eine Hilfestellung sein, eine Checkliste. Die Menschen sind diejenigen, die kommunizieren und es in der Hand haben, wie kommuniziert wird. Sie sind diejenigen die entscheiden, wie umfangreich bestimmte Dokumente sind, wie Regeln ausgelegt werden. Entscheidend sind also in diesem Sinne die Schnittstellen zwischen den Projektbeteiligten.

Sind diese Schnittstellen transparent, werden Qualitätsziele intrinsisch eingehalten und Projekte im entsprechenden Rahmen erfolgreich. Etwas gewagt gesagt: Der Erfolg spricht dann für sich. Eine Qualitätssicherungsabteilung kann nicht in der Lage sein, nur durch Tests eine gute Qualität herbeizuführen. Denn durch Testen wird nicht aufgedeckt, ob ein minimaler Code geschrieben wurde, um Anforderungen abzudecken. Es wird auch nicht erkannt, ob Code lesbar geschrieben ist oder einfach zu verändern ist. Es ist unmöglich, durch Tests herauszufinden, ob Code unnötig komplex ist. Ebenso wird nicht geprüft, ob die Systemarchitektur für die Lösung passend ist [2].

Die Message ist: Silodenken ist unangebracht. Jeder Beteiligte ist für das Erreichen der Qualitätsziele in vollem Maße erforderlich. Transparente und einfache Kommunikationswege sind essenziell dafür.

6. Geschichten erzählen

Ein sehr schönes Mittel zur Kommunikation von Qualitätszielen sind die sogenannten Qualitätsszenarien, die auch in arc42, einer beliebten Vorlage für Architekturdokumentation, fester Bestandteil des Kapitels 10.2 sind [3]. Qualitätsszenarien sind Formulierungen von Szenarien, die auf bestimmte Qualitätsziele (z.B. aus ISO/IEC 25010) einzahlen und dabei einen konkreten Sachverhalt darstellen.

So sind sie ein Hilfsmittel zur Kommunikation mit Kunden, Stakeholdern und Entwicklerinnen und Entwicklern und können dabei Einfluss auf die Priorisierung der Anforderungen und damit auch auf die technische Architektur haben. Qualitätsszenarien können außerdem gut getestet werden, weil sie messbare Metriken liefern.​

Wir haben hier also ein Werkzeug, das uns den Stoff liefert, den wir für den konsistenten Transport der Qualitätsziele über alle Ebenen hinweg so dringend benötigen.

7. Die vier Schlüsselmetriken

Das Team rund um Google Cloud und den Autoren des sehr empfehlenswerten Buches „Accelerate“ [4] haben im dem wissenschaftlichen Projekt namens „DORA“ (DevOps Research and Assessments) aus den erfassten Daten vier Metriken herausgearbeitet, die Aufschluss auf die Performance und Stabilität eines Projekts geben sollen.

Das ist zum einen die Auslieferungsfrequenz („Deployment Frequency“), also die Häufigkeit, wie oft ein Projekt in Produktion gebracht werden kann. Außerdem wird die Zeit gemessen, wie lange es dauert, bis ein Code-Commit in Produktion ist („Change Lead Time“).

Eine weitere Metrik ist die Zeit, die für das Wiederherstellen eines Dienstes gebraucht wird, wenn dieser von einem Fehler betroffen ist („Mean Time To Restore“, MTTR). Die vierte Messzahl ist der Prozentuale Anteil von Ausfällen oder Fehlern, die nach einer Auslieferung auftreten („Change Fail Percentage“). Mit dem sogenannten DORA DevOps Quick Check [5] werden genau diese vier Metriken erhoben und dann eine Einschätzung gegeben, wo man mit seinem Projekt steht (Siehe Abbildung 2).

Abbildung 2: Screenshot des DORA DevOps Quick Check [5]

Das Spannende an diesen Metriken ist die Tatsache, dass sie auf den ersten Blick auf Schnelligkeit aus sind und sich womöglich die Frage aufdrängt: „Warum sollten wir so schnell ausliefern müssen? In unserem Prozess ist das sowieso nicht vorgesehen und die Kunden brauchen nicht mehrmals am Tag eine neue Version!“.

Bei genauerer Überlegung kommt man jedoch zum Schluss, dass die Erreichung einer hohen Ausliefergeschwindigkeit kein Selbstzweck ist, sondern die hier erhobenen Zahlen Rückschlüsse auf die Softwarequalität des Produkts zulassen. Denn gute Zahlen werden hier nur erreicht, wenn die Prozesse flüssig laufen, die Kommunikation funktioniert und der Code während der Paketierung sehr gut getestet wird. Insgesamt also sehr auf möglichst viel Automatisierung gesetzt wird. Mittel zum Zweck sind hier der konsequente Einsatz einer langen Reihe von „Fähigkeiten“, die in einem umfangreichen Katalog zusammengestellt sind [6].

Wie bereits erwähnt, sind es eben genau die vier „Key Metrics“, die auf eine gute oder schlechte Softwarequalität schließen lassen. Und, das ist das Bemerkenswerte, zwar eben nicht nur auf quantitativ messbare Merkmale, sondern auch schwierig messbare Merkmale wie Architektur oder Teamzusammenhalt.

8. Fazit

Was ist Qualität? Was ist Softwarequalität? Diese Fragen sind und bleiben schwer zu beantworten. Eines kann man festhalten: Es liegt dann eine gute Qualität vor, wenn die Qualitätsziele so gut wie möglich erfüllt sind. Anders kann man auch sagen, eine gute Qualität liegt dann vor, wenn möglichst viele am Projekt beteiligten Menschen zufrieden sind. Qualität ist also auch vom Betrachter abhängig und teils auch subjektiv.

Wenn man sich die Dialoge der NATO Software Engineering Conference 1968 genauer ansieht, erkennt man, dass die heutigen Probleme scheinbar immer noch die Gleichen sind. Der Unterschied ist aber, dass wir inzwischen einige Lösungen vorliegen haben und eine Menge Arbeit geleistet wurde, aus der Softwarekrise der 1950er Jahre Lehren zu ziehen. Im Laufe der Zeit entstanden viele Herangehensweisen und Modelle, die helfen, eine hohe Softwarequalität zu erreichen. Es liegt aber in unser aller Verantwortung, diese Lösungen und Werkzeuge auch sinnvoll einzusetzen. Wir müssen also von unserem bequemen Sofa aufstehen und dafür sorgen, dass wir Qualitätsziele einfordern oder definieren und an alle Projektbeteiligten in geeigneter Weise kommunizieren.

WERDE DIGITAL CHAMPION

Wie können Sie die Chancen und Potenziale digitaler Technologien optimal ausschöpfen, um Ihr bestehendes Geschäftsmodell zu erweitern und z. B. mit kundenzentrierten digitalen Produkten und Services, einen echten Mehrwert für Ihre Kunden zu generieren? Erfahren Sie, wie wir Sie unterstützen können:

Yves Schubert- ist seit über 15 Jahren beruflich und privat in vielen Softwareprojekten unterschiedlichster Technologiebereiche maßgeblich beteiligt. Von neuen Technologien und der schnelllebigen Softwarewelt lässt er sich schnell begeistern und versucht neue Trends auf ihre Nachhaltigkeit hin abzuklopfen. In der Praxis wendet er die Prinzipien des Software Craftsmanship an.

Dieser Artikel erschien ursprünglich in der Java Aktuell 06/22 und kann hier nachgelesen werden.

Quellen

[1] NATO Software Engineering Conference (1968), http://homepages.cs.ncl.ac.uk/brian.randell/NATO/NATOReports/index.html

[2] David Farley (2021): Modern Software Engineering: Doing What Works to Build Better Software Faster, Addison-Wesley Professional

[3] arc42 Template, Kapitel 10, https://docs.arc42.org/section-10/

[4] Ph.D. Forsgren, Nicole, Jez Humble, Gene Kim (2018): Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations, IT Revolution Press

[5] DORA Quickcheck, https://www.devops-research.com/quickcheck.html

[6] DORA Capability catalog, https://www.devops-research.com/research.html#capabilities