Agile Methoden in der Softwareentwicklung mit kurzen Entwicklungszyklen erlauben, rasch auf unerwünschtes Verhalten einer Software zu reagieren. Diese reaktive Form der Qualitätssicherung benötigt viel Infrastruktur und bindet Ressourcen, die effektiver eingesetzt werden könnten. Quality by Design (QbD) ist ein bewährter Ansatz aus der pharmazeutischen Industrie, um die Qualität eines Produkts bereits durch dessen Herstellprozess sicherzustellen.
Dieser Artikel beschreibt das Konzept QbD und gibt einen Denkanstoß, wie es in der agilen Softwareentwicklung mehr leisten könnte als Konzepte wie Built-in-Quality oder Embedded Testing. Denkanstoß deshalb, weil es nicht darum geht, ein neues, zusätzliches Regelwerk oder neue Methoden einzuführen, sondern das kollektive Bewusstsein von Softwarequalität zu fördern.
QbD zeigt einen systematischen Weg, wie dieses Bewusstsein in einem Unternehmen eingeführt werden kann, ohne dabei die Freiheit und Kreativität beim Design einer Software einzuschränken.
Quality by Design (QbD)
QbD hat seinen Ursprung in der Arbeit von Joseph M. Juran [Jur92]. Er geht davon aus, dass alle Probleme aufgrund unzureichender Prozessgestaltung in das Produkt eingebaut werden. Deshalb ist es naheliegend, dass die Probleme größtenteils verhindert werden können, wenn man diese bereits in der Gestaltungsphase des Prozesses berücksichtigt. QbD ist heute in der herstellenden Industrie sehr verbreitet und wird beispielsweise in der pharmazeutischen Industrie mittels Richtlinien geregelt. Die Richtlinie des International Council for Harmonization, ICH Q8 (R2) [ICH], definiert QbD als:
"Systematischer Ansatz zur Produkt- und Prozessentwicklung, der mit vordefinierten Zielen beginnt, den Schwerpunkt auf Produkt- und Prozessverständnis und Prozesskontrolle betont und auf solider Wissenschaft und Qualitäts-Risikomanagement beruht."
Voraussetzung für QbD sind die drei Pfeiler von Statistical Thinking [HoSn20], nämlich das kollektive Bewusstsein, dass
- alles in Prozessen abläuft, wobei ein Prozess eine Aktivität bezeichnet, die eine Eingabe in eine Ausgabe umwandelt;
- jeder Prozess variabel ist, da nie alle Störfaktoren bekannt sind und somit die Ausgabe nicht immer die gleiche ist;
- Prozessverständnis und Reduktion der Prozessvariabilität, Schlüsselfaktoren für eine hohe Qualität sind.
Mit QbD wird ein fähiger Herstellungsprozess mit eingebauter Qualität entwickelt, der wiederum ein Produkt mit eingebauter Qualität liefert. Durch stete Überwachung und Kontrolle des Herstellungsprozesses wird die Qualität des Produkts sichergestellt. Im Idealfall (der selten erreicht wird) würde dann das Produkt gar nicht mehr auf Qualität getestet.
Für die Softwareentwicklung bedeutet dies die Reduktion der Qualitätskontrollen, weil die Softwarequalität, dank eines fähigen Softwareentwicklungsprozesses (SEP) mit eingebauter Qualität, bereits in der Software eingebaut ist (siehe Abbildung 1).
Abb. 1: Von Quality by Testing zu Quality by Design
Schwerpunkte von QbD
Die Schwerpunkte von QbD in der pharmazeutischen Industrie sind in Snee [Sne13] beschrieben oder ausführlicher in ICH Q8 (R2). Davon haben wir ein paar relevante Schwerpunkte ausgewählt und in den Kontext der Softwareentwicklung gestellt, siehe Tabelle 1.
Tabelle 1: Relevante Schwerpunkte von QbD
Im Folgenden werden wir anhand eines Beispiels die wichtigsten Punkte erläutern.
Qualitätsprofil
Gute Qualität eines Produkts bedeutet, dass es für den Gebrauch geeignet ist, das heißt, es erfüllt die Anforderungen und Erwartungen der Kunden. Qualität ist daher sehr individuell definiert und deckt alle Aspekte, die für den Kunden und wiederum deren Kundes relevant sind, ab.
In der Softwareentwicklung sprechen wir hier auch, aber nicht nur von bereits bekannten Anforderungen wie Sicherheit, Wartbarkeit oder Benutzbarkeit. Nachhaltigkeit ist eines dieser Qualitätsmerkmale, welche an Bedeutung gewinnen, und kann definitiv nur durch ein gemeinsames Verständnis vieler verschiedener Faktoren erreicht werden.
Messbare Qualitätsmerkmale und Spezifikation
Die Kundenanforderungen müssen in Kritische Qualitätsmerkmale (KQM) übersetzt werden, damit wir messen können, in welchem Grad das Qualitätsprofil erfüllt ist, um so den indirekten Nachweis zu erbringen, dass wir einen fähigen SEP haben.
Möchten wir beispielsweise die Kundenanforderung "Wartbarkeit" messen, könnte die Bearbeitungszeit von Fehlerwirkungen als KQM definiert werden. Akzeptiert der Kunde eine Bearbeitungszeit zwischen 2 und 5 Tagen, legen wir dies als Spezifikation fest. Über diese Messung lässt sich die Kundenanforderung Wartbarkeit nachweisen.
Entwicklungsprozess instrumentalisieren
Als Nächstes wollen wir herausfinden, was im SEP schiefgehen kann, sodass die Qualitätsanforderungen nicht mehr erfüllt sind. Eine Risikoanalyse für den SEP ist hierfür das ideale Werkzeug. Eine FMEA (Failure Mode and Effect Analysis) listet potenzielle Fehler und deren Ursachen auf. Die Eintrittswahrscheinlichkeiten und Auswirkungen auf die Qualitätsanforderungen werden dann bewertet. Dies erlaubt, Standards und präventive Maßnahmen für Elemente im SEP zu definieren.
In einem aktuellen Großprojekt haben wir eine solche Analyse durchgeführt. Die Bearbeitungszeit von Fehlerwirkungen war eine der Herausforderungen, schlimmer aber war, dass die Korrektur oft zu weiteren Fehlerwirkungen führte und so die Bearbeitungszeit noch mehr in die Länge zog. Unsere Untersuchung hat unter anderem ergeben, dass das eingesetzte Tool für die statische Quellcodeanalyse, SonarCube, ungenügend konfiguriert ist. Die bisherige Strategie bestand darin, die bereits durchgeführten umfangreichen Regressionstests einfach nochmals durchzuführen. Eine kostspielige Angelegenheit.
Deutlich effektiver und effizienter wäre es, Codierungsrichtlinien mittels SonarCube unterstützend und verbindlich einzuführen. Codierungsrichtlinien als Kritische Prozessparameter (KPP) haben eine direkte Auswirkung auf die Bearbeitungszeit von Fehlerwirkungen und somit auf die Wartbarkeit als Qualitätsanforderung (siehe Abbildung 2).
Abb. 2: Qualitätsmerkmale
Im Unterschied zu der Messung der KQM konzentriert sich die Messung der KPP darauf, den SEP zu kontrollieren und zu überwachen. Dies liefert wichtige Informationen, um später den SEP kontinuierlich verbessern zu können. In unserem Fall hilft uns SonarCube, die Einhaltung der vom Team definierten Regeln zu überwachen. Halten wir die Regeln ein, sollte sich auch die Bearbeitungszeit von Fehlerwirkungen senken, was wir dann an anderer Stelle messen.
Testkonzept für die SEP-Qualität
Mit dem Testkonzept befinden wir uns im bekannten Umfeld von Testmanagement und Testen. Mit einem wesentlichen Unterschied: Wir testen nicht, um das Risiko einer nicht korrekt funktionierenden Software zu senken. Wir testen, um zu messen, ob die beschlossenen präventiven Maßnahmen und Standards eingehalten wurden.
Dabei wenden wir die uns bereits bekannten Methoden und Vorgehensweisen für Softwaretesting an. Wir nutzen White- und Blackbox-Testmethoden, führen statische und dynamische Tests durch und wenden unser Wissen in Test-Management, Test-Engineering, Analyse usw. an.
Lebenszyklusmanagement
Mit der Auswertung der KMQ können wir feststellen, ob unser Qualitätsprofil erreicht wurde.
Nehmen wir zwei Extremfälle, um das Zusammenspiel zwischen QbD und Softwaretesten zu erklären: Sind sämtliche präventiven Maßnahmen und Standards durch unsere Qualitätssicherung nachweislich eingehalten worden, dann ist die Ursache für eine mangelnde Qualität in lückenhaften, falschen Maßnahmen oder verpassten Risiken zu finden. Dazu sollten wir die Risikoanalyse erneut durchführen und korrektive Maßnahmen einleiten. Diese werden dann wieder in den SEP implementiert und durch angepasste Tests nachgewiesen.
Stellen wir aber fest, dass die implementierten präventiven Maßnahmen und Standards schlecht eingehalten wurden, sollten wir zuerst korrigierend eingreifen, um die Umsetzung ebendieser zu ermöglichen. Eine Schulung könnte hier Abhilfe schaffen, die Überarbeitung von Werkzeug-Konfigurationen, die Nutzung der Lean Toolbox [Geo10] wie die "5 Warums" oder ganz einfach das Gespräch mit den Teams, um die Ursache zu eruieren.
Fazit
Durch die proaktive Zusammenarbeit von Kunden, Entwicklern, Qualitätsmanagement, Qualitätssicherung und Qualitätskontrolle bei der Definition des Qualitätsprofils, der messbaren Qualitätsmerkmale, der Risikoanalyse und der Implementierung der präventiven Maßnahmen werden alle Beteiligten zu gleichen Teilen in das Thema Softwarequalität mit einbezogen.
Die kausale Kette zwischen präventiven Maßnahmen und Qualitätsprofil wird durch QbD sichtbar. Das wiederum unterstützt das gemeinsame Verständnis für Softwarequalität und die damit einhergehenden Maßnahmen. Mit QbD beantworten wir nicht nur, was wir testen, sondern vor allem, warum wir testen. Entlang der gesamten Softwareentwicklungskette wird so das Bewusstsein für Qualität geschärft und damit die Grundlage gelegt, um Software agil zu entwickeln.
Nicht nur die Softwarequalität wird dadurch steuerbar, sondern auch die SEP-Qualität. In Anlehnung an die Demingsche Kettenreaktion führt bessere SEP-Qualität zu einer Kostensenkung durch weniger Nacharbeit, weniger Fehler, weniger Verzögerungen, weniger Probleme und bessere Ressourcennutzung. Dadurch steigt die Produktivität und der Markt kann mit qualitativ besserer Software und niedrigeren Preisen erobert werden. Somit bleiben Sie als Softwareunternehmen im Geschäft und schaffen neue Arbeitsplätze.
QbD bedeutet also weniger eine technische Änderung, sondern viel eher einen organisatorischen Wandel, welchen jedes Unternehmen individuell umsetzen muss. Die Softwarequalität wird Teil der Unternehmenskultur und somit Teil einer nachhaltigen Unternehmensführung.
Nachhaltigkeit par excellence!
Weitere Informationen
[Geo10] M. O. George, The Lean Six Sigma Guide to Doing More With Less. Cut Costs, Reduce Waste, and Lower Your Overhead, Wiley, 2010
[HoSn20] R. W. Hoerl, R. D. Snee, Statistical Thinking: Improving Business Performance, Wiley, 3. Aufl., 2020
[ICH] International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use (ICH), siehe:
www.ich.org/page/quality-guidelines
[Jur92] M. J. Juran, Juran on Quality by Design. The New Steps for Planning Quality into Goods and Services, The Free Press, 1992
[Sne13] R. D. Snee, Building Blocks of Quality by Design, IVT Quality by Design Network, 2013, siehe: www.researchgate.net/publication/283089954_Building_Blocks_of_Quality_by_Design
