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.08.1980

Testen zum Mondscheintarif oder zweites System?

Daß eine Zweitmaschine, die ausschließlich für Testzwecke eingesetzt wird, Arbeitserleichterungen bringt, haben clevere DV-Chefs längst erkannt - die Lösung des Testproblems mit separater Hardware gilt aber offenbar unter Kostengesichtspunkten als Luxus. Günstigere Konditionen für Zweitanlagen - das ergab diese Thema-der-Woche-Befragung - würden einen zusätzlichen Anreiz schaffen, Testbetrieb und Produktion zu trennen. "Es ist unverständlich, daß von den Herstellern die Marktlücke Zweitsystem für Testzwecke noch nicht erkannt wurde", meint Gerhard Mayer, DV-Leiter bei der Cilag Chemie GmbH, Alsbach.

Alfons Groß,

RZ-Leiter bei der Dyckerhoff & Widmann AG, München (Siemens 7.738, BS2000)

Eine allgemeingültige Antwort auf diese Frage kann nicht gegeben werden.

Vorteile eines separaten Rechners sind:

- Unabhängigkeit vom Betriebssystem, mit dem Produktivläufe gefahren werden;

- eine Gefahr des "Absturzes" der Produktiv-Arbeiten bei Systemtests;

- Auslegung des generierten Betriebssystems auf Testbetrieb/Produktivbetrieb;

- optimaler Datenschutz;

- keine gegenseitige Behinderung durch Test und Produktivbetrieb.

Als Nachteile ergeben sich:

- Erweiterung des Maschinen-Bedienungspersonals;

- doppelte Generierung und Pflege des Betriebssystems;

- Raumfrage, Klimatisierung, Kosten für doppelte Betriebssystemsoftware zusätzlich zu den Hardwarekosten .

In unserem Hause lag das Hauptproblem darin, daß bei dem batchorientierten Betriebssystemen BS1000 durch Produktivläufe erhebliche Verzögerungen der Übersetzungs- und Testläufe an der Tagesordnung waren. Dieser Mangel konnte nur durch Erweiterung der Hardware oder durch Einführung eines anderen Betriebssystems gelöst werden. Ein eigener Rechner für Programmentwicklung kam aus wirtschaftlichen Gesichtspunkten nicht in Frage. Der Anteil der Programmentwicklung und -pflege an der gesamten Rechenzeit ist so gering, daß ein separater Rechner wirtschaftlich nicht genutzt werden kann. Außerdem ist die Verknüpfung zwischen Test und Produktion besonders im technischen Bereich unseres Unternehmens zu stark, um eine klare Trennungslinie ziehen zu können.

Der kostengünstigere Weg war es, durch Einführung eines Dialog-Timesharing-Systems dem Programmentwickler die Möglichkeit zu schaffen, die notwendigen Arbeiten durchführen zu können. Die Wartezeiten auf Listen und Testergebnisse konnten dadurch erheblich gesenkt werden.

Der organisatorische Verlauf - Datenerfassung, Arbeitsvorbereitung, Maschinensaal - entfällt. Bei optimaler Nutzung aller Testhilfen kann auch der zeitliche Nachlauf - bis die Ergebnisse beim Programmierer sind - gesenkt werden. Über Datensichtgeräte wird ein großer Teil der Fehler erkannt und korrigiert. Timesharing-Anlagen gewährleisten auch die Gleichbehandlung der Produktiv- und Textverarbeitung. Die Erfahrungen in unserem Hause haben gezeigt, daß durch die Einführung des BS2000 der Parallelbetrieb von Test und Produktiv durchaus zur Steigerung von Zufriedenheit und Effektivität der Programmierer führen kann.

Möglicherweise ist die Forderung nach größtmöglichem Datenschutz ein entscheidender Grund für die Trennung von Test und Produktivbetrieb. Ein Dialogsystem im Teilnehmerbetrieb steigert die Gefahr des Datenmißbrauchs durch EDV-Profis auch bei closed-shop Betrieb erheblich. Es ist daher notwendig, durch geeignete Maßnahmen wie Passwords, Benutzerkennungen und Zugriffskontrollen den Datenmißbrauch zu verhindern.

Fazit: Die ärgerliche, durch die manuelle Tätigkeit von Menschen verursachte Verzögerung von Input und Output kann durch Einsatz modernster Technik auf ein Minimum reduziert werden. Die Umstellung führt dazu, daß jeder Benutzer den subjektiven Eindruck hat, er nutze, "seinen" Rechner. Es besteht also keine Notwendigkeit, zwei Rechner anzuschaffen, um die "Benachteiligung" der Tests abzubauen.

Aufgrund der zusätzlichen Kosten für einen zweiten Rechner muß zuerst die vorhandene Anlage zu klein sein, um sich mit der Trennung von Produktivbetrieb und Test auseinandersetzen zu können.

Anthony D. Harvey,

Manager of Data Processing, Communications and Dealer Systems Support, Clark Central Parts GmbH, Mülheim/Ruhr (IBM 4341, IBM 8100, IBM-Systeme /34 und ITT/Comten)

Die Probleme, die beim Testen von Programmen auftreten, sind folgende:

- Wie garantieren wir die andauernde Verfügbarkeit der laufenden Systeme, von denen unser Unternehmen abhängig ist?

- Wie ist es möglich, diese Anwendungs-Software zu warten, ohne den Produktionsbereich zu beeinträchtigen, wenn wir eine Änderung durchführen?

- Wie können wir die effiziente Entwicklung von neuen wichtigen Anwendungen durchführen und gleichzeitig die verfügbaren Produktivitäts-Hilfsprogramme erweitern?

Die Frage ist also, wie können wir die volle Computer-Kapazität zur Verfügung stellen, um alles gleichzeitig durchzuführen?

Daß eine Organisation benötigt wird, die alle diese Funktionen unterstützt, ist klar. Es besteht die Anforderung an uns, ein vollständiges und echtes duplikates Test-Environment für Wartung, Test und Neuentwicklung zur Verfügung zu stellen, das unsere wichtigsten Funktionen des laufenden Geschäftes nicht behindert.

Es genügt nicht, weiterhin auf der Programm- oder Systemebene zu testen. Wir müssen vielmehr sicherstellen, daß die neuen Anwendungen gemeinsam mit allen anderen damit zusammenhängenden laufenden Anwendungen funktionieren und daß unser neues oder geändertes System erfolgreich innerhalb unseres normalen Produktionsbereiches einschließlich Datenbank, Operating Procedure, Communication und Sicherheitssysteme arbeitet.

Die Hauptalternativen, die wir dabei in Betracht gezogen haben, waren die folgenden:

1. Eine virtuelle Maschine (ähnlich IBM VM/370), die, obwohl sehr reizvoll und auch hinreichend erprobt, sogar höheren Personalaufwand für Betriebssystem-Generierung und Wartung bedeuten würde sowie ein bedeutend komplexeres Operating-Verfahren. Beides Faktoren, die aufgrund unserer Geschäftsanforderungen nicht erforderlich waren. Die Verwender kleinerer EDV-Anlagen haben natürlich nicht immer den Vorzug, eine solche Alternative überhaupt ins Auge fassen zu können.

2. Eine separate Hardware, die direkt mit dem Bereich der laufenden Produktion und den peripheren Einrichtungen über einen sogenannten Multi-Rechner mit kooperierenden Betriebssystemen zusammenarbeitet. Hierbei besteht die Gefahr darin, daß bei einer weiteren gleichen kompatiblen, technologischen Ebene die Hardware finanziell nicht so attraktiv ist und wiederum gegen ein separates Testsystem abgewogen werden muß. Dies ist sicherlich heutzutage für die Benutzer kleinerer und mittlerer Anlagen keine sinnvolle Lösung, obwohl sie besonders wirtschaftlich für die Anwender mit größeren Anlagen und entsprechendem Personal ist. Bei der Entwicklung von Anlagen mit einem Preis-/Leistungsverhältnis ähnlich IBM 4300 wird dieses besonders interessant, wenn die Kommunikation von mehrfachen Betriebssystemen weiter verfeinert worden ist.

3. Die Möglichkeit eines Testbereiches als voll integierter Bestandteil unseres normalen Betriebssystems. Sicherlich war nicht weniger Hardware-Kapazität für separate On-Line Partitions, separate Batch- und RJE-Bereiche und eine Spiegel-Datenbank erforderlich. Mit Sicherheit aber war ein höherer Arbeitsaufwand und ein intelligenteres Design beim Systementwurf und bei der Systemgenerierung notwendig. Es waren dann jedoch alle Test-Einrichtungen mit dem normalen Arbeitsbereich identisch und dadurch den Neuentwicklungs-Teams vertraut.

