In der täglichen DV-Praxis laßt sich erfahrungsgemäß kein Werkzeug allein durch "Druck von oben" durchsetzen. Wichtig für eine reibungslose Einführung ist es deshalb, den betroffenen Mitarbeitern das neue Hilfsmittel rechtzeitig schmackhaft zu machen. So die Erfahrung der Börsen-Daten-Zentrale (BDZ), Frankfurt, bei der Implementierung einer Software-Produktions-Umgebung.

Parallel zur Installation des Data Dictionary stellten wir Überlegungen an, weitere Werkzeuge zur Unterstützung des Entwicklungsprozesses zu integrieren. Dabei wurden zunächst die Aktivitäten betrachtet die manuell nur besonders zeitaufwendig und qualitativ unvollkommen durchführbar sind.

In der Design-Phase sind das die Informations-Struktur-Analyse mit Definition der funktionalen Zusammenhänge und der Verarbeitungsregeln sowie das Erstellen von Prototypen für Listen- und Bildschirm-Masken Informations-Struktur-Analyse und Funktions-Struktur-Analyse sind heute weder durch Entwurfssprachen noch durch Sprachen der vierten Generation ausreichend unterstützt - der analytische Denkprozeß läßt sich eben kaum maschinell unterstützen. Werkzeuge zur Erstellung von Prototypen von Benutzerschnittstellen sind dagegen ausreichend auf dem Markt.

Für Listbilder setzen wir die bereits seit langem im Haus verwendete Retrieval-Sprache "Easytrieve" ein. Bei der Auswahl einer Software zum Entwurf von Bildschirm-Layouts waren die Anforderungen höher: Unter anderem sollte eine Zielsystem-unabhängige Speicherung des Entwurfs möglich sein, das heißt, der Designprozeß muß losgelöst sein vom Generieren der Programteile sowie Zielhardware- und Software-abhängiger Kontrollblöcke. Wir haben uns für den Generator STW04 der Firma SWT, Bonn, entschieden.

In der Phase des DV-Konzepts und der Codierung sollte ein Programm-Generator für Normierung, Portabilität und Effektivität sorgen. Da ein Großteil der Entwickler eingefleischte Jackson-Fans waren, stand zunächst ein Jackson-Precompiler auf der Wunschliste. Zugunsten eines höheren Normierungseffekts und größerer Portabilität haben wir uns jedoch für das Produkt "SWT 01" entschieden. Hierbei handelt es sich um einen Programm-Rahmengenerator, der auf Basis einer relativ einfachen Command-Sprache und nach den Regeln der normierten Programmierung die Struktur von Cobol-Programmen erstellt. Routinen für Dateizugriff, Gruppenwechsel, Strukturkonflikte bis hin zu testfertigen und lauffähigen Batch- und Online-Modulen können generiert werden.

In der Testphase schließlich stützen wir uns auf das Produkt "Softdoc" der Firma SES zur statischen Analyse sowie zum Abgleich von Fach- und DV-Konzept mit realisiertem Code. Bei IMS-Online-Programmen verwenden wir zunächst den Batch-Terminal-Simulator der IBM.

Nicht unerwähnt bleiben darf, daß wir einen dedizierten Entwicklungsrechner IBM 4381 Modell 3 zur Verfügung haben. Als Editor nutzen wir TSO/ISPF. Darüber hinaus steht jedem Entwickler ein eigenes Terminal zur Verfügung, und die Antwortzeiten liegen für Trivial-Transaktionen unter einer Sekunde. Der Software-Entwicklungsprozeß für das Siemens-Zielsystem läuft im wesentlichen ebenfalls auf dem IBM-Rechner. Hierbei kommt uns entgegen, daß sowohl der Data-Manager als auch "SWT04" den Dialog und die Datenhaltung zielsystemunabhängig zulassen. Wir verwalten also die vollständige Entwicklungsdokumentation, Programm-Source (SWT 01), Layouts und Dictionary-Source zentral und redundanzfrei auf dem IBM-Rechner. Erst zum Kompilieren und Testen wird mit dem Siemens-Rechner gearbeitet. Abbildung 3 gibt noch einmal einen Gesamtüberblick über die Software-Produktionsumgebung der BDZ.

Zwei Voraussetzungen sind unserer Erfahrung nach für den erfolgreichen Einsatz einer Software-Produktions-Umgebung ausschlaggebend:

Das oder die Produkte müssen von den Mitarbeitern akzeptiert werden. Hier hatten wir sicher einen guten Nährboden ist einer jungen und motivierten Entwicklungsmannschaft. Darüber hinaus hat uns die Untersuchung einer Guide-Arbeitsgruppe geholfen, in der ein ganzes Maßnahmenbündel zum erfolgreichen Einsatz von Methoden und Werkzeugen aufgezeigt wird. Nachfolgend einige Schwerpunkte mit Stichworten zu den Maßnahmen:

Mitarbeiterausbildung

- Nicht nur das WIE, sondern auch das WARUM schulen;

