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.

09.06.1978 - 

Systemstabilität geht vor Kostendenken:

"Austesten" garantiert keine Fehlerfreiheit

Die zunehmende Komplexität sowohl der Datenverarbeitungsanlagen als

auch der damit verbundenen Problemlösungen (möglichst hoher Integrationsgrad) haben dem Aspekt der Systemstabilität gegenüber dem Kosten- beziehungsweise Effizienzfaktor eine höhere Priorität verschafft. Die folgenden zwei Beispiele mögen diese Aussage verdeutlichen:

Die Ineffizienz eines Programmes wird sehr schnell erkannt und kann durch geeignete Maßnahmen (Tuning) abgebaut werden; fehlerhafte Software hingegen wird nicht unbedingt sofort bemerkt und kann somit zu unqualifizierbaren, wenn nicht sogar zu unqualifizierbaren Folgefehlern führen.

Beim vermehrten Übergang von Batch- zu Dialogverarbeitung ist die Zuverlässigkeit Voraussetzung für eine sinnvolle Anwendung, da der Endbenutzer (Fachabteilung) auf die Richtigkeit der Ergebnisse vertrauen muß.

Wie erreicht man aber in der Praxis diese notwendige Sicherheit?

Die lange vertretene Ansicht, Zuverlässigkeit ließe sich nur durch "Austesten" erreichen, trifft nicht zu. Durch Testen kann man nur das Vorhandensein von Fehlern beweisen, nicht aber Fehlerfreiheit.

Die traditionelle Auffassung ist dadurch gekennzeichnet, daß man den Test als ein Anhängsel der Programmierphase ansieht. Auf diese Weise erkennen wir Fehler der Systementwicklung jedoch zu spät, nämlich erst in der Endphase, eventuell erst während der Produktion. Wir dürfen uns eben nicht darauf beschränken, nur die Endergebnisse einem Test zu unterziehen.

Die Qualität der Arbeitsergebnisse zu prüfen, ist dort schwierig, wo Form und Inhalt nicht standardisiert sind und insofern auch keine allgemeingültigen Beurteilungsmaßstäbe vorliegen. Das Streben muß deshalb dahin gehen, nicht erst für die Programmierung, sondern bereits für die Analysenphase auf der Grundlage eines umfassenden methodischen Konzeptes Standards einzufahren. Es ist ein Unterschied, ob das System-Design nur verbal beschrieben oder durch HIPO-Diagramme, Entscheidungstabellen, Datenflußpläne und Programmstrukturbeschreibungen mit Pseudo-Code in eine Form gebracht wird, die die Überprüfbarkeit und Revidierbarkeit der Ergebnisse ermöglicht.

Eine softwareunterstützte Methodenbank, in der die fertiggestellten Teilergebnisse wie Dateibeschreibungen und Systemdokumentation abgestellt werden, ist wichtiger Bestandteil eines solchen Konzeptes.

Die Anwendung von Methoden und Werkzeugen der Systementwicklung sicherzustellen, ist eine wichtige Aufgabe der Projektführung. Systementwicklungs-Handbücher müssen für jede Phase des Projektes auch die methodischen Standards festlegen. Zu den Meilensteinen des Projektes ist der Nachweis zu erbringen, daß die Ergebnisse unter Verwendung der vorgeschriebenen Methoden und Hilfsmittel in der geforderten Form vorliegen. Erst dann ist eine Fertigmeldung der Phase zulässig.

Die erweiterte Formalprüfung schließt Fehler nicht aus, aber kann sie reduzieren, und zwar vor allem dann, wenn durch die Anwendung zweckmäßiger Methoden auch materiell eine bessere Qualität der Ergebnisse bewirkt wird.

In diesem Sinne sehen wir den Zusammenhang zwischen Projektsteuerung einerseits und Systementwicklung andererseits.

* Leitender Berater und Vertriebsbeauftragter der GMO, Hamburg.