Die Kapazitätseinbuße für Neuentwicklung und Test ist nicht unbedingt durch Beschaffung überholter, günstigerer und unabhängigerer Hardware-Technologie gelöst. Es muß eine Kombination der richtigen Betriebssystem-Software - entweder einer virtuellen Maschine oder eines virtuellen Bereiches - und einer Hardware sein, die verträglich ist mit dem heutigen technischen State-of-the-Art. Ob die tatsächliche Rechner-Leistung von einem Zentral-System, einem Doppel-Rechner oder einem Sub-System kommt, ist unerheblich. Wichtig ist, daß Wartung und Neuentwicklung als wichtige Bestandteile des Geschäftsvorganges, der geplante langfristige und integrierte Lösungen innerhalb des gesamten Unternehmens erfordert, erkannt werden.

Jörg K. Holley,

Leiter der Unternehmensplanung und Organisation, Bomag, Boppard (IBM 370/135, DOS/VS, 2 x Nixdorf 8850, Didos)

Von der Sicherheit her gesehen: ja; von der Wirtschaftlichkeit her gesehen: nein!

Diese allgemeine Aussage konnte ich im Rahmen der langfristigen Planung bei der Entwicklung des EDV-Konzeptes von vielen hören, und - trotz der niedrigen Hardwarepreise - sogar von Herstellern.

Meiner Ansicht nach ist dies zu allgemein und zu einfach gesagt. Nehmen wir die Sicherheit: Wenn Testdateien bei Bedarf von den Originaldateien nur kopiert werden und keine detaillierten Richtlinien für die Testdurchführung vorliegen, werden dadurch Sicherheits- und Datenschutzprobleme geschaffen - egal, ob mit oder ohne Testrechner. Auch der wirtschaftliche Aspekt kann durchaus anders gesehen werden. Ist der installierte Rechner nicht voll ausgelastet, so scheint dies ein Argument gegen den Testrechner zu sein - in vielen Fällen begründet, aber in manchen bestimmt nicht. Denken wir nur an den Einsatz von programmier- und RZ-unterstützender Software, die nachweisbare Arbeitserleichterungen nach sich zieht, aber auch die Rechnerbelastung zum Teil wesentlich erhöht und darum - aber auch aus hier nicht zur Diskussion stehenden subjektiven Gründen - nicht eingesetzt wird, obwohl durch die erwähnten Optimierungen durchaus ein Testrechner wirtschaftlich wäre.

Diese Gegenargumente sollten nur als Beispiel dafür gelten, daß keine generelle Richtlinie zu diesem Thema bestehen kann, sondern daß jedes Unternehmen eine eigene Antwort finden muß. Die Faktoren wie Rechnergröße, Nutzungsgrad, Anwendungen, benutzte Software etc. besitzen jeweils unternehmensspezifische Prioritäten. Eines kann jedoch als Voraussetzung genannt werden: Solange noch nicht alle Optimierungsmöglichkeiten im eigenen EDV-Bereich ausgeschöpft sind, sollte man dieses Thema nicht in Erwägung ziehen, da sonst andere Schwachstellen verdeckt werden.

In unserem Unternehmen wird der Weg gegangen, die Fachressorts schnell, umfassend und sicher zu unterstützen. Da jedoch das Projektteam von der Grobplanung über die Feinplanung und Programmierung bis zur Einführung des Projektes erstens nicht

verändert wird und zweitens sich auch wesentlich mit allgemein organisatorischen Lösungen beschäftigen muß, werden jene Aktivitäten technisch optimiert, die dies zulassen. Dazu gehören neben der Projektabwicklung, -verfolgung und -dokumentation hauptsächlich die Programmierung und die Testabwicklung. Um dies zu erreichen, muß neben dem Einsatz von Software-Tools auch der zeitliche Aspekt berücksichtigt werden. So wurde bei genauer Projektkontrolle in den letzten Jahren festgestellt, daß die Mehrzahl der zeitlichen Überziehungen im Rahmen der Testabwicklung lag beziehungsweise, daß die geforderten System- und Anwendungstests aus zeitlichen Gründen nicht vollständig oder nicht oft genug durchgeführt wurden. Diese Punkte sind jedoch besonders bei Tests von integrierten Systemen wie Kapazitätsplanung Bedarfsplanung und Bedarfsvorhersagemodellen entscheidend da vollständige Simulationen gefahren werden müssen, um alle Auswirkungen anwendungs- und programmtechnisch überprüfen zu können. In noch stärkerem Umfang gilt dies für Maintenance-Arbeiten an solchen Systemen. Wenn aber die Systemplaner und -entwickler die nicht unbedingt allgemeingültige Projektvorgehensweise voll akzeptierten und erstaunliche Erfolge mit ihrem Einsatz erzielten, so muß ihnen auch bei der Lösung dieses Problems von Seiten der Geschäftsführung von geholfen werden.

