Ulrich Wolff ist Geschäftsführer der Unternehmensberatung "Gesellschaft für Information und Kommunikation mbH" (GIK) mit Sitz in Frankfurt und Hamburg.

Für die Erhaltung und Steigerung der Produktivität in der Anwendungsentwicklung wird die Software-Produktionsumgebung (SPU) immer mehr zu einem "Muß"; mit ihrer Hilfe können DV-Abteilungen kostenbewußt arbeiten und ihre Leistungen vergleichbar machen. Will ein Unternehmen bei dieser Entwicklung mithalten, führt kein Weg an der PU vorbei.

Rechner, Systeme und Daten stellen in einem Unternehmen nicht nur wertvolle Produktionsfaktoren dar, sondern sie bilden in erster Linie eine Umgebung, auf die Nachfrager in den Fachabteilungen und Anbieter von DV-Leistungen vielfache Rücksichten nehmen müssen.

Vorwiegend im Dienstleistungsbereich hat die DV ihren ausschließlichen Stellenwert als eine unterstützende Technik zur Verarbeitung von Massendaten verloren. Der aus dem Marketing resultierende Anspruch individueller Kundenbetreuung läßt die reine Technik mehr und mehr identisch mit den angebotenen Produkten werden. So ermöglicht die DV zwar die Bandbreite der Dienstleistungen, aber im Gegenzug stellt das härter gewordene Werben um den Kunden immer differenziertere Anforderungen an die Anwendungsentwicklung.

DV-Abteilungen erhalten externe Konkurrenz

In einem Kreditinstitut kommen dazu die zahlreichen Auflagen und Bestimmungen der Revision, des Datenschutzes, der Bundesbank und des Bundesaufsichtsamtes. Isolierte Anwendungen sind folglich keine geeigneten Lösungen mehr und weichen deshalb integrierten Anwendungen.

Auf dem Markt treten vermehrt konkurrierende Anbieter von DV-Leistungen auf. So erhöht sich der Druck der DV-Anwender auf die hauseigenen Entwickler, denn die Auftraggeber verlangen Leistungs- und Kostentransparenz, um vergleichen zu können.

In dieser Konkurrenzsituation müssen die DV-Abteilungen ihre Wirtschaftlichkeit behaupten. Aufgrund des hohen Anteils der Wartungsarbeiten an ihrem Gesamtergebnis bedeutet dies vor allem eine Steigerung der Qualität

Verstand man früher unter Qualität in erster Linie Fehlerfreiheit, treten heute Kriterien wie Erlernbarkeit, Benutzerfreundlichkeit, Verständlichkeit, Änderbarkeit, Lokalität und Prüfbarkeit in den Vordergrund. Ein Weg zur Steigerung der Qualität geht über die SPU.

Eine Software-Produktionsumgebung umfaßt alle Hilfsmittel, die zur Produktion von Software benötigt werden. Somit ist sie eigentlich nichts Neues.

Integrierender Einfluß auf die Arbeitsmittel

Je nach Größe und Art der Anwendungsentwicklung sieht die zweckmäßige SPU ganz verschieden aus; ist sie aber nach Bedarf und Nutzen richtig konzipiert, so liegt eine wichtige Wirkung im integrierenden Einfluß auf die Arbeitsmittel.

Es ist daher sinnvoll, die vorhandenen Elemente der Anwendungsentwicklung, wie Hardware, Basissoftware, Know-how und Mitarbeiterkapazitäten, auf ihre Tragfähigkeit für die geplante SPU zu prüfen. Zielgrößen sollen Quantität, Qualität und Produktivität sein. Werden Defizite sichtbar, kann man den gewünschten Zielen mit Methoden des Software-Engineerings (SE) näherkommen. Dabei setzt man über den ganzen Lebenszyklus einer Anwendung verstärkt die DV selbst als Hilfsmittel ein. Die folgenden SE-Maßnahmen bilden eine mögliche Handlungsalternative:

- Durch den Einsatz von leistungsfähiger Hardware wird die große Anzahl der Anwendungen überhaupt erst betreibbar. Hier müssen auch die Anwendungen berücksichtigt werden, die vom intensivierten DV-Einsatz für die Entwicklung selbst herrühren.

