© Ekaphon maneechot/Shutterstock.com
Qualität intern und extern gewährleisten

Auf der Suche nach dem Qualitäter


Klar, jeder möchte Qualität in seiner Software. Und zwar immer und möglichst viel. Aber was genau ist eigentlich Qualität? Wie stellt man sie her? Und wer entscheidet, ob eine Software genug Qualität hat oder nicht? Dieser Artikel stellt der klassischen Vorstellung von Qualität eine alternative Sichtweise entgegen, die den Ideen der agilen Softwareentwicklung und des Lean Thinking entstammt.

Go slow to go fast! So lautet ein Motto aus dem Lean Management. Hinter diesem scheinbaren Paradoxon steckt eine fundamental wichtige Erkenntnis: Wenn wir unseren Fokus nur auf Geschwindigkeit, also effizientes Arbeiten richten (Effizienz = „die Dinge richtig tun), werden wir uns damit früher oder später (meistens früher, als wir denken) Probleme einhandeln, die unsere Geschwindigkeit massiv drosseln. Dieses Problem spiegelt sich auch in der klassischen Definition von Qualität wider, wie wir sie zum Beispiel in der Norm EN ISO 9000:2008 (der gültigen Norm zum Qualitätsmanagement) finden. Der zufolge ist Qualität der „Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt“. Wenn wir also Software in hoher Qualität bauen wollen, müssen wir laut der ISO-Norm nur dafür sorgen, dass wir die Anforderungen an das neue System richtig verstanden haben, um es dann entsprechend dieser Anforderungen zu entwickeln und zwar möglichst effizient. Dass dieser Ansatz problematisch ist, zeigen Untersuchungen über die Benutzung von Softwaresystemen. Demnach werden 60 bis 70 Prozent der Funktionen selten oder gar nicht verwendet. Ob diese Funktionen gemäß den Anforderungen korrekt implementiert wurden, ist völlig unerheblich. Dass sie überhaupt implementiert wurden, ist das eigentliche Problem. Versuchen wir es also mit einer anderen Sichtweise: Jerry Weinberg schreibt „Quality is value to some person. [1] Wie hoch die Qualität unserer Software ist, hat also zunächst einmal gar nichts mit den Anforderungen zu tun. Entscheidend ist viel mehr, ob bestimmte Personen, nennen wir sie Kunden, die Software wertvoll finden. Im besten Fall gibt es natürlich eine Übereinstimmung zwischen beiden Ansätzen: Der Wert für den Kunden wird geliefert, indem seine definierten Anforderungen in Software überführt werden. Das Problem dabei ist, dass der Kunde in der klassischen Sichtweise nur einmal kurz am Anfang und am Ende des Entwicklungsprozesses beteiligt ist. Und das führt zu einer Reihe von Schwierigkeiten:

  • Wir können am Anfang nie sicher sein, ob wir die Bedürfnisse der Kunden richtig verstanden haben. Weil wir den Kunden nach der Anforderungsdefinition aber ziemlich lange nicht zu Gesicht bekommen, können wir unsere Annahmen nicht wirklich validieren. Stattdessen setzen wir sie in Software um und hoffen, dass wir richtig lagen, was aber leider nicht immer zutrifft.

  • Was für unsere Kunden Wert schafft und was nicht, ist keine feste Größe, sondern ändert sich mit der Zeit. Nur weil ein Kunde zu einem bestimmten Zeitpunkt einen bestimmten Satz an Anforderungen für besonders wertvoll hielt, heißt das noch lange nicht, dass dies zu einem späteren Zeitpunkt noch so ist. Der Markt ändert sich, die Konkurrenz schläft nicht, neue technische Chancen ergeben sich und neue Ideen entstehen. Unter diesen Gesichtspunkten wäre es am Besten, wir könnten unseren Kunden möglichst oft die Chance geben, Einfluss auf die Weiterentwicklung des Systems zu nehmen.

  • Mit den ersten beiden Punkten hängt die Frage nach der Wichtigkeit der einzelnen Anforderungen eng zusammen. Weil ich nicht genau weiß, welche Teile der Software den größten Wert für den Kunden schaffen, versuche ich natürlich, alles mit der höchsten Priorität umzusetzen. Wenn dann der Zeitplan durcheinander gerät (also eigentlich immer), kann ich nicht vernünftig entscheiden, welche Anforderungen die wichtigsten sind.

Externe Qualität macht interne Qualität zur Herausforderung

Theoretisch wissen wir also, wie wir eine hohe Qualität unserer Software erreichen können: Wir müssen den Kunden so in unseren Entwicklungsprozess einbeziehen, dass wir regelmäßig Feedback darüber bekommen, ob unsere Annahmen zutreffen oder nicht. Und wir müssen dem Kunden die Möglichkeit geben, sich immer wieder umentscheiden zu können, wie genau das neue System aussehen soll. Dies alles betrifft die externe Qualität unserer Software, also die Qualitätsaspekte, die für einen Außenstehenden (z. B. Anwender) sichtbar und beurteilbar sind.

Iterat...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang