Qualität, Entwicklung

Qualität in Web, App und Software ganz einfach

Michael Jaros

Kennen Sie das? Ein Druck auf den falschen Button und die App verabschiedet sich. Ein kurzer Klick und Ihre Tabellenkalkulation reagiert nicht mehr. Fehler äußern sich glücklicherweise meist nur als Ärgernisse im Alltag. Keine solchen zu haben wird oft als primäres Qualitätsmerkmal von Software wahrgenommen. In diesem Artikel erzählen wir Ihnen, warum Softwarequalität so viel mehr ist als die simple Abwesenheit von Fehlern, und wie Sie diese Qualität selbst bekommen können.

Die Basis für gute Qualität

Um Softwarequalität zu verstehen, müssen wir kurz einen Schritt zurückgehen und uns überlegen, warum wir eigentlich Software entwickeln (lassen). Ausgangspunkt jeder Neuentwicklung oder auch jeder Änderung in einem bestehenden System ist ein Bedarf. Damit meinen wir eine Aufgabenstellung aus unserem Geschäftsgeschehen, die mit den Methoden der IT lösbar ist, aber bisher unzureichend oder gar nicht unterstützt wird, und für die es auch keine passenden Lösungen zu kaufen gibt.

Das Ziel einer solchen Aufgabenstellung kann in verschiedene Anforderungen heruntergebrochen werden, die beschreiben, was ein Benutzer mit dem gewünschten System „tun können soll“. Wir sprechen hierbei von den funktionalen Anforderungen. Ein System, das seinen funktionalen Anforderungen entspricht, erfüllt grundsätzlich seinen Zweck.

Nehmen wir als Beispiel eine bestimmte Buchhaltungssoftware für KMU, die ich vor einiger Zeit ausprobiert habe: Die Anwendung kann Buchungen erfassen, korrigieren, auflisten und Berichte ausdrucken. Jedoch war ich trotzdem nicht sehr zufrieden damit:

  • Die Benutzeroberfläche sieht aus wie aus den frühen 90ern.
  • Das Programm ist nicht mit der Tastatur bedienbar.
  • Die Umsatzsteuer wird nicht immer korrekt berechnet.
  • Das „sichere“ Kennwort wird im Klartext in einer Datei im Programmverzeichnis abgelegt.

Wir sehen schon, für das Thema Qualität viel spannender als funktionale Aspekte sind die nicht-funktionalen Anforderungen oder „Qualitätsanforderungen“. Diese Art von Anforderungen beschreibt beispielsweise, wie schnell, wie sicher, wie attraktiv, wie zuverlässig, wie bedienbar oder wie erweiterbar ein System sein soll. Eine besondere Qualitätsanforderung ist es auch, wie gut die funktionalen Anforderungen eigentlich erfüllt sind. Qualität ist also eine Menge wohldefinierter und messbarer Zielgrößen.

Nicht-funktionale Anforderungen nach ISO/IEC 9126
Nicht-funktionale Anforderungen nach ISO/IEC 9126. Abbildung von Sae1962, lizenziert unter CC-BY-SA 4.0

Die funktionalen und nicht-funktionalen Anforderungen mit allen Stakeholdern und auch aus anderen Quellen systematisch zu erheben, stellt sicher, dass alle nachgelagerten Tätigkeiten bereits an den Bedürfnissen der Stakeholder ausgerichtet sind und verhindert so teure Fehlentwicklungen.

Voraussetzung für jede Qualitätssicherung

Ob man die Anforderungen in einem formalen Dokument (Software Requirements Specification, Lasten-/Pflichtenheft), evtl. nach Volere, ANSI/IEEE Std 830-1984 oder ANSI/IEEE Std 29148-2011 oder eher leichtgewichtig zB als User Stories dokumentiert, kommt auf die Rahmenbedingungen und Größe des Projekts an. Es gar nicht zu tun wäre jedenfalls ein Fehler:

