Bessere Anwendungen entwickeln Software-Qualität sicherstellen und messen

Autor / Redakteur: Christian Rentrop / Stephan Augsten |

Die gute Qualität seiner Software sollte jedem Entwickler am Herzen liegen. Doch was ist eigentlich „Qualität“? Der etwas schwammige Begriff lässt sich konkretisieren, bei Bedarf kann man die Qualität sogar messen.

Anbieter zum Thema

Hundertprozentige Software-Qualität ist nur mit hohem Aufwand zu errichen, aber man kann sich langsam annähern.
Hundertprozentige Software-Qualität ist nur mit hohem Aufwand zu errichen, aber man kann sich langsam annähern.
(Bild gemeinfrei: Tumisu - Pixabay.com / Pixabay )

Qualität ist einer dieser Begriffe, die alles und nichts bedeuten können. Objektive Kriterien zu finden, ist schwer: Was für schludrige Entwickler möglicherweise als qualitativ hochwertig gilt, ist für pedantische Kunden möglicherweise ein hingepfuschtes Produkt minderer Qualität.

Als Regel gilt: Softwarequalität ist der Grad, in dem das System die gestellten Anforderungen und die Bedürfnisse und Erwartungen der Nutzer erfüllt. Das schließt Quellcode ebenso ein wie die GUI, sofern vorhanden.

Das Problem an der Qualität von Software – und wohl jeder anderen Arbeit auch – ist, dass hier das Pareto-Prinzip zum Tragen kommt: die bekannte 80-20-Regel. Sie besagt, dass 80 Prozent der Ergebnisse 20 Prozent des Aufwands benötigen, während die restlichen 20 Prozent tatsächlich 80 Prozent Aufwand bedeuten.

Das bedeutet im Grunde, dass der eigentliche Entwicklungsaufwand nicht beim Implementieren von Funktionen liegt, sondern in der anschließenden Optimierung der Qualität. Irgendwo in den aufwändigen restlichen 20 Prozent liegt dann auch das die goldene Mitte, in der Kunde und Entwickler zusammenfinden sollten. Denn 100 Prozent Qualität sind in der Praxis nur mit erheblichem Aufwand zu erzielen.

Was ist eigentlich Qualität?

Doch was ist eigentlich Qualität, noch dazu in der Software-Entwicklung? Nun: Programmierer, Projektmanager und Auftraggeber dürften jetzt sofort „Bugfreiheit“ rufen, doch das ist nur ein Teil dessen, was Softwarequalität ausmacht.

Software-Qualität lässt sich vielmehr an mehreren Faktoren messen, die zum Beispiel im Industriestandard ISO/IEC 9126 genannt werden. Auch in der Norm sind sie eher Vorschläge als echte Regeln, beinhalten jedoch eine Vielzahl von Faktoren, die zur Qualitätssicherung beitragen können. Wichtige Faktoren sind unter anderem:

  • Usability: Wie leicht fällt die Benutzung?
  • Funktionalität: Sind alle gewünschten und nötigen (!) Funktionen an Bord?
  • Fehlerfreiheit: Gibt es technische Fehler, Darstellungsprobleme oder andere Bugs?
  • Effizienz: Wie sind die Anforderungen an Hardware, Software, Mitarbeiterschulungen etc.?
  • Zuverlässigkeit: Wie stabil läuft die Anwendung, auch unter Last und auf verschiedenen Konfigurationen?
  • Wartbarkeit: Können Updates und Bugfixes ohne erheblichen Aufwand eingepflegt werden?
  • Adaptierbarkeit: Kann die Software nach den Wünschen des Kunden angepasst werden? Gibt es APIs oder andere Schnittstellen?
  • Konvertier- und Migrierbarkeit: Wie gut lässt sich die Software an andere Hard- und Softwareumgebungen anpassen?

Qualitätskriterien sind nicht immer kompatibel

Diese sind in der Norm noch einmal nach Untermerkmalen aufgeschlüsselt, die den Qualitätsanspruch konkretisieren. Dummerweise neigen die Qualitätskriterien nämlich in der Praxis neigen dazu, sich zu widersprechen, wenn der Aufwand nicht explodieren soll. So ist zum Beispiel eine Java-Anwendung hervorragend migrierbar, durch den Java-Unterbau aber im Zweifel nicht so zuverlässig und effizient wie eine native Software.

Bei einer Industrieanwendung muss hingegen die Zuverlässigkeit und Adaptierbarkeit im Vordergrund stehen, die gegebenenfalls auf Kosten der Usability oder Effizienz geht. Und bei einer schnell zu entwickelnden Mobile-App sollte primär die Usability und Effizienz im Fokus stehen, während Faktoren wie Adaptierbarkeit oder Fehlerfreiheit zunächst vielleicht in den Hintergrund rücken.

