Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

TÜV-Plakette für "fertige" Minicomputer-Programme?

Demo kann Abnahmeprüfung nicht ersetzen

20.06.1981

Programme, die als "fertig und getestet" vorgestellt werden, stecken oft noch voller Fehler. Mindestens die Hälfte aller Mängel "ertesten" die Anwender. Dies ist eine der Hauptursachen für den hohen Anteil der Software-Wartungskosten. Bei Neuentwicklungen kommerzieller Standard-Anwendungen ist deshalb besondere Vorsicht geboten.

Steigende Kosten in der Entwicklung individueller Software können auch bei Minicomputern durch den Einsatz von Standard-Software aufgefangen werden. Der Markt für Fertig-Programme bietet eine Vielzahl brauchbarer Lösungen an. In jedem Einzelfall ist jedoch eine Entscheidung notwendig, ob das Programm die fachlichen und qualitativen Anforderungen auch erfüllt. Aufschluß über die Eigenschaften und Leistungen des Programms gibt nur eine exakte Abnahmeprüfung. Bei bestandener Prüfung ist das Ergebnis einer TÜV-Abnahme gleichzusetzen.

Die übliche Praxis beim Einsatz von Standardprogrammen ist eine "Vorführung" durch den Hersteller an Stelle einer "Abnahme" durch den Kunden. Der Unterschied fällt zunächst nur dem geübten Spezialisten auf, denn in beiden Fällen läuft das Programm ab, verarbeitet Daten und zeigt Ergebnisse. Bei einer Vorführung allerdings werden meist Daten verarbeitet, die auf den Rechner, das Betriebssystem und das "Demo"-Programm abgestimmt sind, bei denen mit Sicherheit also keine Fehler auftreten. Bei einer Abnahme dagegen werden solche Daten zur Verarbeitung bereitgestellt, die das Programm laut seiner Spezifikation verarbeiten soll. Und damit beginnen für die meisten Programme die ersten und ernsten Schwierigkeiten.

Testen kann teuer werden

Beispiele aus der Praxis weisen deutlich auf die Notwendigkeit einer ordnungsgemäßen Überprüfung von Anwenderprogrammen hin, bevor diese zur "allgemeinen Nutzung" freigegeben werden:

- Zahlreiche Compiler (Cobol und Fortran) weichen von der ANSI-Spezifikation ab; daraus entstehen Portabilitätsprobleme bei Modell- oder Systemwechsel.

- Die meisten Minicomputer verwenden den ASCII-Code. Datenträger, vor allem Magnetbänder und Disketten, müssen vor der Weiterverarbeitung auf Großrechnern, die ED DIC-Code verwenden, erst konvertiert werden.

- Das Anforderungsprofil von kommerziellen Anwendungen an das Betriebssystem ist ganz anders als bei Realzeitanwendungen. Besonders im Multi-Programming- oder Multi-User- Betrieb zeigen Minicomputer ein anderes Verhalten als im Realzeitbetrieb. Oft zur Enttäuschung der Anwender.

Diese drei Beispiele, die recht häufig anzutreffen sind, gehen noch gar nicht auf die Problematik spezieller Anwendungen ein. Dort steckt der Teufel wirklich im Detail.

Musterabnahme als Alternative

Die Lösung dieses Problems ist allgemeines Verfahren zur Prüfung und Bewertung von Softwareprodukten, das von Herstellern und Kunden anerkannt ist und das als Musterabnahme eines Programms gilt. Wegen des großen Umfangs kann diese Abnahme nicht mehr der Anwender durchführen. Hier müssen Spezialisten eingesetzt werden, die über die dazu nötigen Hilfsmittel und Erfahrungen in der Programmentwicklung im Programmtest und auch in der Anwendung verfügen.

Ein allgemeines Verfahren zur Musterabnahme muß die folgenden Prüfpunkte enthalten:

1. Funktionen und Leistungen

