© 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 ver...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang