Quality by Design

Quality by Design (QBD) bezeichnet den Ansatz, Softwarequalität nicht durch nachgelagertes Testen zu sichern, sondern durch gezielte Gestaltung des Entwicklungsprozesses selbst. Fehler sollen gar nicht erst entstehen. Dazu analysiert man Risiken im Prozess, definiert messbare Qualitätsmerkmale und steuert den Prozess kontinuierlich anhand konkreter Metriken.

Das Wichtigste in Kürze

• Fehler gar nicht erst entstehen zu lassen ist wirtschaftlicher als sie durch Testen zu finden und zu beheben: Quality by Design zielt genau darauf ab, den Entwicklungsprozess so zu gestalten, dass Qualität eingebaut statt nachträglich geprüft wird.
• Softwarequalität und Quellcodequalität sind zwei verschiedene Dinge: Erstere beschreibt den Nutzen für den Anwender, letztere die messbare Güte des Codes, und beide brauchen eigene Metriken und Maßnahmen.
• Wer Artefakte wie User Stories nicht systematisch auf Vollständigkeit prüft, arbeitet auf einer brüchigen Grundlage: In einem konkreten Projekt waren sechzig Prozent der Tickets unvollständig, was zu Interpretationsfehlern und unnötigen Rückschleifen führte.
• Quality by Design ist kein aufzusetzendes Framework, sondern ein kultureller Wandel: Jede Person im Team trägt Verantwortung für Qualität, und diese Haltung entsteht nicht durch Vorschriften, sondern durch gemeinsames Verstehen, was auf dem Spiel steht.
• Wer Metriken einführt, sollte mit wenigen, gezielten Messpunkten an neuralgischen Stellen beginnen und diese konsequent monitoren, statt von Anfang an ein umfassendes Kennzahlensystem aufzubauen.

Quality by Design verlagert Qualität nach vorne

Quality by Design heißt, den Entwicklungsprozess so zu bauen, dass Fehler gar nicht erst entstehen, statt sie hinterher zu suchen und zu entfernen. Der Ansatz stammt aus der Pharmaindustrie und lässt sich auf die Softwareentwicklung übertragen.

Viele Firmen setzen Qualität mit Testen gleich. Testen ist wichtig, aber es greift erst, wenn der Fehler schon im Produkt steckt. Alessandro Sebaste beschreibt das Grundproblem nüchtern: Man produziert Fehler, um sie danach zu suchen und wieder zu entfernen. Schlauer wäre, sie gar nicht erst zu produzieren.

Genau hier setzt Quality by Design an. Der Fokus wandert vom Endprodukt-Test zum Prozess, der das Produkt hervorbringt. In der Pharma ist das der Herstellprozess, in der Software der Softwareentwicklungsprozess.

Wie funktioniert Quality by Design in der Pharmaindustrie?

In der Pharma beginnt alles mit einem Quality Target Product Profile, kurz QTPP. Das sind die Useranforderungen an ein Medikament: Es muss sicher sein, es muss wirken, man muss es sich leisten können, und Nachhaltigkeit kommt heute hinzu.

Aus diesem Zielprofil leitet man die kritischen Qualitätsmerkmale ab, die sich im Herstellprozess messen lassen. Parallel fragt man durchgehend, was im Prozess schiefgehen kann, sodass diese Qualität nicht erreicht wird. Dafür dient eine Risikoanalyse.

Danach wird der Prozess so entwickelt, dass er kontinuierlich vermessen und kontrolliert wird. Thomas Gsponer fasst das Ziel zusammen: Fehler werden nicht ins Produkt eingebaut, und das Endprodukt-Testing reduziert sich.

Der Ansatz ruht auf zwei Säulen. Erstens Risikoanalysen, zweitens stetige Verbesserung, im Original Continued Improvement. Beide gelten für Software genauso wie für ein Medikament.

Softwarequalität und Quellcodequalität sind nicht dasselbe