Durchschnittlich 25 % der Arbeit in einem Softwareprojekt ist Anforderungsarbeit [1]. Schiebt man diese Arbeit in spätere Phasen oder führt sie nur halbherzig durch, basieren viele technische Entscheidungen auf Annahmen, die sich später als falsch herausstellen und so den Aufwand massiv erhöhen. Aber es kommt noch schlimmer: Gibt es keinen dokumentierten Soll-Zustand, gegen den das System getestet werden könnte, muss jeder Test auf weiteren, ungesicherten Annahmen basieren, was die Validität der gesamten Qualitätssicherung in Frage stellt.

Anforderungen sind, einmal erfasst, so gut wie nie in Stein gemeißelt: Je volatiler das Umfeld und je wahrscheinlicher Änderungen in den Anforderungen sind, desto wichtiger ist ein agiles Vorgehen, das auf Änderungen ausgerichtet ist.

Wozu Architekturarbeit?

Je komplexer ein System ist, desto wichtiger ist es, grundlegende technische Entscheidungen wie Auswahl von Technologien oder Definition von Schnittstellen im Sinne der nicht-funktionalen Anforderungen zu treffen. Diese Entscheidungen sind jene, deren spätere Änderung die höchsten Folgekosten nach sich zieht. Daher sollten sie in sorgfältiger Abwägung, idealerweise von oder mit einem erfahrenen Architekten getroffen und auch dokumentiert werden.

Auch der Aufbau technischer Schuld, das sind kurzfristig positive, aber langfristig negative technische Entscheidungen, kann von einem Architekten aktiv bekämpft und so die Gesamtkosten gesenkt werden. Ein verbreitetes Beispiel für technische Schuld: Eine Umsetzung wird unter dem im Projektgeschäft häufigen Termindruck technisch unsauber ausgeführt, ein späteres Refactoring in Aussicht gestellt, das dann jedoch niemals stattfindet. Die Qualität – genauer gesagt die Änderbarkeit – nimmt ab, was zu zukünftig erhöhten Änderungskosten führt.

Im Bereich der Änderungskosten ist jedoch nicht nur die Software-Architektur auf höchster Ebene, sondern auch die Qualität des Quellcodes selbst entscheidend. Konsequent angewandte Styleguides für die Programmierung beeinflussen diese und andere Qualitätsgrößen positiv.

Testen ist das A & O

Qualitätssicherung (QS) bedeutet in der Softwareentwicklung vor allem Testen derselben auf verschiedenen Ebenen, wodurch die Erfüllung funktionaler wie nicht-funktionaler Anforderungen überprüft werden und so die Qualität gemessen kann. Das Ergebnis der Qualitätssicherung ist die Dokumentation von Abweichungen zwischen den Anforderungen und dem getesteten Softwarestand.

Für die meisten Softwaretests ist es essentiell, dass die Anforderungen dokumentiert sind, denn nur so kann man den Ist- mit einem Soll-Zustand vergleichen. Eine verbreitete Einteilung unterscheidet die folgenden Teststufen:

  • Komponententest, der einzelne, abgeschlossene Bestandteile der Software testet
  • Integrationstest, der das Zusammenspiel mehrerer Komponenten überprüft
  • Systemtest, der das Verhalten des Gesamtsystems testet
  • Abnahmetests, die häufig bei Übergaben vom Auftragnehmer an den Auftraggeber stattfinden

Die Automatisierung von Softwaretests ermöglicht oft einen enormen Qualitätsgewinn, da mit nahezu gleichem Ressourceneinsatz beliebig oft getestet werden kann. Allerdings ist das Schreiben automatisierter Tests selbst je nach Teststufe recht aufwändig, weshalb eine vollständige Testautomatisierung selten erstrebenswert ist.

Balance qualitätssteigernde Maßnahmen und Kosten von Mängeln
In dieser vereinfachten Darstellung sieht es ganz leicht aus, die richtige Balance zwischen qualitätssteigernden Maßnahmen und Folgekosten von Mängeln zu finden. Da Qualität keine eindimensionale Größe ist und tatsächliche Kosten von Qualitätseinbußen oft nicht so leicht zu beziffern sind, wird man dieses Optimum in der Praxis selten erreichen.

