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.

01.02.1980 - 

Komponente der Systemanalyse:

Eine Feasibility-Study vermeidet EDV-Unfälle

Von Karl-Heinz Weingarten

Feasibility-Studies (Durchführbarkeitsstudien), im folgenden FS genannt, beziehen sich im EDV-Bereich in der Regel auf zwei Gebiete: a) auf die Überprüfung der Durchführbarkeit einer Anwendung im Sinne der Lösung betrieblicher Funktionen (zum Beispiel Überprüfung, ob eine Auftragsabwicklung den tatsächlichen Verwendungsbedingungen entspricht); b) auf die Überprüfung der Durchführbarkeit einer Anwendung im Sinne der Leistungsfähigkeit in Verbindung mit einem EDV-System, also auf quantitative, durchsatztechnische Eigenschaften. Die nachfolgenden Betrachtungen beziehen sich ausschließlich auf Punkt b).

Es erstaunt nicht, mit wie viel Akribie heutige "EDV-Werktätige" sich der Analyse der eigenen oder anderer Organisationen widmen, um diese auf einen - wie auch immer gearteten - Computer zu übertragen. Denn die Systemanalyse erfreut sich im Gesamt-EDV-Geschehen einer hohen Wertschätzung, da von optimaler Vorbereitung natürlich sehr viel abhängt, nämlich, ob ein Computer Geist gibt oder ihn aufgibt.

Somit ist die Realisierung eines Anwendungssystems scheinbar eine nicht so attraktive Angelegenheit, da die Weichen durch die Systemanalyse bereits gestellt sind. Die Erstellung optimaler Anwendersoftware ist aber nicht nur von einer guten Systemanalyse, sondern gleichermaßen von der Beherrschung und Einhaltung bestimmter Systemregeln abhängig. Die FS zur Überprüfung der Leistungsfähigkeit rundet an dieser Stelle das Entwicklungsbild einer Anwendung ab.

Aber - es erstaunt wiederum nicht, wie viele solcher sorgsam geplanten Anwendungsprogramme im fortgeschrittenen Stadium den Geist aufgeben, dann mämlich, wenn die ersten Programmtests laufen.

Nachdem man also erhebliche Beträge in die Vorbereitung und Durchführung investiert hat, beginnt man - viel zu spät - mit der Analyse der Programme, so wie sie nun mal eben entstanden sind.

Daß Optimierungen in diesem Stadium kein nennenswerter Erfolg beschieden ist, muß hier nicht mehr sonderlich erwähnt werden. Fest steht, daß mit einer frühzeitig angesetzten FS zumindest die Problembereiche hätten erkannt werden können. Die FS ist somit eine Komponente der Systemanalyse zur Reduzierung vermeidbarer "EDV-Unfälle".

Gute Systemkenntnisse und ein gesunder Menschenverstand reichen aus, um die "Durchführbarkeit" eines Anwendungssystems zu überprüfen. Je nach dem Grad der Genauigkeit des Ansatzes wird eine solche Studie unterschiedlich exakte Ergebnisse liefern. Wie exakt das Ergebnis auch immer sein mag, es ist immer zu gebrauchen, da relativ zum Ansatz erste, wichtige Aussagen über Laufzeit und Systembelastung gemacht werden können.

Lineare Prozesse sind jene, die man ohne großen Aufwand "in den Griff" bekommen kann; handelt es sich jedoch um simultane Abläufe verschiedener Anwendungen, wird es schon schwieriger. Aber auch in diesem Fall ist eine lineare Betrachtung der einzelnen Anwendungen die Ausgangsbasis für eine FS.

Spätestens an dieser Stelle erkennt man, daß das Wissen um die quantitative (Zeit/Operation) und qualitative (sinnvolle Reihenfolge von Funktionen) Seite Voraussetzung für die Beschäftigung mit einer"FS ist. Die Zeit/Operation (zum Beispiel Plattenzugriffe, Leistungsgeschwindigkeit, Programmwechsel) sollten dokumentierter Bestandteil eines jeden EDV-Systems sein.