Da aber der installierte Rechner als Back-up-Anlage und Zentralrechner unseres DV-Netzes eingesetzt ist, entstanden sowohl für die Programmierarbeiten als auch für die Tests die erwähnten Probleme. Um diese zu lösen, ohne jedoch auf die erwähnten Vorteile verzichten zu müssen, wird in Zukunft ein zweiter Zentralrechner eingesetzt. Die zur Zeit eingesetzte Anlage wird folgende Funktionen übernehmen:

- Online-Programmierung mit entsprechenden Software-Tools,

- Testanlage mit eigenen Testdaten (entsprechend den Sicherheitsvorschriften geänderten Stammdaten, ergänzt um Daten für Grenzwertprüfungen),

- Back-up-Anlage zum zweiten Rechner.

Was erwarten wir davon? In erster Linie erwarten wir eine Steigerung der Entwicklungseffizienz im Sinne einer wesentlichen Erhöhung und Beschleunigung der System- und Anwendertests und dadurch ein Ansteigen der Systemgenauigkeit beziehungsweise eine Reduzierung von Follow-up-Arbeiten. Zweitens eine Erhöhung der Betriebssicherheit bis zu einem minimalen Risikograd und - last, but not least - eine durch die Projektentwicklung voll planbare Projektdurchführung und dadurch eine noch bessere Innovation.

Alle Punkte sind für unser Unternehmen bei der vorhandenen, voll erkannten und akzeptierten DV-Abhängigkeit der Ressorts von entscheidender Bedeutung, so daß die Beantwortung der gestellten Frage für unser Unternehmen lautet: Ja - und mit den Vorteilen der erwähnten Nebenfunktionen!

Gerhard Mayer,

DV-Leiter bei der Cilag Chemie GmbH, Alsbach (IBM 3-12)

Wenn es das EDV-Budget erlaubt und sofern eine gewisse Kompatibilität vorhanden ist, empfiehlt sich eine Methode, auf die wir uns ab Mitte 1980 festgelegt haben: Einführung eines neuen Systems, Parallellauf des alten Systems, sukzessive Übernahme aller Anwendungen. Somit wird das alte System zu Testzwecken frei. Dies gestaltet sich relativ problemlos, da das alte System Firmeneigentum ist.

Wir sehen als positiv an, daß das Hauptsystem vom Test freigehalten wird und somit die Systemzeit für die laufende Arbeit voll zur Verfügung steht. Als weiteren Vorteil sehen wir an, daß dadurch die Arbeit der Programmierung wesentlich effektiver wird und das permanent lauernde Schreckgespenst lange Wartezeiten, bis das System zum Test zur Verfügung steht, verjagt wird. Außerdem erzielt man am Hauptsystem, da die Behinderung durch Test nicht vorhanden ist, einen höheren Durchsatz. Andererseits entstehen im Regelfall durch den Betrieb von drei Systemen dem Anwender nicht unerhebliche Kosten. Es ist jedoch zu bedenken, daß Tests, sofern sie nicht innerhalb der normalen Arbeitszeit durchgeführt werden können, sich auf die Personalkosten, durch Mehrarbeitszeit beispielsweise spürbar auswirken.

Es ist uns unverständlich, daß von Herstellern die Marktlücke "Zweitsystem zu Testzwecken" noch nicht erkannt wurde beziehungsweise zwar erkannt wurde, man jedoch seitens der Hersteller nicht bereit ist, Zweitsysteme zu Testzwecken wesentlich günstiger anzubieten. Die auf breiter Basis angebotenen Minis sind nach unserer Meinung weitgehend als Zweitsysteme bei kommerziellen Anwendungen ungeeignet, da die Systemsoftware oftmals mit der Systemsoftware des Hauptsystems nicht übereinstimmt. Auch hier sind die Hersteller aufgerufen, aktiv zu werden. Systemkenner werden zwar nun auf die verschiedenen Konvertierungsmöglichkeiten hinweisen, aber man muß sich darüber im klaren sein, daß der Nutzen in keinem Verhältnis zum Aufwand steht. Man sollte einmal alle negativen wie positiven Faktoren gegeneinander abwägen und dann die Frage stellen, ob man sich nicht durch ein Testsystem zusätzlich mehr Sicherheit für das Hauptsystem leistet. Für ein Testsystem sind jedoch sowohl Platzbedarf als auch Miet- und bei einem gekauften System Wartungskosten einzukalkulieren. Letzten Endes werden doch die höheren Kosten die Entscheidung zur Anschaffung eines Testsystems nachhaltig beeinflussen.