- Moderne Basissoftware ermöglicht die optimale Ausnutzung der Hardware auch für künftige Entwicklungen. Zusammen mit einem vernünftigen SE-Konzept trägt sie durch mehr Unabhängigkeit der Anwendungen von der Technik zu einer laufenden Sicherung der Softwareinvestitionen bei.

- Erst der massive Einsatz der DV zur maschinellen Erstellung, Pflege und Verwaltung aller Ergebnisse der Anwendungsprojekte entlastet die Mitarbeiter von Routinetätigkeiten und hält wertvolle Kapazitäten für kreative Prozesse des Fach- und DV-Designs und für die Qualitätssicherung frei.

Ferner muß es möglich werden, erfahrenes Personal für neue Anwendungsprojekte einzusetzen, ohne daß es durch die Betreuung der "AIt-Projekte" belastet wird. Dies setzt voraus, daß sich neue Mitarbeiter mit vertretbarem Aufwand und selbständig in die Anwendungen anderer einarbeiten können.

- Jeder Entwickler soll in die Lage versetzt werden, über den Zaun in benachbarte Anwendungsgebiete zu schauen. Hierdurch fördert man die Anwendungsintegration und nutzt Synergieeffekte.

- Der Erwerb von theoretischem und praktischem Know-how über Auswahl, Einführung und Nutzung der Techniken, mit denen Ziele erreicht werden sollen, hilft Fehler vermeiden und die gesamte Entwicklung beschleunigen. Dieses Wissen muß frühzeitig beschafft und an alle Beteiligten herangetragen werden. Empfehlenswert ist eine Abstufung in Beteiligung, Schulung und Information.

Umfangreiche Maßnahmenbündel können mit Projektgruppen durchgeführt werden. Für Aktivitäten aus den Maßnahmen 3, 4 und 5 wäre ein "Arbeitskreis Verfahrenstechnik" (AKVT) denkbar. Da die erarbeiteten Verfahrenstechniken die Arbeitsweise der Anwendungsentwicklung unmittelbar beeinflussen, sind an diesem Arbeitskreis Organisation und Programmierung zu beteiligen.

Der AKVT kann den Prozeß der Integration in Einzelschritten wie die Auswahl und Implementierung von neuen Verfahrenstechniken oder das Austesten von Teilergebnissen, gliedern. Darüber hinaus berichtet der Arbeitskreis regelmäßig an das Management und schult Mitarbeiter sowie fremde Abteilungen; Protokolle geben Einblick in den Fortgang seiner Tätigkeit.

Überlegungen hinsichtlich bedarfsgerechter SE-Maßnahmen sind zwar im Vorfeld der SPU anzustellen, gehen aber bereits Hand in Hand mit Aspekten der Einführungsstrategie.

Die Änderungen von Verfahrenstechniken in der Anwendungsentwicklung ist ein schwieriges Feld. Es erstaunt immer wieder, daß gerade diejenigen, die seit Jahren den Anwendern neue Arbeitsverfahren im Zuge der Automatisierung auferlegen, außerordentlich ablehnend auf die Rationalisierung ihrer eigenen Arbeit reagieren.

Transparenz mindert unbewußte Ängste

Da es sich hierbei um eine von unbewußten Ängsten gefährdete Schlüsselstelle des Konzepts handelt, muß eine erfolgreiche Strategie dies unbedingt berücksichtigen und auf Klarheit und Durchsichtigkeit für alle Beteiligten abstellen. Rechtzeitige Information und Ausbildung der betroffenen Mitarbeiter, die ausreichende Diskussion der mit den neuen Verfahrenstechniken verfolgten Ziele, sowie eine abgestufte Einführung helfen unnötige Reibungen und Ausfälle zu vermeiden.

Die SPU soll die Anwendungsentwicklung bei der Erstellung aller Arbeitsergebnisse unterstützen. Das Vorgehensmodell ist zunächst einmal ein Katalog aller Ergebnisse und der dazu notwendigen Aktivitäten. Arbeitsergebnisse aus den folgenden drei Bereichen lassen sich durch das Vorgehensmodell projektieren: Ergebnisse zur Beschreibung der Anwendung