Und was ist Qualitätsmanagement?

Haben Sie es mit Branchen, Unternehmen, oder Projekten zu tun, in denen Qualität einen sehr hohen Stellenwert hat, werden Sie die Disziplin des Qualitätsmanagements (QM) bereits kennen. QM versucht bezogen auf die Softwareentwicklung, die Prozessqualität zu verbessern. Dies basiert auf der weithin anerkannten Annahme, dass sich so auch die Produktqualität erhöht.

Zum QM gehören unter anderem die Auswahl und Dokumentation eines Vorgehensmodells, die Definition von Metriken, sowie die Kontrolle und laufende Verbesserung der Prozesse. Für QM gibt es Standards wie die Normenreihe EN ISO 9000, aber auch etwas praxisorientiertere Referenzmodelle wie Capability Maturity Model Integration (CMMI), deren Einhaltung von externen Auditoren überprüft und für die ein Unternehmen auch zertifiziert werden kann.

Qualität kostet. Aber was kostet keine Qualität?

Modernere Darstellung des magischen Dreiecks
Wählen Sie zwei – eine modernere Darstellung des magischen Dreiecks.

Das magische Dreieck (engl.: project management triangle [2]) illustriert den grundsätzlichen Zusammenhang zwischen Qualität, Zeit und Kosten: Jede Maßnahme, die Qualität zu erhöhen, bedeutet einen gewissen Aufwand, der auch die Fertigstellung verzögert, während Qualitätsmängel im Vorhinein kaum zu beziffern sind.

Wichtig ist es, Mängel möglichst früh zu entdecken: Beispielsweise kann ein Fehler in den Anforderungen durch ein Review frühzeitig leicht behoben werden. Wird das Problem erst nach der Inbetriebnahme bemerkt, kann dies dagegen enorme Folgekosten nach sich ziehen.

Kosten eines Mangels
Die Kosten eines Mangels steigen mit der Zeit, die zwischen Auftreten und Behebung vergeht. Die Grafik ist nicht maßstabsgetreu. Insbesondere phasenübergreifend und nach der Inbetriebnahme steigen die Kosten für eine Behebung oft überproportional.

Fazit

Sie setzen Software ein – brauchen Sie Softwarequalität? Selbstverständlich. Wie viel davon und welche Maßnahmen genau zu Ihrem Produkt oder Projekt passen, erheben erfahrene Software-Experten von Beginn an mit Ihren Anforderungen, damit Sie nicht an der falschen Stelle sparen.

Egal ob Sie Software selbst entwickeln oder dafür Projektpartner haben: Wenn Sie und Ihre Partner diese grundlegenden Tipps beherzigen, haben Sie schon viel gewonnen:

  • Erfassen und dokumentieren Sie nicht nur Mängel, sondern auch Anforderungen und deren Änderungen systematisch. Nur so haben Sie die Möglichkeit durchgehender Qualitätssicherung und bekommen am Ende, was Sie am Anfang wollten.
  • Machen Sie Architekturarbeit sichtbar und setzen Sie jemanden mit Erfahrung als Software-Architekten ein. So können Sie teure technische Fehlentscheidungen vermeiden und die langfristigen Kosten niedrig halten.
  • Führen Sie Qualitätssicherung auf allen Ebenen ein: Lassen Sie Anforderungen und Architekturentscheidungen reviewen und achten Sie darauf, dass die wichtigsten funktionalen und auch nicht-funktionalen Anforderungen von entsprechenden Tests abgedeckt sind.

Referenzen

[1] Hruschka (2014): Business Analysis und Requirements Engineering, ISBN 978-3-446-43807-1

[2] Atkinson (1999): Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria. International Journal of Project Management. doi:10.1016/S0263-7863(98)00069-6