Qualitätssicherung scheint das "ewige Thema" in der Datenverarbeitung zu sein. Zwar gibt es inzwischen eine ganze Reihe brauchbarer Methoden zur Fehlerfindung und Qualitätsmessung, viele grundlegende Probleme sind jedoch noch nicht beseitigt. Fünf Richtlinien für das Qualitätsmanagement präsentiert hier Harald Oestrich*.

Trotz ihrer unbestrittenen Nützlichkeit konnten die verfügbaren Instrumente das Problem der Qualitätssicherung bisher nicht lösen. Der Grund für diese Situation liegt offenbar darin, daß die Tools Fehler in der Software zwar aufzufinden helfen aber nicht in der Lage sind, Fehler zu vermeiden.

Qualitätssicherung steht heute vor zwei unbewältigten Hauptproblemen:

- Die meisten und schwerwiegendsten Fehler werden im Fachkonzept gemacht, aber erst beim Programmtest entdeckt.

- Die daraus resultierende Vielzahl an Korrekturen zerstört die Struktur gut entworfener Programme und treibt damit den Wartungsaufwand ins unermeßliche.

Eine Therapie für dieses Syndrom kann nur darin bestehen, daß man die heutige technische Qualitätssicherung zu einem Qualitätsmanagement weiterentwickelt. Qualitätsmanagement bedeutet, die strategischen Ziele zu definieren sowie die technische und organisatorische Infrastruktur für das angestrebte Qualitätsniveau aufzubauen.

Voraussetzungen für präventive Maßnahmen

Die Instrumente der Qualitätssicherung kontrollieren das Qualitätsniveau in der täglichen Softwareproduktion (operative Qualitätssicherung).

Ein modernes Qualitätsmanagement basiert auf fünf Grundregeln:

Fehler, die nicht gemacht werden, brauchen nicht korrigiert zu werden. Trotz dieser Binsenweisheit wird heute zwar alles getan, um Fehler zu finden, aber so gut wie nichts, um Fehler zu vermeiden - außer daß jeder Entwickler nach bestem Wissen und Gewissen arbeitet. Dies reicht aber nicht aus. Eine wirkungsvolle präventive Qualitätssicherung ist erst dann möglich, wenn die technischen und organisatorischen Voraussetzungen geschaffen wurden.

Projektbegleitende Qualitätssicherung

Leider ist heute Software immer noch ein Synonym für Programm, was zur Folge hat, daß die Qualitätssicherung nur die Programme prüft, nicht aber die fachliche Dokumentation - sofern sie überhaupt existiert. Sobald man aber verinnerlicht hat, daß Dokumentation und Programme zwei Seiten ein und derselben Medaille sind, wird man vom ersten Projekttag an Qualitätssicherung betreiben müssen. Damit wird man dem Ziel sehr nahe kommen, Fehler in den Phasen zu finden, in denen sie auch gemacht wurden. Die formale und inhaltliche Prüfung der fachlichen Dokumentation ist sicher kein einfaches, aber beim heutigen "Stand der Kunst" ein lösbares Problem.

Stabiles Fachkonzept

Ein DV-System ist letztendlich ein Organisationsmittel, wobei die Software die Aufgabe hat, die betriebliche Realität im Rechner abzubilden. Was ist aber die betriebliche Realität? Bevor man eine DV-technische Lösung anstrebt, muß diese Realität in allgemein verbindlicher Form festgeschrieben werden - im Fachkonzept. Das Fachkonzept ist aber erst dann eine tragfähige Basis, wenn es auf logische Richtigkeit und Vollständigkeit überprüft und inhaltlich abgesichert ist.

Eine inhaltliche Überprüfung im Sinne einer Validation ist nicht möglich, da die betrieblichen Gegebenheiten nur unvollständig schriftlich fixiert sind. Man ist daher auf mündliche Aussagen angewiesen (Interviews). Um die Fachinhalte abzusichern, gibt es nur einen Weg: Kompetente Mitarbeiter des Fachbereichs müssen hauptamtlich im Projekt mitarbeiten und befugt sein, verbindliche Fachaussagen zu treffen.

Einheit von Analyse und Lösung

Technische Lösungen wurden in der Vergangenheit häufig am Fachkonzept vorbei entwickelt. Die Ursache lag darin, daß das Fachkonzept in mehr oder weniger unstrukturierter Prosa geschrieben war. Wenn aber nicht darstellbar ist, welche technische Komponente welchen betrieblichen Ablauf oder welche betriebliche Regel unterstützt, dann kann man auch nicht verifizieren, ob das DV-Konzept alle fachlichen Anforderungen erfüllt. Eine solche Verifikation ist nur möglich, wenn mit Hilfe der Methoden des "strukturierten Design" eine Systemarchitektur entworfen wird, in der die fachlichen Strukturen wiederzufinden sind.

Automatisierung des Gesamtkonzepts

Walk-Thrus eignen sich eher, um globale Konzeptionsfehler oder -schwächen aufzuzeigen, als logische Fehler zu entdeeken. Die Überprüfung der logischen Richtigkeit und Vollständigkeit muß daher an den Rechner delegiert werden. Dies setzt voraus, daß sowohl die fachliche als auch technische Systemarchitektur im Rechner interpretierbar abgebildet ist.

Hierzu bedarf es spezieller Entwicklungssysteme, die auf einer Entwicklungsdatenbank basieren. Die Entwicklungsdatenbank verwaltet die gesamte Systemarchitektur, wobei angeschlossene Generatoren Dokumentation und Programme erzeugen. Bevor die Programme generiert und getestet werden, laufen - projektbegleitend - qualitätssichernde Prozeduren ab, die die logische Richtigkeit der Architektur absichern. Sie verhindern damit, daß Architekturfehler in die Programme einfließen. Solche Systeme sind bereits heute am Markt erhältlich.

* Harald Oestrich ist Marketing-Leiter beim EDV Studio Ploenzke, Wiesbaden.