Leitfaden der Softwaretest e.V. für Manager:

Kosten senken durch Qualitätssicherung

08.04.1982

Wenn von Qualitätssicherung die Rede ist, denkt jeder zuerst an die Kosten. Doch alle bekannten Beispiele aus Hardware und Software beweisen das Gegenteil: Anerkannte Qualitätsprodukte sichern den Erfolg - und damit den Gewinn - jedes Unternehmens.

Ursache für die recht einseitig geführte Diskussion um und über die Qualitätssicherung in der Softwareentwicklung ist zum größten Teil die unsachgemäße Argumentation der DV-Experten. Vom Standpunkt des Unternehmers aus betrachtet, unterscheiden sich alle Aufwendungen für die Erstellung eines Produktes in einen fixen "Kostenanteil" und einen variablen "Investitionsanteil". Qualitätssicherung ist zunächst einmal eine Investition, von der andererseits ein Gewinn erwartet werden kann.

Kurzfristig erreicht man mit Qualitätssicherung in der Softwareentwicklung eine Kostenersparnis, langfristig einen Gewinn in Form von Marktfestigung, Kundentreue sowie Solidität des Unternehmens. Mit dieser Zielsetzung gewinnt die Qualitätssicherung auch ihre eigentliche Bedeutung: Sie ist kein "notwendiges Übel", sondern ein Managementinstrumentarium für die Unternehmensleitung.

Die in den letzten Jahren verstärkt geführte Diskussion über Methoden und Werkzeuge der Qualitätssicherung bekam diese Schlagseite in Richtung Kosten, weil sich die falschen Leute, nämlich die Softwareentwickler dieser Sache angenommen haben. Unter diesen Voraussetzungen mußten zwangsläufig alle Qualitätssicherungsmaßnahmen die Entwicklungskosten erhöhen. Erst wenn die Qualitätssicherung zu einer eigenständigen Einrichtung innerhalb eines Unternehmens geworden ist, können diese Maßnahmen, die selbstverständlich Aufwendungen verursachen, an ihrem Erfolg in Form von Einsparungen oder Gewinnen, gemessen werden.

Der Ausschuß für Qualitätssicherung und Statistik (ASQ) im Deutschen Institut für Normung e.V. hat in der DIN 55 350 Qualität als "die Gesamtheit aller Eigenschaften und Merkmale von Produkten und Tätigkeiten" festgelegt, "die sich auf die Eignung zur Erfüllung gegebener Erfordernisse beziehen". Und derselbe Ausschuß hat weiter festgestellt, daß sich "die Erfordernisse aus dem Verwendungszweck eines Produktes. .. ergeben, unter Berücksichtigung der Realisierungsmöglichkeiten". Damit ist eigentlich eine Brücke zwischen "Theorie" und "Praxis" geschlagen, so einfach das auch klingen mag.

Es gibt eine ganze Reihe von methodischen Ansätzen, Vorgehensweisen und Methoden unterstützende Werkzeuge, die geeignet sind eine Softwareentwicklung qualitativ zu verbessern. Doch muß deren Verwendung stets auf die Ziele des Unternehmens (oder Projektes) abgestimmt werden, sonst wird jedes Tool zur "Selbstbefriedigungsmaschine " in der Hand der Entwickler.

Softwaretest e.V., dessen satzungsmäßiges Ziel "die Hebung der Qualität von Computerprogrammen in Wirtschaft und Verwaltung ist, hat einen "Leitfaden für die Qualitätssicherung in der Softwareentwicklung" herausgebracht. Darin sind in verständlicher, lesbarer Form (ohne "Fachchinesisch" ) Anhaltspunkte für Qualitätssicherungsaufgaben und Qualitätssicherungsmaßnahmen, einschließlich des personalen und organisatorischen Umfelds aufgezeigt. Zieladresse dieser 20seitigen Broschüre ist in erster Linie das Management.

Mit einem "Fünfpunkteprogramm" kann jeder, der sich mit der Thematik der Qualitätssicherung Software beschäftigt, erste Hinweise finden wo und wie "der Hebel" für eine effiziente, das heißt wirtschaftliche und gewinnbringende Qualtitätssicherung in der Softwareentwicklung anzusetzen ist. Kurzfristig kann mit diesem Programm eine spürbare Kostenreduzierung bei gleichzeitiger Qualitätsverbesserung erzielt werden, die das Management zu einer intensiveren Qualitätssicherung motivieren soll. Der langfristige Erfolg wird danach nicht ausbleiben.

Weniger Leute leisten mehr

Die Entwicklungsleistung setzt sich aus den Komponenten "Nutzleistung" und "Blindleistung" zusammen. Erstere fließt unmittelbar in den Projektfortschritt ein, letztere ist ein notwendiger Anteil der Arbeitszeit für Organisation und Kommunikation innerhalb eines Projektes oder einer Abteilung. Mit steigender Zahl der Mitarbeiter nimmt die Blindleistung "exponentiell" zu, die Nutzleistung fällt rasch ab. Die "optimale" Projektgröße (gemessen an der Zahl der Mitarbeiter) muß stets der Aufgabenkomplexität und der Umgebung (Qualifikation der Mitarbeiter, Güte der innerbetrieblichen Kommunikation) angepaßt werden. Anhaltspunkte für die optimale Projektstärke (im Schnittpunkt der Kurven "Nutzleistung" und "Blindleistung" in Abhängigkeit von der Mitarbeiterzahl) hat Softwaretest e.V. in der Broschüre "Wachstumsverluste" zusammengefaßt.