FS bedeutet für den Systemplaner folglich: Analyse der durch die Systemanalyse festgestellten Fakten im Hinblick auf die Übertragungsmöglichkeit auf ein EDV-System mit dem Ziel, Dauer und Systembelastung aller einzeln oder gleichzeitig verwendeten Anwendungsprogramme festzustellen. Darüber hinaus gilt es, ein Gesamtbelastungsprofil in zeitlicher Abhängigkeit zu bestimmen.

Die FS über ein Dialoganwendungssystem unterscheidet sich in der Komplexität wesentlich von der über stapelverarbeitende Anwendungen, da die Steuerung eines Multiprogramming-Systems berücksichtigt werden muß. Dennoch stellt jedes einzelne Programm einen linearen Vorgang dar, der relativ leicht analysiert werden kann. Der größte Unterschied zur Stapelanwendung liegt jedoch im Vorhandensein eines Faktors, der nicht mit der Gleichmäßigkeit von Maschinen abläuft und folglich schwer meßbar erscheint: die Bedienung der Terminals!

Feasibility-Studies über ein Dialogsystem lassen sich in zwei wesentliche Bereiche aufteilen:

- Funktionen, die vom EDV-System durchgeführt werden;

- Funktionen, die vom Bediener durchgeführt werden.

Diese beiden Funktionen sind je Anwendungsprogramm in Ansatz zu bringen. Dialogprogramme sollten der besseren Übersicht wegen in sogenannte Transaktionen aufgeteilt werden (zum Beispiel Aufteilung des Komplexes "Auftragsbearbeitung im Dialog" in die Transaktionen Auftragserfassung, -abfrage und -modifizierung).

Beispielsweise kann eine Transaktion in die folgenden einzelnen Operationen (hier "Dialogbestandsführung") zerlegt werden:

- Ausgabe an Terminal: "Kunden-Nummer"

- Reaktion auf Ausgabe Kunden-Nummer

- Plattendatei lesen: Konstantendatei

- Eingabe: Kunden-Nummer

- Plattendatei lesen: Kundenstamm

- Ausgabe an Terminal: "Kundenname"

- Reaktion auf Ausgabe Kundenname

- ...

Funktionen, die vom EDV-System durchgeführt werden

Diese sind aus den Aufgabenstellungen beziehungsweise Pflichtenheften zu entnehmen. Für die einzelnen Operationen wie interne Verarbeitung, Plattenzugriffe, Programmwechsel und Ein-/Ausgaben auf Terminals sollten für jedes System die Werte dokumentiert sein. Aus dem angeführten Beispiel sind die mit (+) gekennzeichneten Operationen dem EDV-System zugehörig:

- Ausgabe an Terminal: "Kunden-Nummer" (+)

- Reaktion auf Ausgabe Kunden-Nummer

- Plattendatei lesen: Konstantendatei (+)

- Eingabe: Kunden-Nummer

- Plattendatei lesen: Kundenstamm (-)

- Ausgabe an Terminal: "Kundenname" (+)

- Reaktion auf Ausgabe Kundenname

- ...

Funktionen, die vom Bediener durchgeführt werden

Die Leistung eines Dialogsystems ist erheblich von diesen Funktionen abhängig. Die quantitative Wertung der einzelnen Operationen beruht auf Empirie und wurde in der Vergangenheit durch die Definition sogenannter Durchschnittswerte gekennzeichnet (zum Beispiel Eingabe von numerischen Zeichen: 2 Zeichen pro Sekunde). Quantifiziert werden müssen zwei Operationen:

- die Zeit für die Eingabe von Zeichen am Terminal;

- die Reaktions- oder Interpretationszeit für eine am Terminal ausgegebene Nachricht.

Aus dem angeführten Beispiel sind die mit (0) gekennzeichneten Operationen dem Bediener zugehörig:

- Ausgabe an Terminal: "Kunden-Nummer"