Um hohe Kosten der Anschaffung einzusparen, würden sich folgende Alternativen anbieten: Der Zusammenschluß mehrerer Unternehmen oder Anwender zu einer Art Testgemeinschaft, welche die Nutzung eines zentralen Systems eventuell über DFÜ ausnutzen könnten. Eine weitere Möglichkeit wäre, daß Anwender, die im Besitz eines Testsystems sind, dieses gegen eine Gebühr zeitweise zur Verfügung stellen. Wie man gerade in letzter Zeit bemerken kann, geht der Trend zur Fremdsoftware. Die Gründe hierfür dürften auch im recht hohen Zeitbedarf für die Tests zur Eigensoftware liegen.

Wir sind ferner der Meinung, daß durch den Zusammenschluß von mehreren Anwendern in Testgemeinschaften sich gerade für EDV-Newcomer ein äußerst wichtiger Erfahrungsaustausch ergeben wird, der sich auch auf lange Sicht günstig auf die Eigensoftware-Kosten auswirken kann.

Berndt Schwabe,

DV-Leiter, Dyko Industriekeramik GmbH, Düsseldorf (2 x HP 3000/MPE III)

Für die Programmierung wäre eine Anlage, die ausschließlich für Testzwecke und Programmierung benutzt wird, die Erfüllung eines langgehegten Wunsches.

Die Vorteile sind schnell aufgezählt:

- schnellere Programmierung durch kurze Intervalle zwischen Erhalt und Bearbeiten der Umwandlungsliste, Korrigieren des Programmes, Umwandeln und Erhalt einer neuen Compilierungsliste;

- beschleunigte Testphase durch kurze Zyklen zwischen Teststart, Durchführung des Tests, Ausdrucken/Anzeigen des Test-Outputs, Überarbeiten des Testergebnisses und erneutem Start des Testlaufs;

- vereinfachte Projekt-/Programmübergabe: Bedingt durch die strenge Trennung der Testanlage von der Anwenderanlage können die Jobs samt ihrer Prozeduren, Programmaufrufe und der darin enthaltenen Anweisungen für Datenbanken, Dateien und Peripherie bereits so konzipiert werden, wie sie auch später auf der Anwenderanlage zur Ausführung kommen. Ein einfacher Datenaustausch würde für die feierliche Übergabe ausreichen.

Voraussetzungen:

- Vorhandensein einer echten Zweitanlage für Testzwecke und Programmierung mit weitgehend identischen Merkmalen: ausreichender Kernspeicher für angestrebte Partitionsgrößen, gleiches Betriebssystem (Release), und gleiches Spektrum an unterschiedlich gearteten peripheren Möglichkeiten sowie gleiche Programmiersprache und Compiler-Releases. Weiterhin wäre von großem Vorteil, wenn die beiden Anlagen im Rechnerverbund untereinander kommunizieren können. Je stärker diese Merkmale von der Anwenderanlage abweichen, um so aufwendiger wird die Konfektionierung und Übergabe des Projektes werden.

Nachteile lassen sich nicht viele finden.

- Erhöhter Kostenaufwand für die Anschaffung beziehungsweise Unterhaltung der Testanlage;

- fehlende Betrachtung während der Testphase, was das Response- und Echtzeitlaufverhalten der Programme mit konkurrierenden Sessions und Jobs der täglichen Anwendungen anbetrifft.

Der kostenbewußte EDV-Leiter wird nach Abwägung der Vor- und Nachteile in den meisten Fällen eine Aufstockung der vorhandenen Anlage zur Schaffung weiterer Programmier- und Testkapazität bevorzugen.

In unserem Unternehmen standen wir auch vor der Problematik, weitere Kapazität für Tests und Programmierung zu schaffen. Für die Realisierung der derzeit anstehenden Projekte werden wir eine zweite HP 3000-Anlage installieren, die im Rechnerverbund zu unserer ersten HP 3000 geschaltet wird. Gleichzeitig soll dieser Zweitrechner der Programmierung mehr Zeit für Programmierung und Tests zuordnen.

Der Mehrpreis für eine Zweitanlage im Vergleich zur Aufstockung der Erstanlage um entsprechende KBs und Massenspeicher hält jeder Kosten-/Nutzen-Analyse stand, da ein größerer Durchsatz und ein schnelleres Antwortzeitverhalten bei Dialoganwendungen als gewichtiger Nutzen zu betrachten ist.

Mein Tip lautet somit: Statt einer großen Anlage lieber zwei weniger große, die im Rechnerverbund voll kompatibel sind, wobei die schwächer belastete Anlage den antwortzeitempfindlichen Anwendungen und der Programmierung einschließlich Tests vorbehalten wird.