Softwarewerkzeuge gibt es viele. Über Integrationskonzepte und integrierte Software-Entwicklungs-Umgebungen wird eher nur viel geredet. Während die Software-Entwickler den Rest der Welt mit integrierten Standardanwendungssystemen versorgen wollen, scheinen die Organisationen sich selbst die Disziplin der Selbstorganisation nur ungern aufzuerlegen.

Dies hat gute und schlechte Gründe. Der klassische Softwerker ist ein "Künstler", der als Bildhauer mit Hammer (Editor) und Meißel (Compiler) arbeitet.

Mit dem Ausbruch der "Manufakturperiode" im Softwerkergewerbe entstehen aber komplexe Produktionssysteme, die zumindest eines erfordern: Projektorganisation.

Verteidigung der eigenen Autonomie

Aus "höherer Sicht" liegt die "industrielle" Softwareproduktion unmittelbar vor uns, und die "Tool-Euphorie" symbolisiert auch den Traum von der Automatisierung der Softwareherstellung.

Aus der Sicht des Softwerkers geht es um die Verteidigung der eigenen Autonomie und Kreativität. Selbstorganisation ist auch hier tendenziell Bedrohung durch die "Maschine". Die "Computerrevolution" frißt (auch) ihre eigenen Kinder.

Die Konzeption eines Standardanwendungssystems für Organisation und Entwicklung darf die genannten Aspekte nicht nur taktisch in Rechnung stellen. Es bedarf einer strategischen Definition sinnvoller Zielsetzungen .

Ausgangspunkt der hier beschriebenen Überlegungen war die Zielsetzung, aufgabenbezogene, vollständig ausgestattete Entwicklerarbeitsplätze über ein Standardsystem bereitzustellen.

Informationseinflüsse in ein Modell einbetten

Basis ist ein integriertes Konzept, das die Entwicklerarbeitsplätze in ein unternehmensindividuelles und problemanpaßbares "Netz" aus Funktionen einordnet, das aus verschiedener Sichtweise Informationsflüsse, Managementaufgaben und Verwaltungsarbeiten in ein konsistentes Modell des gesamten Unternehmensbereiches einbettet, der von der Projektarbeit tangiert wird.

Unter diesen Voraussetzungen ist es nicht länger möglich, verschiedene Funktionen der Systementwicklung in üblicher Weise nebeneinanderzustellen. Hieraus ergibt sich die Aufgabe, eine wirksame und einfache Synthese traditionell gewachsener Techniken und Tools herauszufinden.

Wesentliche Eigenschaften eines solchen Systems sind insbesondere:

- Unterstützung evolutionärer Entwicklung von anwendungsspezifischen Projektmodellen eingebettet in adäquate Werkzeugsysteme,

- Einbindung dieser Modelle und Systeme in ein homogenes System aus Informations-, Verwaltungs- und Managementfunktionen .

Evolutionäre Entwicklungskonzepte für Projektorganisation und Werkzeugintegration brechen insbesondere mit euphorischen Innovationsstrategien.

Niemand kann "einfach" aus seinem Schatten heraustreten. Man muß die Realität, den "Status quo" und damit die eigene Geschichte akzeptieren. Dieser Schatten kann nicht "verkauft" oder "verloren" werden Auch die Angst "zurückzufallen", sollte weniger ernst genommen werden als die Aufgabe, selbstgesteckte Ziele mit geeigneten Mitteln zu erreichen.

Wer sich auf Vorsprünge anderer konzentriert, gerät leicht in die Situation des Achilles (Zenons Paradox), der aufgrund der verengten Fragestellung, den Vorsprung im Wettrennen mit der Schildkröte immer nur verkürzen, nie aber aufheben konnte.

Allgemeine Merkmale des "Status quo" sind heute:

-Übergewicht der Geschichtsbewältigung (Wartung, Anpassung),

- zunehmender Problemdruck (Anforderungsstau),

- Technologiechaos (Werkzeugvielfalt und Inkompatibilitäten),

