Wenn die Funktionsfähigkeit sich erst im praktischen Einsatz zeigt, ist schon alles zu spät (Teil 1):

Softwarequalität darf kein Zufallsprodukt sein

02.04.1982

Softwarequalität ist ein Problembereich, der gerade in der letzten Zeit zunehmend an Interesse und Beachtung in der Praxis gewonnen hat. Kosten und Zeit waren bisher die primären Zielgrößen der Softwareentwicklung; Softwarequalität war zwar nie unwichtig, sie wurde aber mehr als Zufallsprodukt oder Nebensache empfunden, die nicht geplant oder systematisch sichergestellt werden konnte. Softwarequalität ist im wesentlichen als eine von der Güte der Mitarbeiter abhängige Größe gesehen worden, die mehr oder weniger unbewußt irgendeine Qualität produzieren.

Qualität wird gemessen - vielleicht auch nur grob beurteilt - anhand von Erfahrungswerten, die im Einsatz der Softwareprodukte gewonnen werden, also zu einem Zeitpunkt, bei dem schon "alles zu spät" ist und im Grunde keine Korrekturmöglichkeiten und Einflußnahmen mehr möglich sind.

Dieser Zustand, der noch bis vor wenigen Jahren in der Praxis als selbstverständlich (oder als nicht anders denkbar) betrachtet wurde und sich bis heute noch nicht in der notwendigen Weise grundlegend verändert hat, ist nicht akzeptabel; denn wachsende Softwarekosten, zunehmender Anteil von Software am Umfang der Aufgabenerfüllung in einer Unternehmung sowie wachsende Verflechtung der Softwaresysteme bei gleichzeitig zunehmender Softwareverantwortung zwingen dazu die Qualität zu sichern, um hierdurch die Kosten im Einsatz - so die Wartungskosten -, aber auch Folgekosten (bedingt durch Fehlverhalten von Software) im Griff zu behalten.

Glückliche Minderheit

Oder wird der Aspekt der Softwarequalität in Ihrer Unternehmung/Institution bereits zufriedenstellend gelöst? Dann gehören Sie zu einer nur kleinen glücklichen Minderheit von Softwareproduzenten. Im folgenden werden die Grundlagen zusammengetragen, die der sehr globale Begriff "Qualität" impliziert; es wird ein allgemeines Raster von Maßnahmen vorgestellt, die der Qualitätssicherung und hier insbesondere dem Testen zuzuordnen sind.

Die vierteilige Artikelserie wird im einzelnen behandeln:

- Softwarequalität - Ein personelles Entwicklungsproblem

- Softwarequalität - Was ist das?

- Softwarequalität - Ein Aufwandsfaktor

- Softwarequalität - Wie erreicht man diese?

- Testen als eine analytische Maßnahme der Qualitätssicherung

- Testen von Softwareprodukten (-dokumenten und -programmen)

- Testplanung

- Testkontrolle

- Softwarequalität - Eine Planungs- und Kontrollgröße in Softwareprojekten

- Fragen zur kritischen Analyse der eigenen Vorgehensweise

Die entwickelnde Abteilung wird durch die Präsentation des Produkts im Regelfall entlastet; sie hat rechtzeitig und eventuell auch noch innerhalb des Budgets das Produkt entsprechend den vorgegebenen Anforderungen abgeliefert; der Nachweis wird durch die Präsentation erbracht, bei der - durch vorherige Tests sichergestellt - keine oder nur geringe Mängel zu Tage gebracht werden. Alle übrigen Mängel und auch das Risiko nach der Abnahme trägt die Fachabteilung.

Einschalten des Anwenders problembehaftet

Es folgt die Wartung. Anteile von gebundener Kapazität von über 50 Prozent für Pflege und Erweiterung sind durchaus üblich. Dieser Anteil ist auch ein Maß für die Qualität von Softwareprodukten.

Qualität ist daher nicht nur eine kurzfristige, sondern insbesondere eine auf lange Sicht rentable Investition. Doch Investitionen verursachen betriebswirtschaftlich gesehen nun einmal Aufwand.

Wie ist das Qualitätsbewußtsein beim Anwender? Der Anwender (die Fachabteilung) erwartet grundsätzlich ein Produkt mit optimalen Eigenschaften (keine Fehler im Betrieb leichte Handhabung, geringe Kosten im Einsatz).

Andererseits sind Anwender im allgemeinen nicht bereit oder in der Lage, ihre Qualitätsanforderungen so weit zu präzisieren, daß diese als operationale Zielgröße von der Softwareentwicklung problemadäquat zugrunde gelegt werden könnten. Also verlangt er die "absolute" Qualität, die normalerweise weder theoretisch noch vom Aufwand her realisiert werden kann und auch gar nicht unbedingt notwendig ist.

Ferner ist der Anwender oft nicht bereit und wird auch nicht dazu angehalten, sein Spezialwissen, das er zweifellos hat, der Softwareentwicklung zur Verfügung zu stellen. Dies könnte etwa geschehen in Form einer Beteiligung beim Testen von Dokumenten (Überprüfung des Pflichtenheftes oder des Grobentwurfs in einem Review) oder durch Bereitstellung von praxisgerechten Testfällen, die das Spektrum der Anforderungen weitgehend abdecken.