Es sind dies die Spezifikationen der Vorgänge mit ihren Funktionen, die Spezifikationen der Programm-, Datei-, und Benutzerschnittstellen, die Spezifikation des Datenflusses, der Programm- und Jobabläufe, die Spezifikationen der Objekte mit den sie charakterisierenden Datengruppen sowie das Menschengerüst, die Kosten/Nutzenanalyse und die Handbücher.

Ergebnisse zur Projektplanung und Steuerung

Im groben Aufriß fallen in diesen Bereich zielbeschreibende Tätigkeiten wie das Festlegen der benötigten Ergebnisse und der notwendigen Aktivitäten, das Festhalten des Auftraggebers und des Anwenders, das Festlegen verfügbarer Ressourcen, Soll-/ Ist-Vergleiche sowie die Termin- und Kapazitätsplanung.

Ergebnisse zur Kommunikation mit den Projektbeteiligten

Hierzu zählen Berichte, Protokolle und Mitteilungen ebenso wie Zeitpläne, Einsatzpläne, Arbeitsaufträge und Rückmeldungen.

Alle Ergebnisse hängen in vielfältiger Weise voneinander ab; Sie müssen nicht nur produziert, sondern auch kommuniziert werden. Im

engeren Sinne bedeutet der Begriff "Vorgehensmodell" also Erfahrungen und Vereinbarungen darüber, wann, wer, welche Ergebnisse am besten produziert und welche Einzelaktivitäten dazu gehören. Das Modell ist ein integraler Bestandteil der Produktionsumgebung.

Ein solches Vorgehensmodell ist in erster Linie ein "ergebnisorientiertes Vorgehensmodell": Die Aktivitäten werden, ähnlich Checklisten, pro Ergebnis geführt. Auf eine bestimmte Reihenfolge kann das Vorgehensmodell zwar hinweisen, aber auf zuviel Automatismus und Zwang sollte verzichtet werden. Der Kreativitätsspielraum der Entwickler bleibt dadurch erhalten.

Ein erheblicher Vorteil des ergebnisorientierten Vorgehensmodells ist, daß es die Diskussion über Art und Reihenfolge der Aktivitäten im Planungsstadium versachlicht.

Vorgehensmodelle müssen nicht notwendig DV-gestützt sein. Die Vergangenheit hat aber gezeigt, daß Papier-gestützte Vorgehensmodelle nicht den gewünschten Erfolg brachten. Ein Zuviel an formaler

Routinearbeit führte auf Dauer immer zur Ablehnung.

Werkzeug nicht mehr selbst entwickeln

Um diesen Geburtsfehler des Vorgehensmodells zu beseitigen, versuchte man nach und nach, einzelne Aktivitäten durch Werkzeuge zu unterstützen.

Werkzeuge sind voneinander unabhängige Programme. Es gibt heute zahlreiche brauchbare Werkzeuge auf dem Markt, so daß es kaum noch gerechtfertigt ist, hier eine Eigenentwicklung zu betreiben. Oft sind beim Anwender bereits eine Reihe von Werkzeugen vorhanden. Das heißt aber nicht, daß für ihre Auswahl und ihren Einsatz innerhalb der geplanten Software-Produktionsumgebung sein Aufwand mehr betrieben werden muß.

Ein Grundproblem ist, daß es dem Benutzer überlassen bleibt, die Tools richtig einzusetzen, die verschiedenen Syntaxregeln zu kennen und die Ergebnisse untereinander verwendbar zu machen. Die Konsistenz der Teilergebnisse ist kaum zu gewährleisten. Erst durch die Integration mit dem Vorgehensmodell in der SPU gelingt es, eine weitgehend gemeinsame Sprache für den Einsatz der Werkzeuge festzustellen.