- Ziele klar definieren;

- Schulung unmittelbar vor der Praxis;

- aktive Lernmethode;

- praxisorientierte Schulung.

Mitarbeiterunterstützung

- Einrichtung einer Gruppe "Anwendungsunterstützung" mit beratender Funktion;

- Inhouse-Kompetenz aufbauen;

- Berater mit Praxiserfahrung;

- Mitarbeiter der Unterstützungsgruppe in Projekten;

- Help-Funktionen schaffen;

- Benutzerführung;

- einheitliche Benutzeroberfläche

- Erstanwendung ohne Termindruck;

- Schneeballsystem zur Verbreitung;

- Feedback durch Usergroup.

Mitarbeiter-Motivation

- Mitarbeiter bereits in die Vorbereitung einbeziehen;

-Mitarbeiter in Auswahl und Test von Methoden und Werkzeugen einbeziehen;

- Mitarbeiter zu Vorschlägen auffordern;

- Kritik der Mitarbeiter ernstnehmen;

- positive Meinungsmacher einbeziehen;

- Klima der Erwartung schaffen;

- Angst vor dem Neuen :nehmen;

- Aufwertungseffekte der Tätigkeit herausstellen;

- Bewußtseinsbildung bei den Mitarbeitern, daß Werkzeuge von Routinearbeit entlastet und die Leistung im kreativen Bereich gesteigert werden können;

-Schwachstellen nicht verdecken.

Ressourcen und maschinelle Hilfsmittel

- Methoden und Werkzeuge aufeinander abstimmen;

- das Werkzeug muß an die firmenindividuelle Umgebung anpaßbar sein;

- Werkzeuge müssen auf allen eingesetzten Systemen laufen;

- klare Zuordnung von Phase und Aktivität zu Methoden und Werkzeug;

- phasenübergreifende Tools;

- hohe technische Verfügbarkeit der Werkzeuge;

- ein Bildschirm pro Mitarbeiter;

- Sub-Second-Response-Time;

- menügesteuert und interaktiv.

Die Durchführung eines derartigen Maßnahmenkatalogs stellt natürlich einen beträchtlichen Overhead dar. So waren die Mitarbeiter der BDZ in der Einführungsphase allein durch Schulungs- und Technologie-Transfer-Maßnahmen bis zu 40 Manntage pro Mitarbeiter gebunden.

Aus dieser Erkenntnis heraus ist die zweite Voraussetzung für den erfolgreichen Einsatz von Methoden und Werkzeugen ableitbar: Das Management muß hinter den Maßnahmen stehen. Wichtig ist, daß es sich hierbei nicht nur um Lippenbekenntnisse handelt.

Overheadzeiten gleich zu Beginn einplanen

Dazu gehört eine umfassende Information über den Fortschritt der Einführungsaktivitäten ebenso wie das Tolerieren von Fehlern und das Decken von Terminverzögerungen. Die beliebte Aussage um Führungskräften zu Ausnahmeregelungen zu überreden, nämlich "ich würde das Tool ja gerne einsetzen, aber dann kann ich den Projekttermin nicht einhalten", sollte durch Vorabberücksichtigung von Overheadzeiten gegenstandslos werden.

Wir haben bei allen größeren Projekten (mehr als ein Mannjahr) die Erfahrung gemacht, daß die Lernzeiten durch erhöhte Produktivität um ein Vielfaches ausgeglichen werden. In unserem Pilotprojekt wurden 160 000 Lines of Code für Kontrollblöcke, Copies und Programme erstellt, wobei bei den Programmen der Generator-Input und nicht die generierten Cobol-Statements gezählt wurden. Ebensowenig wurden die vielen tausend Lines of Code Dokumentation miteinbezogen. Diese Leistung erbrachte ein Sechs-Mann-Team in etwas mehr als eineinhalb Jahren. Der Gesamtaufwand für das Projekt von Phase l bis einschließlich Phase 5 betrug zirka 1600 Manntage, was einer Produktivität von 100 Lines of Code pro Mann-Tag über die gesamte Projekt-Laufzeit entspricht.

Diese Zahlen bestätigen, daß der Aufbau einer Software-Produktions-Umgebung die richtige Entscheidung war. Wohl wissend, daß wir noch ein gutes Stuck von einer 100prozentigen Losung entfernt sind, stellen wir uns heute nicht mehr die Frage, ob wir mit anderen oder integrierten Produkten besser gefahren wären.

Im ersten Teil seines Beitrags Setze sich Thomas Gebert mit Methoden und Werkzeugen für eine SPU auseinander und beschrieb das Data Dictionary als Brennpunkt der Entscheidung. Die zweite Folge

beschäftigt sich mit Werkzeugen für Entwurf, Entwicklung und Test sowie mit Erfahrungen bei der Einführung.

*Thomas Gebert ist Leiter Anwendungsprogrammierung bei der Börsen-Daten-Zentrale (BDZ), Frankfurt.