So oder so muss der Entwickler für seine eigene Effizienz abschätzen, welche Faktoren am wichtigsten sind, wo eventuell später Nachbesserung nötig ist und welche Möglichkeiten er im Rahmen des Pareto-Prinzips ausschöpfen kann und will. Denn Fakt ist leider: 100 Prozent Qualität sind in der Praxis kaum zu erzielen, das Erreichen eines Näherungswerts ist mit exponentiell steigendem Aufwand und entsprechenden Kosten verbunden.

Qualität in der Software-Entwicklung in der Praxis

Wichtig ist daher, dass Entwickler bereits in der Planungsphase Qualitätsziele der Entwicklung festgelegt, um eine Kosten-Nutzen-Rechnung anstellen zu können. Dabei muss auch berücksichtigt werden, dass ein vorab zu hoch kalkuliertes Qualitätsniveau die Kosten unnötig in die Höhe treiben kann, während ein zu niedriges Niveau im Zweifel Nachbesserungen nach sich zieht. Das treibt ebenfalls die Kosten in die Höhe.

Gleichzeitig kann ein falsch angesetztes Qualitätsniveau auch die Softwareentwicklung unnötig verzögern; eventuelle Vertragsstrafen oder sogar der Auftragsverlust können die Folge sein. Je nach Größe des Kunden kann das für Softwareentwickler – egal ob einfacher Freelancer oder Softwareunternehmen – fatale Folgen haben.

Daraus folgt in der Praxis die oftmals bizarre Situation, dass Fehler passieren – und sie passieren müssen, um den Kunden zufrieden stellen zu können. Denn zu 100 Prozent fehlerfreie Software, die noch dazu alle Qualitätskriterien erfüllt, ist bestenfalls in der Theorie machbar. Bei der Definition dieser Kosten-Nutzen-Rechnung können das Lastenheft und das Pflichtenheft helfen.

Qualitätsfaktoren haben Einfluss auf Folgeaufträge

Das bedeutet allerdings nicht, dass geschludert werden soll. Denn ein möglichst hohes Qualitätsniveau der Software wirkt sich letztlich auch auf die Kundenzufriedenheit und damit auf mögliche Folgeaufträge aus. Der Kunde investiert im Zweifel viel Zeit und Geld in die Softwareentwicklung – und möchte am Ende natürlich das bestmögliche Produkt erhalten.

Dementsprechend sollten Entwickler immer darauf achten, dass das Produkt augenscheinlich in Ordnung ist: Fehler, die funktionelle Störungen beinhalten sind dabei zwangsläufig eher auszumerzen als zum Beispiel banale Übersetzungs- oder Beschriftungsfehler. Letztere sind aber offensichtlicher – und könnten ein schlechtes Licht auf das Gesamtprodukt werfen. Hier müssen Entwickler achtgeben, dass solche „kleinen“ Fehler nicht aus dem Ruder laufen.

Qualität von Software messen

Doch wie lässt sich die Qualität einer Software in der Praxis messen? Testverfahren als solche gibt es nicht. Es kann jedoch helfen, die Software in der Entwicklungsphase wieder und wieder auf die oben genannten Kriterien zu testen. Als Grundlage des Testings sollten auch hier die ISO/IEC 9126 festgesetzten Kriterien dienen.

Augenfällige Bugs sollten grundsätzlich ausgemerzt werden, andere Fehler können dann im Rahmen dieser Tests nach Wichtigkeit kategorisiert werden: Funktionale Fehler erhalten eine höhere Bugfix-Priorität als solche, die für den Betrieb der Software nicht zwingend notwendig sind. Auch bei der Implementierung von Funktionen sollte solch ein hierarchisches System etabliert werden, damit nützliche, aber nicht zwingend notwendige Randfunktionen im Rahmen der Entwicklung zunächst hintenan gestellt werden können.

Grundsätzlich sollte der Kunde oder die Zielgruppe dabei im Blick behalten werden: Eine barrierefreie Software für eine Behörde stellt hier hinsichtlich Qualität andere Anforderungen als eine einfache Smartphone-App. Dennoch gilt es, auch diese regelmäßig im Hinblick auf Funktionalität und Usability zu überprüfen.

Mit der zusätzlichen Hilfe von Testpersonen – sofern dieser Aufwand samt Auswertung der Ergebnisse finanziell und logistisch vertretbar ist – können gegebenenfalls zusätzliche Qualitätsprobleme aufgedeckt werden, die Projektmanager und Entwickler möglicherweise durch eine gewisse „Betriebsblindheit“ aus den Augen verloren haben. So ist am Ende sichergestellt, dass offensichtliche Fehler im Endprodukt nicht mehr erkennbar sind – auch ohne dass ein hundertprozentiges Qualitätsniveau erreicht ist.

(ID:44700661)