Unklare Anweisungen sind der Anfang allen Übels. Viele Programme entstehen vorzugsweise nach den Vorstellungen der Programmierer und weisen nach Fertigstellung große Lücken gegenüber den Anforderungen der Bedarfsträger oder Anwender auf. Die Folge davon sind permanente Wartungsaufwendungen. Die Grauzone unklarer Anweisungen und Spezifikationen bei Projektbeginn ist die Ursache für häufig beträchtliche Geld- und Sachmittelaufwendungen, die niemals ein brauchbares Ergebnis zeigen.

Wer es durchsetzt, ein Projekt erst dann zu starten, wenn die Anforderung klar sind, das heißt, wenn zumindest die "Was-Beschreibung" vollständig ist, kann hier erheblich mehr Geld sparen, als die Überprüfung der Anforderungen auf Vollständigkeit kostet.

Es gibt ein untrügliches Merkmal für die Entwicklungstransparenz: Ist ein Entwicklungsdokument (eine Spezifikation oder ein Quellprogramm) von einem anderen Mitarbeiter gleicher Qualifikation lesbar, verständlich und mit einfachen Mitteln prüfbar, dann ist eine Entwicklung transparent. Im allgemeinen ist dieses Ziel aber nicht ohne Schulung in methodischer Vorgehensweise und projektbegleitender Beratung der Entwickler zu erreichen. Der "gesunde Programmiererverstand" ist mit Abstand die aufwendigste und teuerste "Methode". Wer glaubt, daß "Programmieren nicht grundsätzlich schwierig ist und von gewissenhaften Schwachköpfen erledigt werden kann, solange man nur genügend davon hat, begeht Selbstbetrug, der nicht ungestraft bleibt". (Zitat: Edsger W. Dijkstra in einem Vortrag, Dezember 1969)

Unzweifelhaft verschlingt das Testen noch immer den größten Brocken der Entwicklungsaufwendungen. Es ist aber vielmehr so, daß Testen ohne Vorgaben, ohne Teststrategie und Testziele im Prinzip beliebig lang ausgedehnt werden kann. Die Aussage über den Stand des Testens ist bei dieser Vorgehensweise zu jedem Zeitpunkt gleich gut: Wenn die Vergleichsangabe, das Maß für "100 Prozent getestet", fehlt, sind Aussagen wie. "20 Prozent oder 80 Prozent getestet" völlig irrelevant und hinfällig.

Wird dagegen der Zugang zum Testen drastisch eingeschränkt, beispielsweise durch die Forderung nach einem Testplan, überlegt sich ein Softwareentwickler, wie er mit weniger Testzeit auskommen kann. Das wiederum wirkt sich positiv auf den Programmentwurf aus: Je einfacher und transparenter ein Programm ist, desto weniger "unklare Stellen" enthält es, die "ausgetestet" werden müssen.

Langfristig wird, "Testen" ohnedies durch eine andere Vorgehensweise ("Programmverifikation" ) ersetzt werden müssen. Die ersten erkennbaren Ansätze dieser Methode lassen berechtigte Hoffnungen zu.

Konfigurationskontrolle als Filterprozeß

Weil Duplikate von Programmen angeblich "nichts kosten", hält sich jeder Entwickler seine eigenen - unkontrollierten - Bibliotheken. Darin wimmelt es oftmals bloß so von "Programmleichen, von "Rudimenten" und "Torsen", abgebrochenen Routinen und nicht funktionsfähigen Moduln. Die bedenkenlose Verwendung unkontrollierter Programme in der Softwareentwicklung ist vorsätzliche Geldverschwendung! Denn die scheinbar "kostenlosen" Soft-Copies erweisen sich als teurer und gefährlicher Ballast.

Eine durchdringende Konfigurationskontrolle, die sich nicht mit Formalitäten begnügt, sondern versucht, den Inhalt der Dokumente und Programme zu erfassen, spart nicht nur hohe Kosten, sondern ist der erste und wichtigste Schritt zur Verbesserung der Programmqualität. Nur die konsequente Konfigurationskontrolle erlaubt eine gesicherte Aussage über den Stand eines Projektes, über Risiken und Rest-Risiken.

Der direkte Gewinn dieser Maßnahmen zeigt sich in der Kosteneinsparung. Bei sachgemäßem Einsatz, der stets die zu erreichenden Ziele im Auge behält, sind die Einsparungen an Entwicklungsaufwendungen in jedem Falle größer als die Aufwendungen für die Qualitätssicherung, für eine vernünftige Datenbank, für die Konfigurationskontrolle.

Allein durch die Anwendung des zuvor genannten "Fünfpunkteprogramms" können bis zu 30 Prozent (und mehr) der Entwicklungskosten bei Neuentwicklungen eingespart werden. Dem stehen Aufwendungen in Höhe von fünf bis zehn Prozent (des ursprünglichen Kostenansatzes) für das Qualitätssicherungsprogramm gegenüber.

Der weitaus größere Gewinn liegt, wenn auch zunächst unsichtbar und deshalb nicht direkt meßbar, in der langfristigen Sicherung des Produkt und damit des Unternehmenserfolgs. Dazu gehört auch, daß Qualitätssicherung eine Risikoabschätzung für jede Neuentwicklung erlaubt, die ein Unternehmen vor bösen Überraschungen bewahren kann.