- Akzeptanzschwellen (die Schwerkraft intern eingefahrener Arbeitsweisen) und

- Informationsdefizite und Kommunikationsmängel.

Dementsprechend verschieben sich die Gewichte der Problemstellungen. Gegenüber methodischtechnischen Gesichtspunkten werden psychologisch-organisatorische Kriterien wichtiger. Die Selbstorganisation moderner Softwareproduzenten erfordert gerade in diesem Bereich Unterstützung durch Standardsysteme.

Dabei geht es insbesondere darum, die Räume der Kreativität der Entwickler einzubinden in einen problemspezifisch anpaßbaren Rahmen, der Selbstdisziplin und schnelle Orientierung fördert. Die Architektur eines solchen Standardsystems soll im folgenden skizziert werden.

Der Anwender muß mit Hilfe der Funktionen des Standardsystems, die Datenbasis, die seine Projektorganisation beschreibt, selbst definieren können.

Zu den Standardsystemen gehören folglich auch Funktionen, Abbildungsregeln und Modellierungskonzepte für die anwenderspezifisch zu erstellende Datenbasis bereitstellen.

Es kommt hierbei auf Funktionen an, die Hierarchien verwalten können.

Weiter müssen die "Stammbäume" (Hierarchien) in ihren Blättern und

Verzweigungen (Knoten) mit einer Vielzahl von Elementen aus "Spezialkatalogen" verknüpfbar sein.

Dies erlaubt für einzelne Projekte

- eine präzise Strukturierung der Einzeltätigkeiten,

- eine differenzierte Organisierung der Sichtweisen auf die Informationen innerhalb eines Projektes sowie - eine systematische Implementierung von aufgabenbezogenen Informations- und Werkzeuggriffen.

Datenbasis und Software präzise trennen

Das Grundgerüst der Projektablauforganisation ist die hierarchische Struktur des Phasenplanes (Abb.1). Es enthält die Standardaufgaben für die Projekte eines Unternehmens.

Die Modellierung des unternehmensspezifischen Projektmodells ist unter mehreren Gesichtspunkten durchzuführen, wobei zumindest die Sichtweisen des projektübergreifenden Managements (Unternehmen), des projektinternen Managements (Projektleitung) und des Projekt-Controlling beziehungsweise der Fachabteilungen zu berücksichtigen sind (Abb. 2).

Das Vorgehen nach diesem Konzept ist bei präziser Trennung von Datenbasis und Software möglich.

Weiter kann unterschieden werden zwischen Generierungskomponente und Arbeitskomponente eines solchen Systems.

Die Generierungskomponente erzeugt und verwaltet die Daten der Wissensbasis, das heißt die hierarchische Struktur des Projektmodells mit den Verknüpfungen zu den Elementen der "Spezialkataloge".

Die Generierungskomponente hat tendenziell den Charakter eines "Expertensystems". Sie besteht aus Software, die die Grundfunktionen der Modellierung unternehmensspezifischer Projektmodelle erlaubt (Systemgenerierung) und aus solchen, die aufgrund einer Auswahl weniger projektbeschreibender Merkmale aus dem allgemeinen Projektmodell für die einzelnen Projekte erforderliche Untermenge selektieren (Projektgenerierung).

Die Arbeitskomponente ermöglicht allen Projektbeteiligten die Arbeit mit den für sie relevanten Systemfunktionen und Daten.

Die Arbeitskomponente arbeitet mit der ausgewählten Untermenge der Wissensbasis und den Stammdaten, die aus den "Spezialkatalogen" bestehen (Abb.3).

Elementare Aufgaben

Grundlegende Bestandteile der Arbeitskomponente sind Arbeitsumgebung und Werkzeugsystem.

Das Werkzeugsystem ergibt sich unmittelbar aus der Generierung eines Projektes, da in der Modellierungsphase elementare Aufgaben (Tätigkeiten) beschrieben und mit elementaren Diensten (Werkzeugfunktionen) verknüpft werden.

