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

Generierung neuer Releases (Checkliste der zu berücksichtigenden Punkte)

Bei jeder Generierung eines neuen Releases entstehen immer wieder im Prinzip dieselben Probleme. Man sollte diese in Form einer Checkliste abarbeiten. Es gibt zwei verschiedene Problemarten. Erstens kann man allgemeine Punkte aufstellen, die für alle EDV-Benutzer mittlerer und größerer Systeme gelten. Zweitens sollte man sich die Mühe machen, die kundenspezifischen Probleme herauszuarbeiten. Auf diese kann hier verständlicherweise nicht eingegangen werden.

1. Die erste Aktion sollte das systematische Durcharbeiten der Ankündigungen neuer Features des entsprechenden Releases sein. Hierfür sollte man sich die notwendige Zeit nehmen.

2. Die zu generierenden Features sollten ausgewählt und genau besprochen werden.

3. Wenn das neue Release im wesentlichen deshalb implementiert wird, weil ein back-level-release verwendet wird, kann die Wirtschaftlichkeitsbetrachtung entfallen. Man sollte sich trotzdem Gedanken zum Nutzen eines neuen Releases machen.

4. Sehr wichtig, ja geradezu lebensnotwendig ist das Nachforschen nach der Güte des neuen Releases. Man sollte sich nicht scheuen, beim Software-Dienst des Herstellers genaue Erkundigungen einzuziehen, welche Funktionen des neuen Releases vermutlich Schwierigkeiten bereiten werden. Vielleicht liegen auch schon Änderungen (sog. PTF's vor, die unbedingt eingespielt werden müssen.

5. Man sollte seine Erkundigungen auch auf der Benutzerseite fortsetzen. Ein Telefonat mit einem Benutzer dieses neuen Releases kann viele bittere Erfahrungen ersparen.

Einzelpunkte der Generierung

1. Man sollte überprüfen, ob Bibliotheken verändert werden. Hier kann sich mitunter die Größe, verändern. Es kann sinnvoll sein, einzelne Bibliotheken auf andere Plattenstapel zu verlagern. Geht man hier nicht gründlich genug vor, fliegt man auf die Nase.

2. Je nach Größe der Installation werden ein oder mehrere Systemplattenstapel benötigt. Man sollte überprüfen, ob hier Änderungen notwendig werden.

3. Aus dem Gesichtspunkt eines eventuellen Parallellaufes des alten und neuen Releases ergeben sich eine Vielzahl von Einzelproblemen, die es zu bedenken gilt.

4. Es ist auch nicht uninteressant darüber nachzudenken, ob man nach Freigabe des neuen Releases noch auf das alte Release zurückgreifen kann. Ein Test wäre angebracht.

5. Die eigenen Programmierer sollte man nicht dadurch überraschen, daß man mal kurz eine neue Testorganisation einführt, ohne diese vorher genau zu überdenken und abzustimmen.

6. Man sollte sich darüber Gedanken machen, ob erhöhte Paging-Probleme zu erwarten sind. Dies gilt besonders dann, wenn der Hauptspeicher bisher schon eng ausgelegt war, oder wenn man neue Speichertechniken (VSAM als Beispiel) einführen will.

7. Ist die Job Control zu ändern? Gibt es möglicherweise Probleme mit dem Job-Exit? Muß man hier möglicherweise Modifikationen vornehmen?

8. Gibt es Accounting-Probleme? Ist gewährleistet, daß die Zeiten vom System zuverlässig abgegeben werden? Leider ist dies nicht immer eine Selbstverständlichkeit.

9. Treten für das Operating Änderungen auf? Müssen die Operator auf die neuen Möglichkeiten hingewiesen werden? Dasselbe gilt für die Arbeitsvorbereitung. Ebenfalls sollte man alle System-Benutzer auf neue Möglichkeiten des neuen Releases hinweisen, sofern diese davon betroffen sind.

10. Neue Releases sollten gründlich getestet werden. Es ist daher eine Testzeitenabstimmung erforderlich, zumal in den meisten Fällen das gesamte System beschlagnahmt werden muß.

11. Man sollte repräsentative Jobs für Vergleichsläufe auswählen und die Ergebnisse der Vergleichsläufe mit Vergleichsprogrammen (Tape-Compare etc.) vergleichen.

12. Alle Änderungen müssen dokumentiert werden. Am besten nimmt man sie gleich in das EDV-Handbuch auf. Damit stellt man sicher, daß auch die Benutzer des Systems informiert sind.

13. Man sollte rechtzeitig Optimierungsmöglichkeiten des neuen Releases klären bzw. Benchmarks fahren, falls dies erforderlich sein sollte.

14. Schließlich ist das neue Release offiziell freizugeben.

Aus der Sicht des individuellen Benutzers gibt es eine Vielzahl von Dingen, die zu berücksichtigen sind, insbesondere dann, wenn man An- oder Umbauten des Systems vorgenommen hat. Auch an diese Punkte sollte man rechtzeitig denken.