Wer Qualität steuern will, muss zwischen Softwarequalität und Quellcodequalität trennen. Beide haben eine andere Ausrichtung und brauchen andere Maßnahmen.

Softwarequalität zeigt sich in Merkmalen, die der Nutzer erlebt. Eine Software soll stabil laufen, performant sein und bedienbar sein. Auch der Stromverbrauch einer Applikation wird zunehmend zu einer Kundenanforderung. Die Leitfrage lautet: Was braucht der Kunde, und was braucht der Kunde des Kunden?

Quellcodequalität ist die Ebene darunter. Hier geht es um die Bausteine, aus denen die Lösung entsteht.

Daraus folgt eine differenzierte Haltung zur Agilität. Wie eine Applikation gebaut wird, soll offen bleiben. Bei den Komponenten, die du verwendest, sind weniger Kompromisse sinnvoll. Beim Schreiben von Code gelten bis zu einem bestimmten Punkt feste Regeln, ab diesem Punkt darf das Team flexibel sein.

Metriken nur dann, wenn sie zu Entscheidungen führen

Eine Metrik hat nur Wert, wenn jemand aus ihr eine Veränderung ableitet. Viele Teams lassen ein Tool Zahlen ausspucken und nutzen sie nie, um zu verstehen, wo es schiefläuft und was sich verbessern ließe.

Quality by Design dreht das Verhältnis um. Man verändert nicht aus dem Bauch heraus, sondern auf Basis von Werten. Messen, verstehen und gezielt eingreifen gehören zusammen.

Ein konkretes Beispiel ist die Datenqualität von Artefakten. In einem Projekt mit SAFe als Framework wurde gemessen, ob Stories vollständig waren: Wurde eine Fachanwendung ausgewählt, sind Akzeptanzkriterien vorhanden, sind die Felder richtig ausgefüllt. Das Ergebnis: 60 Prozent der Tickets waren unvollständig.

Sichtbar gemachte Lücken verändern Verhalten. Sobald das Team die Zahl sah, stieg die Qualität der Tickets, und einfache Fehler sowie Rückläufer nahmen ab. Ein guter Indikator ist auch, ob die Zahlen mit dem Bauchgefühl übereinstimmen. Sagen die Daten Katastrophe, während sich alles gut anfühlt, stimmt etwas nicht.

Warum Quality by Design kein Framework wie Scrum ist

Quality by Design schreibt keine festen Abläufe vor. Es ist kein Framework, das Vorschriften macht, sondern ein Vorgehen, das mit dem Team gemeinsam die eigenen Schwachstellen findet.

Der Kern ist die Risikoanalyse auf der Ebene des Teams. Du schaust, wo es schiefgehen kann, etwa weil eine Technologie neu und unbekannt ist, und definierst genau dort eine Maßnahme. Test-Driven Development kann ein passender Ansatz sein, muss es aber nicht. Die Maßnahme muss ins Team passen.

Die Teamgröße bestimmt das nötige Maß an Regeln. Ein kleines Team aus zwei oder drei Senior-Leuten braucht weniger Vorschriften als eine Struktur aus mehreren Teams mit Juniors, die das Business noch nicht kennen.

Der Erfolgsfaktor ist, nichts blind überzustülpen. Maßnahmen, die das Team selbst umsetzen will und kann, halten. Aufgesetzte Regeln nicht.

Qualität ist eine Haltung, nicht ein erfülltes Häkchen

Compliance ist nicht gleich Qualität. Spezifikationen und Regulatorien zu erfüllen, heißt noch nicht, gute Qualität zu liefern. Dieser Trugschluss existiert in der Pharma wie in der Software.

Qualität beginnt mit der Frage, wer dafür verantwortlich ist. Die Antwort: jeder einzelne Mensch. In der Pharma macht eine Frage das greifbar, die man Mitarbeitenden stellt.

Würdest du dieses Medikament einem Kind spritzen? Das ist Qualität.

Thomas Gsponer

Übertragen auf andere Produkte: Würdest du in das Flugzeug einsteigen, dessen Steuerung du programmiert hast? Diese innere Einstellung trägt nur, wenn die ganze Firma die gleiche Qualitätskultur teilt.

Ist die Kultur vorhanden, nehmen Menschen Aufwand auf sich, um dorthin zu kommen. Sie bringen von sich aus Verbesserungsvorschläge. Dann wird Quality by Design zum Selbstläufer. Dieser Punkt ist nicht leicht zu erreichen.

Wie du mit Quality by Design startest, ohne dich zu verzetteln

Fang klein an und baue nicht von Beginn an ein großes QBD-Konstrukt. Das würde nicht funktionieren. Der Einstieg ist das Zielprofil mit den Useranforderungen.

Von dort aus ergibt sich schnell eine Liste von Einflussgrößen, bei denen Entwickler sagen, dass etwas schiefgehen könnte. Daraus fragst du, was das für Entwickler, End-User, Produkt und Firma bedeutet. So kommst du auf wenige Kennzahlen, mit denen du beginnst.

Bei den Messpunkten gilt: so wenige wie möglich, nur an den wirklich neuralgischen Stellen. Lieber vier Kennzahlen, die du verstehst, als viele, die niemand auswertet.

Sobald Daten entstehen, zeigen sich Schwankungen. Der nächste Schritt ist, diese Variabilität zu verstehen und ihre Einflussgrößen zu finden. Mit diesem Verbesserungs-Mindset entstehen mit der Zeit ausgefeiltere Metriken von selbst.

Eine Transformation braucht Zeit. Bis erste Effekte wirken, vergehen ein bis zwei Jahre, weil es ein kultureller Wandel ist. Du beginnst überall gleichzeitig, aber in kleinen Schritten.

Komplexität rausnehmen ist oft der schnellste Gewinn

Quick Wins liegen häufig dort, wo Prozesse über die Jahre Werkzeuge angehäuft haben. Funktioniert etwas nicht, baut man eine weitere Software darauf, und am Ende schiebt man Daten zwischen Tools hin und her.

Ein Beispiel aus einem Projekt mit mehreren hundert Beteiligten: Stories wurden über mehrere Sprints in Jira gesammelt, dann nach Excel exportiert, dort sortiert und über einen SharePoint abgenommen. Dazu kamen technische Probleme.

Die Lösung war, die Abnahme direkt in Jira zu machen, ohne Export. Dafür wurden Workflow und Berechtigungen angepasst. Der Abnahmeprozess lief schneller, die Übersicht war sofort da, und Projektleiter sahen direkt im Board, was lief und was nicht.

Die Einführung brachte zunächst Reibung mit sich, weil eingespielte Abläufe sich ändern mussten. Danach war das Feedback gut, und die gesparte Zeit floss an anderer Stelle wieder ein. Wer mitten in der Arbeit steckt und liefern muss, sieht solche Vereinfachungen oft selbst nicht.

Erst denken, dann entwickeln

Continuous Integration und Continuous Deployment machen es leicht, ohne Nachdenken zu deployen. Es wird laufend ausgeliefert, und weil genug Rechenpower da ist, muss sich niemand groß überlegen, was rauskommt. Geht etwas schief, wird hinterher ein Bug gefixt.

KI-gestützte Werkzeuge verstärken diese Verlockung. Code lässt sich schnell generieren, die Pipeline schickt ihn durch die Welt, automatisierte Tests laufen mit. Oft weiß niemand mehr genau, ob diese Tests überhaupt noch Fehler finden würden.

Der größte Hebel liegt deshalb davor: zuerst denken, dann entwickeln. Über die Useranforderungen prüfen, ob es das Feature wirklich braucht, und es so bauen, dass es beim ersten Mal richtig herauskommt.

Dazu kommt der Ressourcenaspekt. Blind neue Software zu entwickeln oder zu automatisieren verbraucht Ressourcen, die es eigentlich nicht braucht. Den Prozess regelmäßig zu hinterfragen, was gebraucht wird und was nicht, ist Teil von Quality by Design.