So entsteht eine Benutzeroberfläche, die dem gewünschten Ergebnis oder der gewählten Aktivität automatisch das richtige Werkzeug zuordnet. Unterhalb dieser Benutzeroberfläche, im Werkzeugkasten, lassen sich zwei Gruppen bilden, nämlich solche, die Primärinformationen erfassen und solche, die abgeleitete Ergebnisse, Sekundärinformationen, erzeugen. Zur ersten Gruppe zählen die Programm-, Text- und Maskeneditoren, zur zweiten die Formatierer, Generatoren und Compiler.

Für die Auswahl der Werkzeuge und ihren Einsatz in der SPU gelten neben der Forderung nach Funktionalität und Effizienz zusätzliche Kriterien wie die Integrierbarkeit der Benutzeroberfläche in die SPU, die Verträglichkeit der Methoden, besser noch die Methodenneutralität und ebenfalls die Integrierbarkeit der Datenbasis.

Die sachlogischen Zusammenhänge zwischen den Ergebnissen der Werkzeuge und dem Transfer verantwortet allerdings noch der Benutzer. Aus diesem Grund fanden Werkzeuge bislang nur dort Anwendung, wo bereits mit mehr oder weniger formalisierten Ergebnissen gearbeitet wurde. Um Produktivitätssteigerungen auch in anderen Bereichen zu erzielen, benötigt man noch eine weitere wichtige Komponente der SPU, das Dokumentationsmodell.

Logische, konzeptionelle und physische Sicht

Im Zusammenhang mit Datenbanken spricht man von der logischen, der konzeptionellen und der physischen Sicht. Vergleichbar kann die Sicht auf die Informationsbasis der SPU als Entwicklersicht, die Sicht des SE-Spezialisten als konzeptionelle Sicht und die Sicht der Realisierung der Informationsbasis in verschiedenen Speichern als physische Sicht bezeichnet werden.

Die Entwicklersicht hängt stark mit den Arbeitsergebnissen aus dem Vorgehensmodell zusammen. Die konzeptionelle Sicht zeigt die Gesamtzusammenhänge auf; sie wirkt entscheidend auf die Konsistenz der Informationsbasis, auf den Pflegeaufwand und den daraus erzielbaren Nutzen. Die physische Sicht sorgt für einen effizienten Zugriff auf die Informationsbasis.

In der Praxis erweist es sich immer wieder als schwierig, ein Dokumentationsmodell mit seiner konzeptionellen Gesamtsicht dem Anwender plausibel zu machen. Oft fehlt es ihm sowohl an methodischem Wissen als auch an praktischer Erfahrung. Auf besseres Verständnis stößt die schrittweise Einführung eines immer umfassender werdenden Dokumentationsmodells.

Das Überladen des Modells durch das Abbilden komplexer Strukturen sollte man vermeiden. Sparsame, aber aussagefähige Dokumentation ist zu favorisieren, denn nicht der SE-Spezialist, sondern vor allem die Entwickler müssen später mit der SPU umgehen können.

Wird vor Abschluß der SPU das Dokumentationsmodell in den Pilotprojekten getestet, muß es aufwärtskompatibel weiterentwickelt werden. Dazu sind genaue Vorstellungen und Kenntnisse der Gesamtstruktur notwendig. Moderne flexible Werkzeuge ermöglichen heute dieses Vorgehen anwenderfreundlich und schrittweise.

Zahlreiche halbfertig Produkte am Markt

Keine Frage, die SPU kann die Produktivität und Wirtschaftlichkeit in der Anwendungsentwicklung erheblich fördern. In Zukunft wird daher für viele Unternehmen die Entscheidung für eine eigene Anwendungsentwicklung mit der Notwendigkeit einer SPU eng verbunden sein. Die Anwender sind dann gut beraten, sich nicht in die Abhängigkeit eines der zahlreichen, aber nur halbfertigen Produkte zu begeben, die als SPU auf dem Markt angeboten werden.

Eine Einführungsstrategie, bei der die SPU langsam mit dem Verständnis der Anwender wächst und die die bereits getätigten Investitionen nutzt, ist erfolgversprechender. Das notwendige Know-how ist heute schon vorhanden, und für ein Unternehmen entstehen nicht mehr die hohen Kosten, die eine Erstentwicklung mit sich bringt.