Die Probleme, eine Softwarequalität zu erreichen, die den Anforderungen, aber auch den Möglichkeiten eines Software-Entwicklungsprojekts entspricht, treten nicht erst bei der mangelnden Verfügbarkeit adäquater Methoden und Verfahren auf; sie sind vielmehr zunächst in der persönlichen Einstellung der Personen zu suchen, die am Entwicklungsprojekt direkt oder indirekt beteiligt sind und wesentlichen Einfluß nehmen auf dessen Verlauf. Hierzu zählen der Manager, der Anwender oder die Fachabteilung sowie der Softwareentwickler selbst.

Wie ist das Qualitätsbewußtsein beim Management? Das Management denkt primär (immer noch) in bezug auf Softwareprojekte kostenbewußt, nicht qualitätsbewußt. Hierbei zählt nahezu ausschließlich die direkt sichtbare Qualität. Qualität erschöpft sich aber eben nicht schon in der Lauffähigkeit des Softwareprodukts während der Präsentation.

Der Anwender sieht - bisher - vielfach nicht seine bedeutende Rolle bei der Durchführung von Softwareprojekten und füllt sie dementsprechend auch nur unzureichend aus. Hier für Abhilfe zu sorgen wird aber in Zukunft immer wichtiger werden. Der Anwender ist der Auftraggeber, der das Ergebnis seines Auftrages vor und nach der Freigabe für den Betrieb beherrschen muß.

Zwischen diesen beiden Positionen steht der Software-Entwickler, der einerseits unzureichend formulierte Anforderungen erhält und dennoch sein Meisterstück abliefern muß, der andererseits aber ständig unter Zeit- und Kostendruck steht. Bewertet wird er in erster Linie (und zwar während des Projekts) anhand des quantitativen, in zweiter Linie (im nachhinein während des Einsatzes des Softwareprodukts) anhand des qualitativen Outputs.

Der Softwareentwickler gleicht einem Seiltänzer, dessen einzige Chance (derzeit) darin besteht, durch Anwendung besserer Methoden und Verfahren der Konstruktion und Analyse das Seil in eine stabile(re) Lage zu bringen beziehungsweise das vorhandene dünne Seil durch ein dickeres, leistungsfähigeres zu ersetzen und, wenn auch immer noch in luftiger Höhe, sich so einen sicheren Stand zu verschaffen.

Softwarequalität umfaßt alle Eigenschaften von Produkten, die sich auf die Eignung zur Erfüllung gegebener Erfordernisse beziehen. Die Erfordernisse ergeben sich wiederum aus dem Verwendungszweck eines Softwareprodukts. Diese Definition versteht jeder, doch versteht jeder unter Qualität etwas anderes. Denn Qualität läßt sich nicht durch eine Größe, sondern nur durch eine Vielzahl von Größen ausdrücken.

Qualität setzt sich aus einer Vielzahl unterschiedlicher Qualitätsmerkmale zusammen, die inhaltlich unterschiedliche Bereiche im Eignungsspektrum des Produkts bezeichnen sowie untereinander in Beziehung stehen.

Die wesentlichen Klassen von Qualitätsmerkmalen sind:

- Anwendungsbezogene Qualitätsmerkmale

Sie wirken auf die Eignung des Softwareprodukts für die geplante Aufgabenlösung, also auf die Anwendung selbst.

- Wartungsbezogene Qualitätsmerkmale

Sie wirken auf die Eignung des Softwareprodukts für eine notwendige Änderung (Fehlerlokalisierung, Fehlerbehebung) und Erweiterung (Ausbau des Funktionsumfangs),also auf Wartungsaktivitäten.

- Übertragungsbezogene Qualitätsmerkmale

Sie wirken auf die Eignung des Softwareprodukts für die Übertragung in eine andere Einsatzumgebung (funktionale und technische Einsatzumgebung).

Diese Klassifizierung bezieht sich primär auf Endprodukte von Softwareprojekten (Programme, Dokumentationen).

Die Qualität eines Endprodukts ist aber in hohem Maße abhängig von der Qualität der Zwischenprodukte (diese Aussage gewinnt mit der Größe eines Projekts zunehmend an Bedeutung). Entsprechend sind auch bei Zwischenprodukten Qualitätsmerkmale zu unterscheiden, um das kontinuierliche "Sich-Aufbauen" von Qualität im Softwareprojekt planen, steuern und überhaupt realisieren zu können.

Als zusätzliche Klassen von Qualitätsmerkmalen ergeben sich:

- Transformationsbezogene Qualitätsmerkmale

Sie wirken auf die Eignung eines Software-Zwischenprodukts für anschließende Transformationsaktivitäten (Weiterentwicklung, Übertragung in ein höherwertiges Zwischenprodukt), und damit unmittelbar auf die Fehlerrate sowie den Aufwand für die Transformation.

- Softwareendprodukt-bezogene Qualitätsmerkmale

Sie sind Merkmale von Zwischenprodukten und wirken unmittelbar auf die spätere Eignung des Softwareendprodukts für die geplante Aufgabenlösung (so etwa Merkmale eines Lösungsalgorithmus im Entwurf, der unmittelbar die Laufzeit sowie den Speicherbedarf des Softwareendprodukts bestimmt).

Dipl.-Kfm. Heinz Bons und Dipl.-Kfm. Rudolf van Megen sind als Unternehmensberater auf dem Gebiet der Software-Qualitätssicherung (generell) und des Software-Tests (speziell) tätig. Die Büroanschrift lautet: Universitätsstr. 79, 5000 Köln 41, Tel.: 02 21/40 20 97.