Was ist Softwarequalität?

Der Begriff der Qualität ist in aller Munde. Ob es um Biogemüse vom lokalen Bauen oder um ergonomisch geformte Bürosessel geht: Qualität ist wichtig. Gleiches gilt für Softwarequalität. So haben sich auch viele Softwareunternehmen selbst einer höheren Qualität verschrieben. Qualität ist prinzipiell etwas Gutes und Erstrebenswertes. Da sind sich alle einig.

Es scheint eine imaginäre Übereinkunft zu geben, was Qualität ist. Der Kunde spricht von schlechter Qualität. Die Entwickler möchten etwas ändern, um die Qualität zu erhöhen. Der Manager führt Prozesse ein um Qualität in den Griff zu bekommen. Was genau Qualität ist, darüber schweigen sich die meisten jedoch aus.

ISO und Co

Sobald man über Softwarequalität redet, hört man gleich die Prozessverfechter ISO nummern runter beten. Dann geht es um Richtigkeit, Konformität, Fehlertoleranz, Erweiterbarkeit, Stabilität, Robustheit, … (die Liste ist lang).

Das klingt erst einmal alles sehr gut. Es ist in der Praxis aber genau so wenig fassbar, wie er Begriff Qualität selbst. Womit haben sie zuletzt Fehlertollranz gemessen? Die Richtigkeit („Anzahl der Fehler“ durch „Anzahl der Funktionen“) scheint da greifbarer. Jedoch weiß niemand wie viele Fehler eine Software wirklich hat. Im Allgemeinen gilt – „Sie hat keine“, bis man einen findet. Also schmälert die Suche nach Fehlern die Qualität etwa?

Durch die Auseinandersetzung mit den üblichen Normen bekommt man zwar einen guten Überblick, über welche Teilbereiche sich Softwarequalität erstreckt. Es sagt jedoch nichts darüber aus, was es bedeutet, wenn die Qualität gering oder hoch ist. Zurück bleibt das vage Gefühl für Qualität.

Eine grobe Annäherung

Das Qualität ihren Preis hat, ist den meisten klar. Ebenso klar ist, dass mit steigendem Umfang die Kosten steigen. Einfach ausgedrückt verhalten sich Kosten zu Qualität folgenermaßen:

Kosten = Zeitaufwand = Funktionsumfang * Qualität

Sobald man die verfügbare Zeit bei gleichem Umfang herabsenkt oder den Funktionsumfang bei gleichbleibendem Budget erhöht, wirkt sich das negativ auf die Qualität aus. Das war ja nun bereits klar. Was vielen nicht klar zu sein scheint ist die Umformung dieser einfachen groben Gleichung:

Qualität (h/f) = Zeitaufwand (h) / Funktionsumfang (f)

(Ich war so frei Einheiten hinzuzufügen: „h“ steht hier einfach für Zeit. Die Größe „f“ soll einen Funktionsumfang beschreiben. Also eine Menge an fs. Der Einfachheit halber nenne ich es mal „Funktionen“. - Man könnte auch „Features“ sagen.)

Qualität ist also ein Maß an Zeit, die man pro Funktion einsetzt.

Das ist sehr ungünstig! Denn damit steht die Qualität im kompletten Gegensatz zu Effizienz (f/h). Das erklärt vielleicht auch ein wenig, wieso so viele Unternehmen bei der Verbesserung der Softwarequalität scheitern. Effizienz hat heutzutage immer noch einen weitaus höheren Stellenwert für viele Unternehmen. – Das liegt sicherlich auch am Kaufverhalten der Kunden, die einen geringen Preis eher zu schätzen wissen, als eine höhere Qualität. Das ist vor Allem dann der Fall, wenn die Qualität vom Kunden nicht beurteilt werden kann.

Eine Analogie

Viele Analogien für Softwarequalität hinken. Man spricht von Stabilität oder Robustheit und denkt an Baumaterial das tragende Lasten aushalten soll. Man könnte fast den Eindruck bekommen, es fehle nur an Statikern für Softwarearchitekturen. Andere wiederrum sprechen von Standards und Konformität. Das mag vielleicht für materielle Produkte gelten, die sich wie ein Ei dem Anderen gleichen sollen. Software hingegen lässt sich problemlos innerhalb von Sekunden zu 100% identisch vervielfachen.

Aus diesem Grund möchte ich eine etwas passendere und dennoch greifbare Analogie vorstellen:

Angenommen sie haben ein Problem, für das eine Software geschrieben werden soll. Sie haben meist eine Ausgangssituation (z.B. viele Kundenanfragen, die nicht ad-hoc beantwortet werden können) und wollen eine Zielsituation erreichen (schnelle Datenabfrage für Kundenanfragen). Diese zwei Zustände sind wie zwei Ufer eines Flusses. Dazwischen tobt die reißende Strömung.

