Kosten- und Termingrenzen einzuhalten,Eng mit den Kosten (siehe Kap. 4) verknüpft ist die Qualität. Seit es Software Engineering gibt, gehört die Verbesserung der Qualität zu seinen wichtigsten Zielen. In diesem Kapitel wird der Begriff der Software-Qualität erläutert und gegliedert.
Das Wort »Qualität« ist lateinischen Ursprungs (qualitas, -atis, f. die Beschaffenheit, Eigenschaft). Jeder Gegenstand hat Eigenschaften, hat also in diesem ursprünglichen Sinne eine Qualität oder ein Bündel von Qualitäten. Diese Aussage impliziert keine Wertung.
Das hat sich – wie bei vielen anderen Wörtern auch – im Laufe der Zeit geändert: »Qualität« wurde gleichbedeutend mit »guter Qualität«. In diesem Sinne steckt es auch im Begriff der Qualitätssicherung, nicht aber in der Qualität, wie sie DIN 55350 definiert:
Qualität — Gesamtheit von Eigenschaften und Merkmalen eines Produktes oder einer Tätigkeit, die sich auf die Eignung zur Erfüllung gegebener Erfordernisse beziehen.
Anmerkung 2: Ein Produkt ist z. B. jede Art von Waren, Rohstoffen, aber auch der Inhalt von Konzepten und Entwürfen. Eine Tätigkeit ist z. B. jede Art von Dienstleistung, aber auch ein maschineller Arbeitsablauf wie ein Verfahren oder ein Prozess.
Anmerkung 4: Die Qualität wird durch die Planungsqualitäten und Ausführungsqualitäten in allen Phasen des Qualitätskreises bestimmt.
DIN 55350-11:1995-08 (Auszüge)
Software-Qualität enthält darum nicht nur Qualitätsaspekte im landläufigen Sinne, sondern auch, und zwar im Kern, die Funktionalität. Eine Software hat alle geforderten Qualitätsmerkmale, wenn sie korrekt ist, also die geforderte Funktionalität bietet, und darüber hinaus alle anderen geforderten Eigenschaften besitzt (z. B. die geforderte Wartbarkeit, die notwendige Effizienz und auch die Verfügbarkeit zum geforderten Termin).
Das Software Engineering befasst sich sowohl mit der Qualität des Produkts (Produktqualität) als auch mit der Qualität des Projekts, in dem das Produkt hergestellt wird (Projektqualität). Der Begriff der Projektqualität ist nicht gebräuchlich; stattdessen spricht man ungenau von der Prozessqualität. Definiert man aber den Prozess als gemeinsames Schema, das beliebig vielen Projekten zu Grunde liegt, wie es in Zusammenhang mit der Prozessbewertung und -verbesserung üblich ist, so sind Projektqualität und Prozessqualität zwar eng verbunden, aber nicht gleichbedeutend. Durch hohe Prozessqualität soll eine hohe Projektqualität gefördert, wenn nicht erzwungen werden. Die beiden Begriffe verhalten sich zueinander wie die Qualität einer Theatertruppe zur Qualität einer Aufführung: Jeder weiß, dass auch an einem Spitzentheater eine Aufführung misslingen kann, so wie einer zweitklassigen Bühne dann und wann eine sehr gute Aufführung gelingt. Hohe Prozessqualität ist also weder eine Garantie noch eine zwingende Voraussetzung für hohe Projektqualität, aber sie schafft günstige Voraussetzungen dafür.
Die Prozessqualität sagt aus, wie weit es dem Hersteller der Software gelingt,
Kosten- und Termingrenzen einzuhalten,
seinen Aufwand zu minimieren,
Kenntnisse zu sammeln,
wiederverwendbare Komponenten zu schaffen,
das Betriebsklima zu pflegen.
Die Produktqualität lässt sich weiter differenzieren in Gebrauchs- und Wartungsqualität, also in die Qualität aus Sicht eines Benutzers, der mit der Software arbeitet, und in die Qualität aus Sicht einer Person, die an der Software arbeitet, sie also korrigiert, ändert oder erweitert.
Schließlich hat jede der genannten Qualitäten viele verschiedene Facetten; beispielsweise stecken Antwortzeiten, Bedienungsfreundlichkeit und Robustheit in der Gebrauchsqualität, Portabilität und Lesbarkeit in der Wartungsqualität.
Während der Entwicklung steht die Projektqualität im Vordergrund. Der Kunde ist letztlich nur an der Gebrauchsqualität interessiert (Abb. 5–1), es sei denn, er will die Wartung selbst übernehmen; dann ist er auch von der Wartungsqualität betroffen.
Tatsächlich ist die Sache aber nicht so einfach. Auch dann, wenn der Kunde mit der Wartung gar nichts zu tun hat (wie z. B. bei einem massenhaft verkauften Software-Produkt, also einer »Shrinkware«), kann ihm die Wartbarkeit nicht gleichgültig sein, denn sie ist die Voraussetzung dafür, dass von Version zu Version Fehler behoben und Verbesserungen wirklich durchgeführt werden. Gute Wartungsqualität macht das Produkt langfristig besser.
Abb. 5–1 Bedeutung verschiedener Qualitätsaspekte über der Zeit (Pfeile repräsentieren Einflüsse; nach der Stilllegung ist nur noch die Ersetzbarkeit wichtig.)
Die Prozessqualität hat auf den ersten Blick noch weniger als die Wartungsqualität mit der Gebrauchsqualität zu tun: Der Prozess ist das Schema für die Projekte, die Prozessqualität prägt also die Projektqualität, und diese hat Einfluss auf das Produkt. Trotzdem waren es die Kunden der Software-Hersteller, allen voran der weitaus mächtigste, das US Department of Defense, die die Prozessqualität zum Thema machten. Denn die Kunden waren (und sind bis heute) den Herstellern ausgeliefert: Wenn der Hersteller von Druckmaschinen die Software für eine neue Maschine nicht zum richtigen Zeitpunkt und in der richtigen Qualität erhält, kann er vielleicht die Zahlung verweigern, aber das schützt ihn nicht vor der Pleite, die ihm droht, weil er neue Druckmaschinen produzieren, aber nicht ausliefern kann. Darum wollen die Kunden vor der Bestellung wissen, ob der Lieferant allgemein seriös arbeitet; sie wollen also seine Prozessqualität kennen. Die Verfahren zur Bewertung der Prozessqualität sind Gegenstand des Kapitels 11.
Abbildung 5–2 zeigt – in Anlehnung an Boehm, Brown und Lipow (1976) – eine Gliederung des Qualitätsbegriffs. Der Oberbegriff »Software-bezogene Qualität« soll dabei alles einschließen, was uns im weitesten Sinne als Software-Qualität erscheint.
Einige Teilbegriffe wie Termineinhaltung und Ausfallsicherheit sind geläufig, andere wie Prozesstransparenz oder Leistungsvollständigkeit wurden für diese Taxonomie neu eingeführt. Aber für fast alle gilt, dass die Bedeutung nicht a priori klar definiert ist. Wir haben also bei der Definition einen gewissen Spielraum. Den nutzen wir so, dass wir möglichst disjunkte, also nicht überlappende Bedeutungen festlegen.
Diese sind in den Tabellen 5–1 bis 5–3 für die atomaren Qualitäten der Abbildung 5–2 angegeben.
Wesentlich am »Qualitätenbaum« ist die Botschaft, dass verschiedene, konkurrierende Qualitäten angestrebt werden, sodass in den Anforderungen möglichst genau geklärt sein muss, wo die Prioritäten liegen. Bei der praktischen Arbeit kann der Qualitätenbaum als Checkliste für die Spezifikation verwendet werden, um sicherzustellen, dass an alle Qualitätsaspekte gedacht wurde.
ist hoch, wenn der Entwicklungsaufwand gering ist. |
|
Entwicklungsgeschwindigkeit: |
ist hoch, wenn das Resultat nach kurzer Zeit zur Verfügung steht. |
Termineinhaltung |
ist umso höher, je genauer der geplante Termin eingehalten wird. |
Aufwandseinhaltung: |
ist umso höher, je genauer der geplante Aufwand eingehalten wird. |
Prozesstransparenz: |
ist hoch, wenn der Bearbeitungsprozess wohldefiniert ist und gemäß der Definition abläuft. |
Bausteingewinn: |
ist hoch, wenn viele wiederverwendbare Software-Komponenten entstehen oder verbessert werden. |
Know-how-Gewinn: |
ist hoch, wenn die beteiligten Mitarbeiter viele neue Kenntnisse und Erfahrungen mit Anwendungen, Methoden und Werkzeugen erwerben. |
Projektklima: |
ist gut, wenn die Mitarbeiter ihre Zusammenarbeit als angenehm empfinden und gern wieder ein ähnliches Projekt durchführen wollen. |
Tab. 5–1 Atomare Merkmale der Prozessqualität
Korrektheit: |
ist hoch, wenn die Spezifikation zutreffend und die übrige Software korrekt in Bezug auf die Spezifikation ist. |
Ausfallsicherheit: |
ist hoch, wenn die Software nur sehr selten die erwartete Funktion nicht erbringt. |
Genauigkeit: |
ist hoch, wenn die Resultate vom mathematisch korrekten Resultat nur wenig abweichen. |
Effizienz: |
ist hoch, wenn die Software kaum mehr Rechenzeit benötigt, als minimal erforderlich wäre. |
Sparsamkeit: |
ist hoch, wenn die Software kaum mehr Speicherplatz und andere Betriebsmittel benötigt, als minimal erforderlich wäre. |
Leistungsvollständigkeit: |
ist hoch, wenn die Software alle geforderten Leistungen tatsächlich erbringt. |
Handbuchvollständigkeit: |
ist hoch, wenn die Handbücher erschöpfend Auskunft auf alle sinnvollen Fragen des Benutzers geben. |
Konsistenz: |
ist hoch, wenn die Software sich gegen den Benutzer in ähnlichen Situationen ähnlich verhält. Das betrifft die Bedienung, Fehlermeldungen, auch Datenformate usw. |
Verständlichkeit: |
ist hoch, wenn der Benutzer rasch versteht, wie er mit der Software umgehen muss. |
Einfachheit: |
ist hoch, wenn die Software dem Benutzer konzeptionell einfach erscheint. |
Tab. 5–2 Atomare Merkmale der Produktqualität – Brauchbarkeit
ist hoch, wenn die Spezifikation die tatsächlichen Anforderungen und nur diese vollständig angibt. |
|
Lokalität der Software: |
ist hoch, wenn Fernwirkungen in der Software (Wirkungen über die Grenzen der Software-Komponenten hinweg) vermieden sind. |
Testbarkeit der Software: |
ist hoch, wenn die Programme unter definierten Bedingungen ausgeführt und die relevanten Resultate vollständig erfasst werden können. Die Ausführung ist damit reproduzierbar. |
Strukturiertheit: |
ist hoch, wenn die Software in logisch abgeschlossene Einheiten mit hohem Zusammenhalt und geringer Kopplung gegliedert ist. |
Simplizität: |
ist hoch, wenn in der Software nur wenige schwer verständliche Konstruktionen enthalten sind. |
Knappheit der Software: |
ist hoch, wenn ihr Umfang durch Vermeidung von Redundanz aller Art gering gehalten wurde. |
Lesbarkeit der Software: |
ist hoch, wenn ein (fremder) Leser in der Lage ist, mit minimalem Aufwand den Inhalt korrekt zu erfassen. |
Geräteunabhängigkeit: |
ist hoch, wenn Merkmale spezieller Geräte darin eine geringe Rolle spielen. |
Abgeschlossenheit: |
ist hoch, wenn die Software eine gut abgegrenzte Leistung erbringt und damit kaum Schnittstellen zu anderen Systemen hat. |
Tab. 5–3 Atomare Merkmale der Produktqualität – Wartbarkeit
In aller Regel werden die einzelnen Aspekte der Qualität nicht bewusst differenziert und nach Prioritäten geordnet. Stattdessen folgen die Entwickler ihren Gefühlen und Gewohnheiten. Praktisch heißt das meist: Sie bewerten die Effizienz weit höher als alle anderen Eigenschaften. Dies führt zu einer Fehlinvestition von Mühe und Arbeitszeit. Denn ein Programm, das unter dem Diktat der Performanz entwickelt wurde, ist in der Regel weder zuverlässig noch gut wartbar. In Wahrheit ist die Effizienz aber nur bei einem Bruchteil der Programme wirklich wichtig, während Zuverlässigkeit und Wartbarkeit (neben anderen Merkmalen) extrem wichtig sind. Die Entwickler arbeiten also mit den falschen Prioritäten. (Die Neigung, Programme zu »optimieren«, ist in Abschnitt 18.2.2 unter dem Stichwort »Don’t suboptimize« näher behandelt.)
Vielen Entwicklern ist auch nicht klar, wie sich ihr Verhalten auf die Qualität auswirkt. So ist ein völlig unbegründetes Vertrauen in den Programmtest weit verbreitet. Alle Erfahrungen zeigen aber, dass im Test nur ein Teil der Fehler entdeckt wird, Inspektionen (Abschnitt 13.4.5) sind deutlich wirksamer. Wirklich professionelle Entwickler wissen das, haben es verstanden und verhalten sich entsprechend.