- Reaktion auf Ausgabe Kunden-Nummer (0)

- Plattendatei lesen: Konstantendatei

- Eingabe: Kunden-Nummer (0)

- Plattendatei lesen: Kundenstamm

- Ausgabe an Terminal: "Kundenname"

- Reaktion auf Ausgabe Kundenname (0)

- ...

Ehe man sich der ganzheitlichen, exakten Leistungsberechnung zuwendet, sollte jedoch die Möglichkeit der systemunabhängigen Berechnung der Terminalleistung aufgezeigt werden. Dazu gehören die bereits erwähnten Faktoren:

- Ausgabezeit für eine Nachricht auf dem Terminal (zum Beispiel mit 2400 baud);

- Reaktions- oder Interpretationszeit des Bedieners für eine ausgegebene Nachricht;

- Eingabezeit für eine vom Bediener erfaßte Nachricht.

Setzt man die Summe der drei Faktoren/-Transaktion in das Verhältnis zu einer Zeiteinheit, ergibt sich die Erfassungskapazität eines Terminals für den gewählten Zeitraum. Darüber hinaus zeigt das Ergebnis dem Systemplaner auf, wie viele Terminals zur Abdeckung eines bestimmten Programmkomplexes benötigt werden.

Die oben genannten Faktoren enthalten noch nicht die Werte für die Antwortzeit, da diese durch die zu diesem Zeitpunkt noch nicht bekannten, systeminternen Vorgänge definiert werden. Deshalb ist das Berechnungsergebnis zu korrigieren.

Schreitet man zur exakten Bestimmung der Leistung, müssen die CPU-internen und Peripherie-bedingten Zeiten berücksichtigt werden. Ausschlaggebend ist dabei die Zahl und die Art der Plattenzugriffe. Diese bestimmen erfahrungsgemäß zu durchschnittlich etwa 80 Prozent die Höhe der Antwortzeit. Wird eine "besonders gute" Antwortzeit gewünscht, kann die "Dateienlandschaft" einer Systemanalyse stark ins Wanken kommen.

Sogenannte "gute" Antwortzeiten können sehr unterschiedliche Werte annehmen und sind trotzdem immer noch gut. Ein Systemanalytiker, der zwischen einer Ein-/Ausgabe am Terminal einige Dutzend Plattenzugriffe und diverse interne Verarbeitung plant, kann nicht den Anspruch auf eine Antwortzeit von unter einer Sekunde erheben. Ein Dialogsystem ist eben kein Datensammelsystem!

Setzt man die Gesamtzeit aller Operationen für eine Transaktion in das Verhältnis zu der externen, also am Terminal verbrauchten Zeit, ergibt sich die Belastung der EDV-Anlage durch diese Transaktion.

Je nach EDV-System sind systemspezifische Eigenschaften zu berücksichtigen, wie zum Beispiel das Multiprogramming-Verhalten. Ein System, das mittels Zeitscheiben gesteuert wird, ist schneller in den Griff zu bekommen als ein rein "Interrupt"-gesteuertes. Die Algorithmen für eine Berechnung haben die Hersteller zu liefern.

Aus der Betrachtung aller über das EDV-System abzuwickelnden Dialoganwendungen läßt sich ein Gesamtbelastungsprofil ableiten.

Je nach Hersteller und System gibt es unterschiedliche Hilfsmittel zur Durchführung einer FS:

- Tabellen, in die bereits bestimmte Betriebssystem-Funktionen eingearbeitet sind (etwa als Konstanten);

- Programme, die im EDV-System verfügbar sind und über Terminals ausgeführt werden können.

In beiden Fällen müssen die einzelnen Operationen innerhalb einer Transaktion eingetragen werden, entweder manuell in die Tabellen oder per Terminal in eine Plattendatei. Letztere Version erstellt nach Vorhandensein aller notwendigen Transaktionsbeschreibungen automatisch die Resultate. Ein weiterer Vorteil besteht in der leichten Modifikationsmöglichkeit einmal erfaßter Transaktionen.