Der Entwicklerarbeitsplatz kann so durch die System- und Projektgenerierung in zweifacher Hinsicht ausgerüstet werden:

- Bereitstellung elementarer Dienste (Services)

- Verknüpfung elementarer Aufgaben mit allen erforderlichen Informationen (Support) für den Entwickler (Abb. 4).

Die Servicekomponente führt den Entwickler durch die Werkzeuge, die er bisher manuell steuern und verwalten mußte.

Durch diese Führung und die Supportkomponente wird der Entwickler von nebensächlichen, technischen und verwaltungsintensiven Arbeiten entlastet.

Er kann sich stärker auf seine Entwicklungsaufgabe konzentrieren.

Service- und Supportkomponente bilden zudem die Basis für effektive Qualitätssicherung und Dokumentation. Die maschinelle Unterstützung bei der Einführung und Durchsetzung von Standards und die Informationszugriffsmöglichkeiten, zum Beispiel, ob wiederverwendbare Teilprodukte zur richtigen Zeit in anderen Zusammenhängen verfügbar sind - alle diese Eigenschaften in ihrem synergetischen Zusammenspiel bewirken erhebliche Produktivitätssteigerungen.

Unzählige Fragen, wie: "Wo finde ich was?", "Wie bediene ich dieses Werkzeug, wie jenes?", "Was ist wann mit welchen Prioritäten zu machen?" etc. fressen nicht selten 50 Prozent und mehr der Arbeitszeit.

Die damit erreichte Stufe der Werkzeugintegration kann die Bedienoberfläche der Einzelwerkzeuge zunächst noch nicht in einem homogenen Konzept ausschalten. Sie beschränkt sich auf Aufrufstrukturen und Kommentare zur Bedienung.

Es ist in unserem Sinne auch unsinnig, die realen Probleme der Werkzeugintegration zu verstecken.

Das vorgestellte Konzept soll nicht zuletzt als Wegweiser und Problemaufdecker dienen, das die Notdürftigkeit der künstlichen Brücken nicht verschleiert.

Eine wesentliche Auswirkung des breiten Einsatzes von Standardsystemen, die diesen Anforderungen genügen, wird die Qualitätssteigerung der austauschbaren Erfahrungen zwischen Einzelunternehmen und Software-Tool-Herstellern sein.

Eine erste Wegweisung liegt für uns schon jetzt auf der Hand:

- Es müssen anstelle von "Universal-Tools" zunehmend "Elementar-Tools" erzeugt werden.

Nur so kann Tool-Integration von qualifizierten Software-Ingenieuren, die die Methodenintegration für einzelne Unternehmen durchführen, zukunftssicher und herstellerunabhängig realisiert werden.

Die Erfahrung bei der Entwicklung und Präsentation eines diesem Konzept entsprechenden Systems zeigen, daß das Problembewußtsein für die Notwendigkeit eines integrierten Gesamtkonzeptes für Entwicklung und Organisation in der Breite e(...)noch geweckt werden muß.

Fachleute der Softwaretechnik bezeichnen diese Konzeption als zukunftsweisend, weil sie die Träume vom "Supertool" aufgibt, ohne Abstriche von den berechtigten Anforderungen zu machen, die den Träumen zugrunde liegen.

Die frühzeitige Einführung solcher Konzepte eröffnet auch Möglichkeiten einer echten Selbstorganisation von betroffenen Unternehmensbereichen. Dennoch bleibt ein Quentchen Skepsis.

Brauchen Softwareentwickler nur noch Zeit, die Vorteile der Standardanwendungssysteme für sich selbst zu entdecken?

Oder wollen sie sich diese Systeme von oben (wegen wachsendem Problemdruck) aufzwingen lassen?

*Dietrich von Alemann ist Berater für Informationsverarbeitung der WKF-Consult, Beratungsgesellschaft für Orgnisationsentwicklung mbH, Berlin.