Sie lassen also eine Brücke über den Fluss bauen, welche es Ihren Mitarbeiten ermöglichen soll bei einer Anfrage schnell auf das andere Ufer gelangen zu können um ad-hoc die passende Antwort zu finden, anstatt sie mühsam auf dieser Seite des Flusses zu suchen.

(Sie werden sicher überrascht sein, wenn sie jetzt hören dass nicht um die Befestigung der Brücke am Fundament, die Materialeigenschaften oder um die Verbindungstellen zwischen den einzelnen Modulen geht. – Natürlich gibt es dazu auch hinkende Analogien in der Softwareentwicklung, aber darum soll es hier nicht gehen.)

Niemand hat das zuvor gemacht.

Da wir uns in der Welt der immateriellen Güter befinden ist eine Brücke zu bauen kein Problem. Sie schauen nach einer existierenden und kopieren sie einfach binnen Sekunden oder laden sie aus dem Internet herunter. Dumm nur, wenn bisher alle Welt Flüsse nur mit Booten überquert.

(Nur wenn etwas noch nicht existiert muss es erdacht werden.)

In so einer Situation benötigen sie ein Team von Entwicklern, die eine Brücke bauen sollen. Das bedeutet aber auch, dass diese Entwickler etwas machen, dass so noch nicht gemacht wurde. Es gibt also auch keine Entwickler, die Erfahrung im Bauen von Brücken hätten. Sie versuchen jedoch solche zu wählen, die zumindest so etwas Ähnliches gemacht haben. Sie holen sich einen Entwickler der Straßen gebaut hat (für die Oberfläche), einen der Kräne erstellt hat (für die tragenden Aufgaben) und einen der Zäune erstellt hat (für das Geländer).

Die drei setzen sich zusammen und überlegen, wie man die beiden Ufer mit einander verbinden könnte. Sie legen los.

Am Ende der Woche haben die drei Entwickler beide Ufer miteinander verbunden und zeigen ihnen das Zwischenergebnis. Sie wundern sich, ein wenig. Wenn die Ufer verbunden sind, wieso wollen die dann noch zwei weitere Wochen daran arbeiten? Als sie die Verbindung sehen wird es ihnen klar.

Anders als erwartet

Der schmale Steg zwischen diesem Ufer und dem Anderen verläuft nicht geradlinig. Vielmehr beschreibt er einen Zick-Zack-Kurs. (Der Verlauf der Brücke beschreibt die Bedienung der Software, um das gewünschte Ziel zu erreichen.) Würde man gerade aus gehen, würde man unweigerlich abstürzen. An diesen Fall haben die Brückenbauer anscheinend gedacht und an genau dem Abschnitt einen Zaun aufgestellt, so dass man zumindest daran gehindert wird in Wasser zu fallen. Stolz laufen die Entwickler von einem ans andere Ufer und zeigen, dass es jetzt möglich ist („Proof of Concept“).

Sie sind nicht zufrieden? Wieso denn eigentlich nur? Sie hatten sich sicherlich eine geradlinige Brücke vorgestellt. Ein Entwickler erklärt ihnen, wieso das nicht geht:

Zum einen wollten sie, dass die Benutzer später unterwegs entscheiden sollen, wo sie am anderen Ufer ankommen wollen. Deswegen hat die Brücke Verzweigungen. Das sollte Zeit auf dem anderen Ufer sparen. (Anforderungen und Erwartungen passten nicht zueinander.) Außerdem gab es tiefe Stellen im Fluss (Fehlende oder undokumentierte Schnittstellen), die man umgehen musste. Auch der Kran, der einen Teil der Brücke trägt, konnte nur auf einem Ufer stehen. (Der Kran-bauende Entwickler sollte sich ja auch sinnvoll einbringen und tat es, wie er es am besten konnte. Frei nach dem Motto: „Wer nur einen Hammer hat, für den sieht jedes Problem wie ein Nagel aus.“) All das waren Faktoren, die in den Verlauf der Brücke einflossen.

Tests

Sie lassen die ersten Mitarbeiter „Beta“-testen und jagen sie über die Brücke. Einer fällt nach dem anderen ins Wasser. Völlig nass beschweren sie sich über einige schlecht ausgeschilderte Stellen und unsichere Passagen: „Wenn man nicht aufpasst, fällt man kurz vor dem Ziel auf die Nase. Dann war die Arbeit bis dahin umsonst.“ Sie notieren sich alles und melden es den Entwicklern. Diese bessern aus. Überall wo ihre Mitarbeiter über den Rand der Brücke ins Wasser gefallen sind, werden Zäune aufgestellt, die sie zukünftig daran hindern. Tafeln sollen dann Hinweise geben, wieso das kein guter Weg ist.