Der Funktionstest soll die Unterschiede zwischen dem implementierten Programm und der Spezifikation aufdecken. Die Testfälle müssen dabei folgenden Randbedingungen genügen:

- Einteilung der Testfälle in Äquivalenzklassen zur Einschränkung des Testumfangs. Zeigt der Test eines Elements einer Klasse einen Programmfehler, führen sämtliche anderen Testdatensätze zum gleichen Fehler.

- "Negativtests", um die Reaktionen des Programms auf falsche Eingaben zu prüfen.

- Prüfung von Grenzwerten, das heißt Werten, die an den "Rändern" der Äquivalenzklassen liegen. Erwartet ein Programm zum Beispiel Werte, die zwischen (-1) und (+1) liegen, so sollen zum Test die Fälle (-1.1), (-1), (1 ), und ( 1.1 ) ausgewählt werden.

Tests von Funktionsfolgen sollen die Modularität der Anwendung aufzeigen. Einzelne Funktionen müssen sowohl isoliert als auch im Zusammenhang mit den spezifizierten Pre- und Post-Verarbeitungsfunktionen korrekte Ergebnisse liefern.

- Im Belastungstest soll überprüft werden, wie sich das Programm bei der Verarbeitung von großen Datenmengen verhält. Bei Erstinstallationen gehört dazu auch ein Belastungstest des Betriebssystems mit gleichzeitiger Verarbeitung von Anwendungs- und Dienstprogrammen (Compiler, Dump/ Restore etc.)

2. Benutzerschnittstelle

Beim Test der Benutzerschnittstelle sind die Bedingungen zu untersuchen, die der Anwender bei der Nutzung des Programms berücksichtigen muß:

- Ist die Benutzerschnittstelle der Intelligenz, Ausbildung und Umgebung des Anwenders angepaßt?

- Sind die Ausgaben des Programms sinnvoll in Aufbau, Umfang und Inhalt?

- Liefert das Programm verständliche Fehlermeldungen, zum Beispiel: "FEHLER IN WRITE-ANWEISUNG ZEILE 234 VARIABLE X", oder meldet es: "A3C ERR FO"?

- Besteht Konsistenz bezüglich Syntax, Semantik und Formaten der Eingaben?

- Bietet das Programm bei fehlerhafter Bedienung im Online-Betrieb Korrekturmöglichkeiten und Hilfestellungen für den Anwender?

3. Dokumentation

Die Dokumentation muß eine genaue und klare Darstellung des Softwareprodukts geben. Die in ihr enthaltenen Beispiele sollten als Testfälle verwendet werden können. Sie muß sämtliche Leistungen des Programms und das Vorgehen bei der Installation beschreiben. Der Umfang der Dokumentation muß der Komplexität der Anwendung angemessen sein. Pro Einzelfunktion sollen nicht mehr als zwei bis maximal fünf Seiten Beschreibung erforderlich sein.

Der Aufbau der Dokumentation muß eine klare inhaltliche Trennung zwischen den Teilen für die Installation und Programmwartung (für den Systemprogrammierer), für die Steuerung des Programms (für RZ und Operating) und für die Nutzung des Programms durch den Anwender ausweisen.

Beurteilung

Die Abnahmeprüfung der Programme erfolgt gegen deren Spezifikation die sich bei Standardprogrammen stark verkürzt im Angebot der Hersteller niederschlägt. Die Beurteilung des Softwareprodukts soll eine Zusammenfassung der einzelnen Testphasen, sowie eine Bewertung der Ergebnisse enthalten. Dem Anwender soll so eine Entscheidungshilfe gegeben werden, ob er das Programm zur Lösung seiner Probleme einsetzen kann.

Die Prüfergebnisse der Abnahmeprüfung sowie einige Eckdaten des Programms werden dokumentiert, so daß bei Programmänderungen (neue Versionen) oder Anwenderanpassungen lediglich die "Deltas" festgestellt und geprüft beziehungsweise abgenommen werden müssen.