Einsatz der Software und Betriebsbewährtheit: Nutzen der berechneten Zuverlässigkeit

Nutzen Die wesentlichen Anwendungen der berechneten Werte sind: Nachweis, daß die spezifizierte Zuverlässigkeit erreicht wird Festlegen eines Auslieferungszeitpunktes Verwenden in probabilistischen Systemanalysen Der Nachweis, daß die spezifizierte Zuverlässigkeit erreicht wird, geschieht durch einfachen Vergleich der spezifizierten mit den ermittelten Werden.

Aus der Kenntnis der Versagenshäufigkeit, der Testkosten und der Fehlerbeseitigung läßt sich der ,break even point' für die Auslieferung eines Software-Paketes bestimmen.

Durch Verkaufsstatistiken sind die große Anzahl und die unterschiedlichen Anwendungen zu belegen. Um nachzuweisen, daß keine oder nur unwesentliche Software-Fehler aufgetreten sind, benötigt man die vollständigen Fehlerlisten oder Rücklaufstatistiken.

Bei probalistischen Systemanalysen ist zu beachten, daß man die gefundenen Ausfallraten auf Kalenderzeiten umrechnen muß. Die Tatsache, daß die Betriebsbedingungen sich von den Testbedingungen unterscheiden, wird durch Verwendung eines größeren k-Faktors (z.B. k=5) ausgeglichen. Der Übergang auf das betriebliche Verhalten ist aber durchaus schwierig. Die Schwierigkeit entsteht, weil die Art und Weise, wie das Programm benutzt wird, also welche Eingabedaten mit welcher Wahrscheinlichkeit anliegen, nicht explizit in die Modellierung eingeht. Einige Autoren setzten hierfür Faktoren an, die die Effizienz des Tests im Vergleich zum Normalbetrieb ausdrücken sollen. Hierdurch wird das Problem jedoch auf die Quantigizierung dieser Faktoren verlagert. Hier sollen rein qualitativ die Unterschiede des Testbetriebs im Vergleich zum Normalbetrieb aufgeführt werden:

Beim Testen wird selten derselbe Eingabedatensatz mehrfach am Programm anliegen, während dies im Normalbetrieb (problemabhängig) durchaus der Fall sein kann. Bei einem sorgfältigen Test werden auch solche Funktionen mit einbezogen, die im Normalbetrieb vielleicht sehr selten auftreten, wie Grenzsituationen für die Speicherverwaltung, zeitlich ungünstiges Eintreten von Anforderungen... Beim Testen können mögliche Konstellationen der Eingabedaten übersehen werden. Im Betrieb sind die Anforderungen denkbar, die niemand berücksichtigt hat.

Es wird häufig aus einer zu ,,Technischen'' sicht getestet. Die ersten beiden Punkte lassen das Programm im Normalbetrieb besser erscheinen als in der Testphase, während der letzte es bezüglich der Zuverlässigkeit verschlechtert. Wenn das zu testende Programm keine Pionierentwicklung ist, sondern sind die Probleme die bei der Entwicklung auftreten können bereits bekannt, so kann man die Möglichkeit, daß etwas übersehen wird, unter Umständen gegenüber den anderen Punkten vernachlässigen. Dann ist eine Versagensrate aus der Testphase eine konservative Näherung an die des betrieblichen Verhalten.

Ebenfalls schwerwiegend ist, daß die letzten fehlerfreien Laufzeiten das Ergebnis bestimmen. Deshalb ist Software mit sehr hohen Anforderungen an die Zuverlässigkeit mit diesen Modellen praktisch nicht zu qualifizieren.