Es gibt Stellen an denen trotzt Warnhinweisen die Mitarbeiter immer wieder lang gehen, weil sie es so gewohnt sind. Dort wird die Brücke ausgebaut. Sie wird breiter damit man neben einander passt, sie bekommt zusätzliche Wege und weitere Ebenen. So mancher Mitarbeiter äußert den Wunsch einer zusätzlichen Rampe für Fahrradfahrer oder über einen Lift auf die obere Ebene.

Was haben sie getan?

Rückblickend werden sie feststellen, dass sie auch noch ein Jahr später immer wieder mal eine kleine Veränderung an der Brück vornehmen lassen. Die Konstruktionsarbeiten haben dann doch zwei Monate statt drei Wochen gebraucht und die Brücke ist irgendwie viel größer und komplexer ausgefallen, als sie anfangs geplant war. Ihre Mitarbeiter sind dennoch froh, weil sie jetzt schnell dorthin gelangen, wohin sie müssen. Ab und an kommt einer durchnässt zu ihnen und meldet eine Lücke im Zaun, aber es werden zunehmend weniger.

Hatten sie nicht bereits nach einer Woche eine Verbindung zwischen beiden Ufern etabliert? Was haben sie die ganze Zeit gemacht? Sie haben Zeit (bzw. Geld) in die Brückenarbeiten gesteckt, ohne wesentlich mehr Funktionen zu liefern. Nach der Formel von Oben haben sie nicht nur Zeit investiert, sondern gleichzeitig damit die Qualität erhöht. – Das werden auch ihre Mitarbeiter bestätigen können.

Die Brücke ist viel breiter geworden und viele Stellen sind abgesichert worden. Die Brücke ist auf die diversen Verhaltensmuster der unterschiedlichsten Benutzer ausgerichtet worden. Anfangs waren nur die Entwickler in der Lage sie zu überqueren ohne abzustürzen. Jetzt fängt die Brücke auch Fehltritte ab, sichert den Benutzer und leitet ihn auf die andere Seite.

Fazit

Es geht bei Software nicht darum, wie oft ich sie starten kann, bevor sie zerbricht. Es geht auch nicht darum, wie viele Datensätze ich aufnehmen kann, bevor sie platzt und unwiederbringlich zerstört ist. Software nutzt sich nicht ab! Sie hat Grenzen, aber sie geht nicht kaputt.

Unsere Bedürfnisse und unser Verhalten geben vor, was eine Software alles behandeln und unterstützen soll. Je mehr und je verschiedener die Benutzer sind, umso höher sind die Qualitätsansprüche an die Software.

Qualität beschreibt demnach, wie intuitiv der Benutzer geführt wird, wie nachsichtig die Software mit Benutzern umgeht, wenn diese sich gegen die „Regel“ verhalten und wie lange der Benutzer braucht um sein Ziel zu erreichen.

Die Analogie zeigt, wieso es nicht sinnvoll ist, eine Software von den Entwicklern selbst testen zu lassen. (Sie kennen die Software zu gut, um sie falsch zu bedienen.) Es zeigt aber auch die Notwendigkeit und den Nutzen von Tests. Eine zu früh freigegebene (also wenig getestete) Software wird die Benutzer frustrieren. Dass kann sogar so weit gehen, dass sie diese ablehnen.

Je besser die Benutzer das System kennen (z.B. durch Schulungen), umso geringer kann die Qualität der Software ausfallen. Man verlagert den Ausbau der Software auf die Schulung der Benutzer. Dies ist immer ein Abwägen der Kosten. (Was einfacher zu ändern ist, wird geändert.)

Die Analogie zeigt aber auch, dass es übertrieben ist eine solche Brücke gegen Eventualitäten abzusichern oder auszubauen, wenn diese gar nicht genutzt werden. – Dies sollte klar machen, wie wichtig es ist echte (sich realistisch verhaltenden) Benutzer auf eine Software loszulassen.

Was ist mit Metriken?

Solange es keine Automaten gibt, die aus Anforderungen automatisch Software erstellen, wird es vermutlich auch keine Automaten geben, die eine Software automatisch auf Übereinstimmung mit den Anforderungen prüfen können.

Man kann sich nur mit vagen Heuristiken behelfen. Bezogen auf die Analogie kann man die Länge einer Brücke im Verhältnis zur Breite des Flusses betrachten. Ist sie „zu lang“, dann ist sie vermutlich verzweigt und verwinkelt. Ob sie aber unpassend ist, kann man nicht beurteilen. - Oder man kann schauen, wie viel Prozent der Begrenzung mit Zäunen versehen sind und dabei 100% anstreben. Aber ob die Brücke ans Ziel führt kann so man nicht sagen.

Metriken helfen nur bedingt bei der Beurteilung der Softwarequalität. Sie können unter Umständen eine Software als unpassend entlarven und so eine geringe Qualität feststellen. – Die Abwesenheit solcher Alarmsignale ist aber kein Zeugnis für hohe Qualität.