Dieter Jekat, Leiter des Bereiches Information Services der Infratest Wirtschaftsforschung GmbH, München
Kauf- oder Mietverträge für Software-Produkte enthalten in der Regel die Zusicherung, daß auftretende Mängel in angemessener Frist vom Lieferanten beseitigt werden. Eine Garantie für die Fehlerfreiheit des Programmes oder die einwandfreie Funktionsfähigkeit (entsprechend vorgegebener Spezifikationen) fehlt. Die Frage eines Prüfzeichens für Programme wird seit Jahren diskutiert. Insbesondere im Zusammenhang mit der Ordnungsmäßigkeit der Buchführung. Welche Chancen bestehen für die Einführung eines allgemeinen Prüfzeichens für Programme? Und welche Randbedingungen sind zu beachten? Dazu einige vollständige Hinweise:
Zunächst ist festzustellen, daß allgemein anerkannte Standards für die Beurteilung der Qualität von Software fehlen. Dies gilt nicht nur für die Bundesrepublik, sondern auch für die USA, wie ein entsprechender, Untersuchungsbericht des Standford Research Institutes zeigt.
Für zahlreiche industrielle Materialien und Produkte existieren dagegen allgemein anerkannte Standards zur Qualitätsbeurteilung entsprechende Meßgrößen und -verfahren sind bekannt ( VDE-Prüfzeichen, DIN-Normen). Software-Produkte sind derzeit dagegen nur "beschränkt prüffähig" durch Programmtests läßt sich bisher mit Einschränkungen die formale Richtigkeit sowie die Anwesenheit von Fehlern, jedoch nicht deren Abwesenheit feststellen. Darüber hinaus kann - ebenfalls nur mit Einschränkungen - festgestellt werden, ob ein Programm die ihrer zugeschriebenen Funktionen erfüllt. Diese Feststellungen allein sind für den potentiellen Software-Nutzer nicht ausreichend. Der Programmnutzer muß in der Lage sein, die Produktspezifikationen mit seinen eigenen Anforderungen zu vergleichen und zu bewerten. Das heißt, er muß die Eignung des Programmes für eine bestimmte Aufgabenstellung prüfen können. Und hierbei ergeben sich erhebliche praktische Schwierigkeiten, da nur in den wenigsten Fällen die Anforderungen eindeutig spezifierbar sind. Insbesondere dann nicht, wenn ein Programm Teil eines "Man-Machine-System" ist (zum Beispiel ein Vertriebssteuerungssystem). Allgemeiner formuliert: Organisationsforrnen sind nicht in physikalischen Größen meßbar. Und selbst bei technisch-wissenschaftlichen Programmen, die auf einem rnathematisch beschreibbaren Lösungsalgorithmus basieren, kann durch ein Prüfzeichen eine a priori richtige Anwendung nicht sichergestellt werden. Daraus folgt, daß ein allgemeines Prüfzeichen für Programme, daß die Dimensionen Qualität und Eignung umfaßt, nicht vergeben werden kann. Eine labormäßige Prüfung von Programmen, wie sie für Werkstoffe und Geräte seit Jahren üiblich ist, kann derzeit nicht durchgeführt werden. Es fehlen objektive und quantitative Maßstäbe für die Beurteilung sowie geeignete und "geprüfte" Untersuchungsmethoden. Auf einige weitere Aspekte sei noch hingewiesen:
Programme werden nur selten in der Originalversion eingesetzt; bei Anwendungsprogrammen sind in der Regel betriebsspezifische Modifikationen erforderlich. Dann wäre der Entzug des Prüfzeichens notwendig bzw. eine Neuvergabe des Prüfzeichens.
Und was würde durch ein Prüfzeichen attestiert? Die formale Richtigkeit des Programrnes, die Fehlerfreiheit, die Eignung zur Lösung eines bestimmten Problems, funktionale Vollständigkeit, die Übereinstimmung mit vorgegebenen Spezifikationen, die Anpassungsfähigkeit, die Modularität, die Portabilität, die Wartbarkeit, die Effizienz, der Nutzen oder die Zuverlässigkeit? Die meisten dieser Kriterien sind Design-Kriterien, die sich gegenseitig beeinflussen. Und die Prüfmöglichkeit selbst ist ebenfalls als Design-Kriterium zu betrachten. In die Qualitätsbeurteilung mit einzubeziehen ist die Eigenschaft eines Software-Systems, unzulässige Input-Daten zurückzuweisen, denn es besteht die Gefahr, daß der Software-Nutzer Opfer unzulänglicher Input-Daten wird ("garbage in - gospel out") - eine Überlegung, der besondere Bedeutung zukommt im Hinblick auf Programme der öffentlichen Verwaltung (Berechnung von Renten) oder bei Programmen zur Berechnung von Reaktorbauteilen.
Wer sollte nun autorisiert werden ein Prüfzeichen für Software vergeben zu dürfen? Ein "Bundesamt für Software-Prüfung, Software-Hersteller, Benutzerorganisationen? Und wie sollten die Aktivitäten einer Prüfungsinstanz finanziert werden? Weichen Einfluß haben die angewandten Entwicklungsverfahren und Produktionstechniken oder die Qualifikation der Software-Produzenten auf die Software-Qualität? Welchen Einfluß hätte ein derartiges Prüfzeichen auf den Software-Markt und die Software-Anbieter? Zu bedenken sind weiterhin rechtliche und finanzielle Aspekte, auch im Hinblick auf die Produzentenhaftung.
Welche Schritte sollten nun konkret unternommen werden um dem Ziel der Qualitätsprüfung/ -sicherung für Software näherzukommen? Zur Zeit existieren für die meisten Software-Produkte keine Funktionsstandards. Daher wäre die Erarbeitung solcher Standards ein erster Schritt; beispielsweise die Festlegung der Funktionen nie ein Nettolohn-Programm zur Verschnittoptimierung für die Textilindustrie oder ein Entscheidungsabstellengenerator mindestens müßte. Obwohl solche Funktionsstandards keine Garantie für die Leistungsfähigkeit, Qualität und Zuverlässigkeit eines Software-Produktes in einer benutzerspezifischen Umwelt geben können, sind sie für viele potentielle Software-Käufer sicher eine nützliche Hilfe. Ein weiterer Schritt wäre in der Darlegung der bisherigen Erfahrungen von Software-Nutzern mit bestimmten Programmen zu sehen (consumer model). Ein erster Ansatz dazu wird derzeit für den ISIS Software-Report erarbeitet.
Zur Festlegung der Funktionsstandards sind noch intensive Forschungsarbeiten notwendig. Diese Forschungsarbeiten sollten in enger Zusammenarbeit zwischen Wissenschaft und Praxis erfolgen. Ob die Einrichtung einer Institution für Software-Prüfung dazu empfehlen werden kann., muß bezweifelt werden.
"On the feasabilith of software certification". By: R. E, Keirstead prepared for National science Foundation Grant No. GJ 36903x1 SRI Project 2385, 1975.